Design QA Deserves a Seat at The Table

Design QA deserves a seat at the table

Have you ever experienced looking back and forth between your mockups and the actual deployed design in production, and asking yourself the question:

How did it turn out this way?! What happened?

Your expectation didn’t meet reality and the worst part is, you’ll be adding these changes to the next sprint which will take 2 – 3 weeks to be deployed. In short, the wonky design (which you didn’t really create) will be left hanging in the app and be seen by thousands or millions of users (depending on your product’s user base).

So what really happened? The answer is simple. A Design QA process was robbed of having a seat at the table.

Months ago I experienced the exact same thing. The new version was deployed in production and I was totally excited to see how my work came out. I opened the app and the unexpected happened— the padding, alignments, font sizes, responsive design, and elements weren’t even within an inch of where I expected them to be. It looked like the designer (which was me) didn’t have a shred of alignment sense to their name 😂 But it did wake me up to important learning, which was that Design QAs must happen.

So what is a Design QA?

It’s the process of reviewing visual designs, micro interactions, and copywriting by cross-checking the developed design vs. your handed-off design before production to find any inconsistencies.

The goal of a Design QA is to ensure that quality and expected design output are deployed during production.

The challenges of a Design QA

Design QA can be really challenging at first. It can eat up time during a sprint and can also be pretty expensive. But adding it to your process ensures a quality output that will give your users better experiences.

To begin with complete transparency, I have listed three steps of Design QA and their corresponding challenges:

Step 1: Making Design QA part of your workflow

It’s a no brainer that in order for a Design QA to happen, it first has to be part of your product development workflow. Your product task board could look like this:

Design QA deserves a seat at the table

But since a Design QA now has to take place, we meet the first challenge. We have to expand our old task board to add the following:

Design QA deserves a seat at the table

The challenge with adding Design QA into your workflow is that it makes the whole product team feel like a whole other testing is being added (oh well, it’s true!). Developers think that they’re being bombarded with a simple thing (fixing padding is so simple!) when, instead, they could focus on fixing bugs.

However, if we continue neglecting Design QA and the product is out, we’ll realize that no matter how optimized our code structure is, if the interface looks totally out of place, all of our efforts will be futile.

Users interact with the interface, not with the code.

If we’re able to successfully integrate Design QA into our product flow, then a great ROI could happen. But before we celebrate, there’s still something we need to prepare ourselves for, the Developer’s hand-off — our holy grail.

Step 2: Preparing Developer’s hand-off

Developer’s handoff is what I consider the holy grail because, if not done correctly, chaos may ensue. Expectations won’t be met. Dev handoff is a process where you send out your design files (Sketch files, Figma files, JPEG files, PNG files, PSD files etc) to the mighty developers on your team 💪.

In our case, I upload our Sketch files in Zeplin where our developers can download the assets, see the specs (padding, height, font size), and copy paste code snippets. But it doesn’t end there. Together with the Zeplin link that I share with them, I also provide Design specs documentation — this is where the second challenge comes in.

Creating the Design Specifications is a pretty tedious task. A Design spec is a document where you as a designer have to get into the nitty gritty of your design, documenting things like Navigation path, Micro-interactions, and Conditions. I have created tables below to show you what these look like:

Design QA deserves a seat at the table
Design QA deserves a seat at the table

Take note: You can create your own design specs documentation. It’s just that this format works for us since we’re just two designers on our team. Feel free to use this as a base and tweak it according to your preferences 😉.

From the looks of the tables, you can already see why this is a tedious task 🙄. This part will seem even more daunting, because you thought you were already done when you sent out the Sketch files, and it turns out there’s more! Because you still have a full-length document to develop👏.

Even though it sucks (at first), this documentation will ultimately serve as your source of truth. It works as a roadmap for you and also for the developers. And in the long run, it saves them from having to poke you every day to ask, “Hey! What happens when a user clicks this?”

Looking at the Design specs, I would say there’s still room for improvement. Maybe some of you are using Invision Prototype or Framer Prototype as a substitute for all of these, and all the developers have to do is try for themselves how the prototype works. But above all, having this document gives a clear path for the whole product team. It gives direction and it sets the scene for everyone.

Step 3: The QA itself

As you’re going through the Design QA, you’ll get to understand that having a pixel-perfect output is just icing on a cake. The most important part is to make sure that the developed designs are as close to how you made them as possible. It doesn’t have to be perfect. It just has to be close enough.

Also, there will be times that some of your designs aren’t be implemented very well, especially if developers are on a tight timeline. Enter the challenge of prioritization. And here are the 4 prioritization levels:

This design is…

  • Priority 1: Big impact. It needs to be fixed now.
  • Priority 2: Big impact. I’ll create a workaround so it can be fixed now.
  • Priority 3: Low impact. I’ll carry it to the next sprint .
  • Priority 4: Low impact. It’s a problem for another sprint 😂.

The first priority is all about urgency and importance. You know that if this design goes unchecked, it will affect a major user flow and your metrics won’t be achieved. Second priority fixes focus more on importance. The feature will make or break a major user flow so you’ll create a workaround that your developers can confidently deliver on time.

Finally, we have third and fourth level priorities, which almost share the same level of importance as the first two, but not the same level of urgency. Third priority designs can go unchecked for the time being due to their low impact but they need to be solved in the next sprint, while fourth priority designs can be addressed in the next 2-3 sprints, depending on the sprint timeline. In short, I call fourth prios ‘a problem for another sprint 😉.’

Why include a Design QA?

So now, why have a Design QA? Why does it deserve a seat at the table?

If a Design QA isn’t part of our workflows, we’ll find ourselves in 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

Design Debt is pile after pile of small abandoned design details that range from adding 10px padding to buttons, using the correct hex color, to implementing the right font sizes and much more.

Due to the small size that, after all, is “just one line of code!” 🤷‍♀️, these small details tend to be blissfully ignored until they all pile up. But after numerous sprints, reality hits hard. Your team realizes how ugly-looking the design is and a complete rewrite is the only solution you’ve got.

Basically, Design QA could be a challenge at first but we should keep in mind that it is an important part of great product development. Always remember that users don’t interact with your highly optimized code, but rather with your high-quality, kind interface.

Happy Designing! 😎


If you want to contribute to next the issue of Phase Magazine, just drop us a line:

Mhariell Mosqueriola Avatar

Mhariell Mosqueriola / Lead UX Designer @ Airfrov

Riel is a Filipino Product Designer working as Lead UX Designer in Airfrov, a Singapore based e-commerce startup with the mission of connecting people to the best things around the world. She is a designer who loves solving human perceptions. Apart from these, she's also a speaker and loves sharing her knowledge through her Medium account.

medium.com/@rielm