Make design QA official

Stop undermining your design efforts. Start doing QA.

Have you ever fired up your company’s app and asked:

Yikes, what’s this?

Was this update really released without telling me?

Guess there’s no Design QA happening…

Why do I still eat Chipotle after the numerous E. Coli outbreaks?

Well, if this has happened to you as a UX designer (not getting the chance to QA what you’ve designed) I empathize, sympathize, ethnographic-ize… I feel you. It sucks.

What is Design QA?

Before we continue on, let us talk about Design QA (Quality Assurance) and it’s importance. Design QA entails:

• Reviewing the visual design, micro-interactions, and animations of developed software (code) before it’s released.
• Noting any inconsistencies and working with your team to prioritize and make the necessary fixes.

However, after speaking with teams around the world, we continuously hear how Design QA is something rarely talked about, respected, or codified internally. This is a big problem…

Why do Design QA?

When Design QA is not done, it leads to UX debt — also known as a warm pile of design-garbage. Thousands of differing hex values, font-sizes, and button styles continuously get thrown into your product every sprint. This process miraculously transforms it into an obese hoarder — petting it’s 34 cats whilst scarfing down microwaved hot-pockets. This can weigh your tool down till it either collapses or your company decides to do a complete rewrite.

UX debt can also weigh you (the designer) down mentally. Product design is a team sport — one where we have to rely on others to help us put forth a great experience. When we have to look at a “very far-from-pixel-perfect” feature we worked on or worse — hear complaints from our users — this can make us feel:

1. Bad at our jobs.
2. Frustrated with our teammates.
3. Lacking the motivation to work hard on future-features.
4. Keanu Reeves in John Wick 2: All-black-attire coupled with resting-b*tch-face.

Basically — Design QA should be one of the most important areas of our workflow, which we need to start concentrating on. If we don’t, we completely undermine the weeks of user research, brainstorming, cross-team collaboration, iterations, and testing we do prior to passing our work off.

If Design QA is so important — why is it often deprioritized?

There are several reasons (many of which can be organization specific) as to why Design QA is not cemented in the product development workflow. A few reasons being:

1. We can sometimes forget that mockups aren’t what users interact with. Our job doesn’t end the moment we share a Zeplin link.
2. Design QA can be insanely uncomfortable. Giving a fat laundry-list of issues to an engineer can suck. It feels like we’re grading them on their homework and not giving out the gold star.
3. The speed/velocity of shipping new features can often outweigh quality and design. This can be an issue of colleagues not understanding the importance of design and UI consistency within digital products.
4. We’ve been really busy trying to implement user research practices, design systems, cross-team collaboration activities (journey maps, affinity diagrams) and so forth into our team’s processes — that we haven’t had the time to fight for Design QA…yet.

Make Design QA official

With all that said, it’s time we fight for Design QA and make it official. As listed above, there are some great reasons as to why this will be a tough battle— but it’s something we need to do. Here are some potential ways to help:

Save your team time.

When selling Design QA, talk about short-term vs. long term time and cost savings. Design QA will add a few hours to your sprint. This isn’t insignificant, however, if you put this off — you’ll end up with a product so inconsistent and trash, you’ll have to spend months re-engineering and re-designing it entirely. That is time and money your team could be spending building new features/products instead.

Track Design System ROI.

If your team is in the process of or has already built out a design system, then Design QA is necessary to see any return on that investment. Design Systems are incredibly difficult to build, but more importantly, actually adopt. By implementing a place in your process for Design QA — you can ensure that all that time spent was put to good use and has resulted in a consistent experience.

Prioritize your issues.

While you’re making notes of inconsistencies on your site, make sure to prioritize them. This lets your teammates know you understand what’s needed to fix now versus what can be put on the backlog for later. I often do:

• P1: This is a blocker and needs to be fixed before release.
• P2: If the fix can’t be done this sprint, it’s OK but let’s make sure to add it into the next.
• P3: A fix here would be a great nice-to-have.

Provide context.

When giving feedback, make sure your notes are clear, contextual, and organized. If you’re sending out feedback in Slack, Jira, and emails — this will become cumbersome and confusing for your team. Furthermore, this makes Design QA seem like an “unofficial” activity if it’s happening haphazardly. Best thing to do is include screenshots, annotations, URLs, and potentially some metadata (browser, viewport size etc.) all in one, prioritized, and organized location. There are some tools, which can help you do this including InVision, Marker.io, and Pastel — but I personally use Toybox.

Be inclusive.

Lastly, make sure you include engineers, product managers, and QA testers into your design process. This will help your teammates understand why you made certain design decisions and their importance. Furthermore, it will make them feel more comfortable including you into their development workflow.

Design QA, like most things, is all about open and honest communication. This makes it all the more complicated to implement — but also incredibly important. Great products and incredible experiences are built when everyone on the team feels they have a safe platform to both give and receive critical feedback. Happy building.

— — — — — — — — — —

I’d love to hear more about your Design QA process and challenges. Feel free to DM me on Twitter to chat: twitter.com/bmaho2211

Thanks for reading!