What is the importance of Design QA?
What I learned when initiating and conducting Design QA in my team, and the impact it generates.
How it Started
Back in 2020, I had the opportunity to initiate and tinker around how to create a better collaboration between the Design and Engineering team. As the team grew, more and more projects were getting developed. There, I noticed that there were some discrepancies between what designers crafted in Figma and what was produced in our app.
Back then, product managers and the Quality Assurance (QA) team often asked the design team whether the mismatches that they found during the staging period, which is a period where the QA team makes sure that the application is operating smoothly before releasing it to the public, were expected or not. Turns out, there were a lot of things that were not expected. It was then that I realized that the designers here had little-to-no visibility in how their design was being implemented to the app.
In Traveloka, Tricleloka has been the main framework for designers to execute their work. In fact, the Design QA belongs to the last phase in the Tricleloka framework, where the design team is expected to check whether their design is implemented accurately on our app.
Why is this important? Well, this is to ensure our customers have the expected experience in regards to what the design team crafted beforehand.
But don’t we have the QA team to do that?
That was the question I had in the early time of building the Design QA activity.
After doing a little bit of digging, I found out that the Engineering QA team put more emphasis on the feature/product functionality. In other words, the Engineering QA test focuses more on whether feature X runs well so that users can get their job done. Therefore, there was not really an in-depth testing towards the actual components, meaning the spacing, margin, padding, etc.
From the picture above, there was a minor pixel misalignment that happened during the staging period which was not expected from the designers. It might look minor, but the design among our products would look inconsistent and messy between each other, and the more those problems persist, in the long run, the less trustworthy we look as a brand. Therefore, it’s best to avoid that.
At the end of the day, all elements that will be experienced by the users, should look and feel the same as the initial craft by designers, therefore Design QA is required to fulfill the requirements.
In the end, this does not mean the Design QA competes with Engineering QA. They should complete each other since each of the QA emphasizes different parts of the product/feature than the other. This way, we can see better results from the functional, as well as the visual, aspects.
The Initial Phase: How to Start a Design QA
It all begins by coordinating with the QA team to know what projects are being released and after that, I can mark the calendar when the Design QA session will start in that month for the designers. The Design PIC (in this case, me) usually starts by coordinating with the Engineering QA team to list out which projects that were released the past month.
After that, I delegate the listed projects to the relevant designers that were involved in the project. This way, the designers would not need to gather the context of that project from zero, they could just start right away checking the components, interactions, and microcopy.
In order to begin the Design QA sessions by the designers, the Engineering QA team would list down on how to perform the QA step by step (e.g. you must select a specific inventory or a search for a particular flight route to see the feature), which eventually will lead to the feature to be tested. This eliminates the time for the designers to figure out how to perform the QA themselves.
Pro-Tip!
To get reminded of the Design QA activity, utilize the auto-remind function from your working messaging platform for you and the QA team.
The technical phase: What to Check On
There are 3 main aspects to be tested (sorted from top to bottom, architecturally):
- The flow
- The layout
- The component.
The flow represents the interaction between pages and the feedback after users tap on a particular component (let’s say a button). The layout represents the order of components within a page (the Information Architecture), whether the order matches with the designer’s output. Whereas the component represents the look and feel of the components (the micro details).
The way we conduct the Design QA is by setting up our phones with the staging apps, therefore we can compare the component side by side with Figma as our design crafting tool.
Later after delegating the task, the designers conduct Design QA activity at their own time since this would provide more flexibility in between doing other tasks, as long as the bugs are reported before the next staging.
Being Pixel Perfect: What to Focus On
What I found out is that most of the time, the inconsistency arises from the component, not the flow or the layout.
The flow and layout should not be too much of a problem since they should be much more visible by the QA team first before even the Design QA session. However, the components often have issues with the pixels, notably the margin, padding, spacing, and the components themselves.
When the designers discover the mismatch, they can report the bug using Jira, which is a tool used by the Engineering and QA team. Through it, they are able to attach images of what it is supposed to look like.
Wrapping Up
All in all, Design QA is an important step for us to ensure that our design output is translated well when being used by public. After all, who doesn’t want their craft to look exactly the same as the agreed output?
More importantly though, Design QA will improve collaboration between the Design and the Engineering QA team, and give designers more exposure to different functions and how they work.
It also trains us to be more detail-oriented when crafting our design output. Because, as we conduct more and more Design QA, we will then start to notice the gaps between the design and engineering development. And once we realize those gaps, we can take proactive steps to minimize that gap.
Such an example in my team is that we started to make pixel guidances for any new components, like the picture above. We wouldn’t have realized that this detail is needed if it were not for Design QA. So by conducting design QA, not only we are trained to be more detail-oriented in our output, but the number of design bugs regarding spacing, margin, and padding would immensely be reduced as well, thus giving our users better experience.
Editor: Ricky Ronaldo & Yunita Wongso
