Recently we’ve been talking to some customers about the challenges faced by user experience (UX) designers.

Our conversations have revealed that the biggest designer problems relate to collaboration with other teams and stakeholders, particularly developers and quality assurance (QA) engineers.

We thought we’d boil our research down to some key questions being asked by design leaders and their teams, and see if we can provide some answers.

1. How do we persuade leadership that we need a proper design system?

Many product development teams don’t have a proper design system or design system tooling. Their components aren’t up to date because whoever’s meant to be on top of the maintenance isn’t. Nor are the components in a central place where everyone can access them. Instead they’re scattered over a range of tools.

The challenge for designers is persuading top-level management that this has to change. In lots of companies, the leaders don’t see a design system as a product that can make them money.

Maybe that’s the problem: seeing a design system as a product. Many people see products as things that generate revenue, and design systems don’t, at least not directly. They make money by improving your products and reducing inefficiencies in your design process, but that’s hard to quantify. This is why some leaders have trouble perceiving the business value of design systems and deprioritize them.

But if we frame a design system as infrastructure, rather than as a product, management’s perception will change. Infrastructure is the systems and services that are necessary for companies to run, like electricity and internet. And like any utility, they need maintenance to keep running. This should help senior managers appreciate how essential they are to our success.

Another way is by getting your organization to adopt working practices that emphasize why design systems are necessary for good designer-developer collaboration, such as the Clear View Method for Design Handoff. This simplifies the design-to-dev handover while still making sure the final build is exactly what designers intend. The first principle of the Clear View Method is:

Build and document a design system prior to handoff.

Basically, a properly documented design system is crucial to making sure your handoff isn’t too long, complicated, or inefficient. Your design system documentation should live in a general team workspace tool like Confluence, not a design tool like Figma or a developer tool like Storybook. That way it’s easy to use and maintain, and most importantly, it’s accessible to everyone.

2. How can we champion the importance of small details when our developers outnumber our designers?

Designers are often outnumbered in cross-functional teams. This leads them to acquiesce to developers who question the value of their design iterations and encourage a simpler approach.

The problem is, exceptional design is impossible if you’re always cutting corners like this.

This is one of several designer problems that can be alleviated by involving developers in the design process much earlier. The second principle of the Clear View Method for Design Handoff is:

Handoff isn’t a one-and-done process.

This means that handing over a final design shouldn’t be the beginning or the end of the process. There should be regular meetings and check-ins throughout the project, including a project kickoff meeting that enables a designer to outline the problem to be solved and get ideas from devs and stakeholders.

Confluence can be used to create design documentation to be presented at these meetings. By integrating Figma with Confluence, you can show initial ideas and draft Figma designs on Confluence pages.

Involving developers from the get-go will help them better understand the context, purpose, and value of the designs you end up proposing.

3. How do we get QA to stop prioritizing functionality over visuals?

It’s not just developer collaboration that designers are struggling with. Working effectively with the QA team can also be a challenge.

Specifically, designers are finding that the visuals are taking a back seat to the functionality in the QA process. They say that all of the detail is there in Figma, but QA aren’t seeing it. They’re so focused on having a working product that can be shipped to customers that they’re not paying close enough attention to what it looks like.

Some of the problem here could be communication. The sixth principle of the Clear View Method is:

Hand off to everyone.

So, this is about making sure you’re handing over designs not just to the development team, but to QA, product owners, support, and anyone else who can offer input and value. This, combined with the second principle, handoff isn’t a one-and-done process, can help make sure you’re having ongoing discussions with QA throughout the project. From the outset you can impress on them the importance of the visuals and how they impact the UX.

But some of the problem could also be Figma. Figma is a design tool and it’s very complicated to navigate if you’re not a designer. Asking QA to go into Figma to inspect the detail of your designs may not be entirely fair.

Instead, you could link to your Figma designs in a more neutral and accessible tool, like Confluence or Jira. With an app like CollabSoft’s Figma for Confluence and Jira, you can embed a Figma frame in a Confluence page or Jira ticket. QA can view designs without the cognitive load that comes from navigating Figma.

4. How do we change this “fix it later” mentality?

Agile’s mantra of “fail fast and often” isn’t a license to be slapdash and lazy and push out rubbish products simply because you can fix them later.

But designers are concerned that that’s exactly what’s happening. Managers are prioritizing getting features released to customers and not worrying that devs and QA are missing important details in the designs. Because, you know, they can be fixed later.

But designers find that those fixes just get added to the backlog and forgotten about because no one saw them or thought them important in the first place.

While better communication between designers, devs, and QA can help prevent this, leadership also needs to change its attitude. They’ve hired UX designers for a reason. If the minutiae of their designs are being ignored, what are they paying them for?

Again, designers can try to alleviate this problem by following the fourth principle of the Clear View Method and handing off to everyone, including management. Because if the leaders are made aware of the problem and its context, they’ll hopefully start to appreciate why the details matter.

5. How do we get developers motivated to improve our processes?

Another designer problem is getting buy-in from developers to fix the problems. Some designers believe developers have no motivation to learn tooling like Figma’s dev mode, or discuss designs and functionality with designers during development, or attend their handover meetings.

Fault lies on both sides of the fence here, and with managers failing to foster better links between their teams. Developers need to acknowledge why it’s vital that they improve how they collaborate with designers, and they need to invest some time in doing that.

But designers need to acknowledge some things too. If they’re holding handover meetings, that’s great, but if devs aren’t attending, it’s because the importance of them being there isn’t being communicated. They may assume they’re not needed. Designers and managers need to impress on them otherwise.

And if devs aren’t motivated to learn tooling like Figma, maybe that’s because they shouldn’t be learning tooling like Figma. Even though Figma’s trying to accommodate devs with Figma dev mode, it’s still a tool that favors designers. It’s their sandbox, their playground for exploring and iterating. Devs want clear, unambiguous instructions on what they should code, and Figma isn’t the place for it.  

Finally, if developers aren’t communicating with designers during the development process, maybe it’s because the lines of communication aren’t clear. Too many tools in the handoff process is common, and all it does is confuse everyone. If there isn’t a single source of truth for communicating about designs and their implementation, good communication won’t happen.

So the answer is: streamline your tools, which leads us onto…

6. How do we streamline our tooling?

A lot of the designer problems we’ve talked about can be traced back to bad tooling. And by bad tooling, we mean, too much.  

Some designers say their handoff process is spread across a mix of tools: Figma, Jira, Microsoft Teams, Slack, Zeplin. Sometimes Figma and its ‘Ready for dev’ label are used. Sometimes Jira tickets are made and linked to designs, but often they’re not. If Jira isn’t used, Microsoft Teams is used and handoff happens across a bunch of group chats.

One designer told us they had a really old instance of Confluence which their lead designer didn’t want to use, so they used Zeplin instead. But Zeplin is a whole other platform with its own concepts, workflows, and permissions. Adding Zeplin to an already complicated stack—instead of upgrading a collaboration tool that everyone’s familiar with and has access to—is a poor strategy.

This lack of a single source of truth is making design handoffs overly complicated and leading to devs missing details or straight-up building the wrong designs.

Teams can fix this by homing in on one or two tools for handoff. Jira and Confluence are general team workspace and collaboration tools where everyone’s already working. Make them your handoff tools. Your devs use Jira to manage their tasks, and coding a design is a task that should live in Jira. Confluence is for documentation, so why not use it for your design documentation? And with CollabSoft’s Figma for Jira and Figma for Confluence, devs and stakeholders can view Figma designs in tickets and pages without having to log into or navigate Figma.

No need for Figma dev mode. No need for Zeplin. No need for Microsoft Teams. Make your Atlassian tools your single source of truth for design handoff and you’ll save a ton of frustration.

7. Do our designers need to be more technical?

One of the designers we spoke to said that on her design team of 7, there was 1 designer who was more technical and understood a bit of code. The rest knew the product well, but didn’t have much technical knowledge.

In 2023, Figma ran a survey of 200 developers, 91% of whom said that designers should know how to code. When CollabSoft ran a survey of 500 designers earlier this year, a still high 68% said the same: designers should know how to code.

Our blog about why good designer-developer collaboration can be hard tackled this issue of designers becoming coders. In the end, we argued that, no, designers don’t need to become developers to work better with them. But a basic understanding of code, what it does, and what its limits are, would really help. And likewise, developers should learn the basics of design.

Basically, there’s a language barrier between designers and devs. Designers becoming more technical and devs learning a bit of design is a way of overcoming it. In the same way that designers feel like devs don’t appreciate the finer details, their lack of knowledge of the technical limitations could be the reason why devs are ignoring some of those details.

So, a better understanding from both sides is absolutely key.

8. Is remote working hurting developer-designer collaboration?

We live in a world of globally distributed teams and remote working. But could remote working underpin all of the designer problems we’ve been talking about?

Nah. Although there’s drawbacks to not being co-located, they can be overcome with the right tooling and the right processes. In fact, the right tooling can actually enable fully remote design handoffs to be better than the ones we used to do in the office. Interacting in Jira and Confluence about a Figma design is much more structured, traceable, and deliberate communication than an ad hoc hallway chat.

What are your pain points as a designer? Are they different to the above? Could any of the solutions we’ve talked about work for your team?