This article was originally posted on Florian's Medium

As a designer, there have been countless times when I found myself grinding my teeth, anxiously wondering how developers would interpret and implement my designs. Each inconsistency or deviation, no matter how minor, would trigger a chain reaction: more time spent in Slack or Jira, a product manager knocking on my door, eager to ship the product, only for the cycle to repeat itself in the next project. Sound familiar?

If not, you might be working with a robust, well-governed design system that has a strong bond between design and code. You are one of the lucky ones that might not get as much out of this article as all of the other designers (and engineers?) that live in component limbo.

In the fast-paced world of startups, and even in more established companies, this disconnect between design and development is a persistent problem. Components are often not standardized in code, despite being meticulously crafted in design systems. The result? Inconsistent user experiences, frustrated teams, and delayed product launches. While some designers are fortunate to work with developers who are passionate about design or extremely detail-oriented, not everyone has this luxury. Worse still, many designers don’t even realize they can take steps to mitigate these issues.

From the beginning of my career, I’ve been a strong advocate for Design QA — a process that ensures a higher quality of design implementation. While it does require some extra effort, the benefits are immense, not only in terms of the final product but also in fostering a better working relationship with developers. Let me share how I’ve implemented Design QA across different teams and projects.

Before handoff: Setting the stage for success

Design QA doesn’t start at handoff; it begins long before that. The key is to tailor your preparation to what your developers need and prefer. Whether you’re using annotations, a handoff document, or a combination of tools, the goal is to create something your devs can and want to work with.

One lesson I’ve learned from working with multiple teams is that flexibility is crucial. Different teams may prefer different handoff methods, so it’s important to be adaptable. Once you’ve figured out what works best for your developers, you can make the necessary adjustments. Much of this process revolves around tokens and components, as this is where you can gain the most ground. However, Design QA extends across the entire implementation of the feature you’ve designed.

Define components and clearly flag them as such

One of the biggest challenges I’ve faced is dealing with inconsistently implemented components. Whether it’s wrong properties, missing states, or inconsistencies with other instances of the same component, the root cause often boils down to a simple misunderstanding: developers aren’t always aware that something should be treated as a component.

To address this, I began clearly pointing out in my documentation which components should be used where, and whether they are new, modified, or reused. If it’s a new component, it’s essential to reference the entire component, not just one state of it. This can be done by linking back to your design system or laying it out on the page where the developers will be working.

Point out past implementations

When you want to ensure that developers reuse or modify existing components, it’s helpful to leave annotations or remarks in your documentation pointing out where the component already exists in the product. This allows developers to reuse code from those areas, reducing the risk of inconsistencies.

Moreover, this practice can spark conversations. If the existing component doesn’t fully meet the needs of your new design, developers are more likely to reach out to you, leading to better outcomes.

Write a light testing plan

Just as QA engineers create testing plans, you can write one for yourself when the implementation is ready. This ensures that you don’t overlook any details, even if some time has passed between handoff and testing. Go through the design systematically, covering all user flows, and pay extra attention to new components, ensuring all states are tested.

If you’re worried about the time commitment, consider using AI tools to help draft your testing plan. This can be a significant time-saver while still ensuring thorough testing.

After handoff: ensuring quality through collaboration

Once the handoff is complete, your work isn’t done. In fact, this is where Design QA truly shines. It’s crucial to maintain communication with both QA and Engineering teams.

Talk to QA and engineering

If this is your first time implementing Design QA, make sure to communicate your plan to QA, a trusted developer, or ideally, both. Approach this as a collaborative effort rather than a critique of their existing work. Encourage them to reach out if anything is unclear during development.

Most organizations have a test environment where features are available before they hit production. Ensure you have access to this environment so you can start your QA cycle at the right time. The goal is to catch any issues before the product goes live, preventing potential user confusion and additional work for developers.

Track project progress and chime in at the right time

Now it’s time to observe and be ready to test. Keep an eye on project progress and be prepared to jump in as soon as the implementation is ready. Ideally, your team will ship iteratively to the test environment, allowing you to provide feedback early and avoid a rush of corrections at the end.

One effective strategy is to group functionality and requirements into user stories for your developers. This approach, though it requires alignment with the whole team, can significantly improve the testing process by allowing you to test entire flows as soon as they’re completed.

It all comes down to… communication

Even if implementing all these steps seems daunting, many of the problems we face as designers stem from a lack of communication. By simply talking more with your team, you’ll likely see improvements without needing to establish a rigorous process right away.

When the time is right, make incremental changes, and you’ll gradually be able to introduce new tools and processes that make the development process smoother and collaboration much more effective.

Isn’t there a tool for this?

When design and development workflows start feeling repetitive or tedious, it’s natural to look for tools to simplify things. The design-engineering relationship has been a key focus in recent years, giving rise to tools like Figma’s Dev Mode, Zeplin, and design system management platforms like zeroheight and Figmayo. Additionally, the emergence of the Design Engineer role reflects the growing need for dedicated resources to bridge the gap between design and code.

However, even with these tools, there’s still a fair amount of manual work involved. While design QA remains a crucial part of the process, these tools rely heavily on human input. One notable exception is Jux, which operates as a true source of truth between design and engineering. Jux allows designers to create and modify components just like they’re used to, while simultaneously providing developers with the exact code needed for those components. This seamless integration ensures that changes made by the designer are reflected in the code without the usual back-and-forth, reducing many of the pitfalls inherent in the traditional design-engineering workflow.