Great customer experiences don’t happen by accident. In digital product design, the customer experience encompasses everything that the product team does; development, design, DevOps, and QA — everyone’s role impacts the customer experience but especially the design and user experience. Since I’m a product designer, there’s a particular part of the process that I’m obsessed with, and that’s making sure that designs get implemented as intended. What does this mean? It means ensuring that design work is coded to closely if not perfectly match the actual designs.
Why is this important?
Consistency is one of the main tenets of good product design. Over time as a product is designed and developed inconsistencies inevitably crop up. Over time this can add up and turn into “design debt.”
Design Debt affects the integrity of the user experience. This is what happens when a bunch of incremental changes collect over time and yield a disjointed, inconsistent, and patched-together experience. — Design debt
While it may be challenging to address 100% of inconsistencies all of the time, doing Design QA is a big step towards combatting design debt.
Design QA can be a challenge
There are other fundamental flaws that can make Design QA a challenge:
- Teams or companies do not understand or value design enough to create a process that fosters good design outcomes → “the feature works”
- People don’t see the difference between a design and a poorly coded version of it → “looks good enough to me”
- The focus of teams is on speed and feature delivery — and visual integrity is easier to cut than coding → “we don’t have time for it”
Speed vs. quality
To elaborate on the last point, as a product team works together, they sometimes run the risk of getting into feature delivery mode and shipping. Teams can lose sight of the bigger picture and attention to detail while trying to close as many tickets as possible before the Sprint ends. As a team races to the end of the Sprint and increases velocity, this may create a scenario where the integrity of the design implementation can fall to the wayside as a “time-saving” measure.
Collaboration is good, but it’s not enough
I’ve written before about how teamwork and collaboration are necessary requirements for product teams to do great work together. Co-designing at the conceptual stage, designer and developer pairing, using tools like Zeplin to create transparency and bridge the gap between design and CSS; these are all great and do help, but they don’t take the place of having a designer formally sign-off on coded designs before they are shipped.
This is where Design QA comes in! ✨
What is Design QA
Design QA (QA = Quality Assurance) is merely a step in the process between development and testing. It’s a chance for the designer to:
- Review the coded version of the UI prior to testing
- Work with the developer(s) to make updates to the UI in code
Maybe you work on a tiny team and are already working very close together doing some version of design QA already; perhaps you work at a company like Pivotal where designers and developers spend time co-working together and design QA is built into the workflow already. If not though, it’s very easy to for the quality of implementation to lose its place in the process.
Design QA as part of the workflow
Your standard workflow might look some version of this. If your team works in any sort of Sprint and moves a ticket from one part of the development lifecycle to another, your (design) work may be in any one of these categories at any given time.
In a workflow like this, how do we ensure the integrity of design? When a ticket is done in development, it’s usually up to the developer working on the ticket — or the product manager to move it to testing. Sure, teams can get into the habit of trying to do some version of Design QA without having a step in the process for it, but that breaks down quickly; people forget or decide for themselves that the design implementation is good.
The more important question is: if design implementation is essential, why don’t we just have a step for it?
By making Design QA a deliberate step in the process, it can’t be skipped. It’s also recognition that design implementation is an important part of the process that the team values. When we account for Design QA in the process, the workflow mentioned above, now looks more like this.
Include developers in the design process
Just as it helps for designers to be involved when designs are being coded, it’s also key to include developers in the design process.
Design and development are really two sides of the same coin and the more isolated they are from one another, the more challenging the whole process will be.
To include developers in the design process, you can do things like:
- Discuss the requirements of a feature before beginning design to suss out technical details that may impact design decisions
- Sketch out initial design solutions together
- Share designs with developers throughout the process to get feedback
Most of the challenges we face in product design and development can be solved with mutual respect, communication and honesty.
Happy making!
Additional Reading
→ Why Developers and Designers Should Work Together
→ Tips for Designers & Developers Working Together to Implement Great UI’s
→ How Designers And Developers Can Communicate To Create Better Projects