You did a great UX design process and the design looks good, you feel comfortable delivering it to the developer, but when it is implemented, there are gaps between the implementation and the design. In order to overcome this issue and to create products that look close to the design, the designer should implement a design QA (quality assurance) process. But, how do you report all your findings and share them with the developers? In this article, I will try to answer those questions.
What is design QA testing?
Quality assurance is a process the designers do after the developers implement a solution, in which they review all the functional design and visual designs to ensure the development team implemented the design correctly into the product. It is not like the quality assurance testing that the QA team makes, since it focuses on design and development gaps, not normal bugs.
Why do we need design QA?
There are always differences between the design and the final implementation. It could be that the UX designer didn’t explain the solution well, or the engineer didn’t pay attention to certain details. Because of that, the designer needs to review the implementation to make sure everything is implemented as designed. So the team knows the product will deliver close to the design and is of high quality.
Common Challenges in the design QA process
There are a few challenges the team needs to overcome with design QA.
Design QA isn’t part of the product development process
Design QA usually happens between the development process and QA testing, but not all teams have it. In the event that this step doesn’t exist during the development cycle, the designer needs to convince people of its importance.
Lack of time
Sometimes the product designer doesn’t have time to do quality assurance on a design. The team is in a hurry to deliver the solution right away. In that case, two hours of design testing can also be a big help.
How to organize your findings
To be able to organize your findings, I recommend building your own method that you’ll use every time you need to conduct design QA. By building a process, you will make this step fast and easy. Here are some of my favorite techniques:
Make a template to explain the issues
Create a template and write all your findings there. In my experience, the template should have three key points:
- Title.
- Bug/issue description.
- Expected behavior.
You will be able to tell the developers what is wrong and how to fix it. In addition, you can add a link to a video explaining the bug, the date you found it, and what its priority is. That way, you have everything organized in one place. If you would like to see an example, you can check out my Bug Reporting Template in the Figma community.
Take a screenshot
Taking screenshots of the product and painting over them is the easiest method (but also old school). You can add marks in Figma or add notes with your tablet pen if you want to be more flexible. This technique is good for pointing out visual design problems and grammatical errors.
Make a video
When there’s a problem with an interaction or a flow, it’s difficult to explain it with images. Therefore, you may wish to record the interaction or the process and show it in a video. You can also talk about the bug inside the video. That will make it easier for the engineer to figure out what is wrong.
This tip is super useful if your team is in a different time zone. It will save meeting times that are difficult to have because of the time difference.
Put everything in Figma
My favorite technique is to add a page in Figma to the same file I design the solution and organize it in lines. Each line represents a bug. On one side of the screen I like to put the bug templates, and on the other, an image of the bug and how it is supposed to behave. This works for me because:
- I can take a screenshot of the product and paint on top of it in Figma to explain what is wrong.
- I can paste the artboard of the current behavior from the file when I need to explain the Expected behavior (no need to move to another file).
- I believe that the design QA is part of the process, and I think it makes sense to put everything in one place.
Techniques for sharing findings with developers
Keep in mind that you should talk to the developers and find out how they want to receive the information. When both sides use the same method, communication is improved and friction is reduced. I worked with many development teams, and each has its way. Therefore, take the time to define how you and the developers feel comfortable about sharing the information. Here are a few tips on how to share your findings with the developers.
Every bug has its own ticket
You can open a ticket in your task manager program (Jira, Monday, ClickUp, Trello, etc) for each bug you find. Simple, one bug, one ticket. The downside is that it is time-consuming.
Open one ticket for all bugs
I found this technique to be most useful and easy. The first step is to organize everything in Figma as I explained above. Each bug has an explanation and two images, one to explain the bug, and another to explain the expected behavior. When it’s done, open a ticket and post the link for the Figma file. That way, the developers can see all the bugs you found during the testing in one place.
A Special board to report design QA bugs
I worked in a team where we had a kanban board for reporting design QA bugs. I had to open a task for each bug, and then the developers entered this board and started fixing them.
It’s very similar to the first technique I shared, but the difference is that we leave the main tasks board cleaner. The downside of this technique is that it’s a lot of work.
Meet with the developer and discuss the issues
Developers sometimes fix bugs without opening a ticket. They see it as part of the development ticket, so no need to open a new one. In that case, you speak with the developers, explain the issues, and compile all the bugs into one document. This technique works well when the engineer begins working on the issue right away.
Bug fixing challenges and how to handle them
Talk to the developers and show them the bugs
Communication is the key. Once you have organized all the information, take 15–30 minutes to review everything with the developers. It will make communication easier and reduce friction between you and the developers.
Prioritize and postpone issues for future releases
The developers may not be able to fix everything you found during testing due to a lack of time. In that case, you can prioritize what needs to be fixed now and what the team will fix later. If you do so, I recommend you open a ticket for the issues that are not resolved. By doing so, the information will be saved in a place that everyone can see. One more thing, the decision to postpone bug fixing should be taken with the entire team to make sure everyone is on board.
Solve small bugs quickly
When you find a small bug after doing the design QA, like a color error or a misspelled word, try to fix it with the engineer quickly. Take 5 minutes with them, explain it to them, and have them fix them at the same time. That’s faster than opening tickets and documenting everything.
To summary
In this article, I showed you how as a product designer you can share the bugs you find during the design QA test. The article started with an introduction to what a design quality test is, why it is necessary, and how it differs from the QA software testing carried out by the QA tester. During the second part, I talked about how to document bugs. We saw that we could use a template, but we need to add a video or an image. Furthermore, there are different ways to share them with developers, from opening a ticket for each bug to opening one for all of them.
https://edwche.medium.com/design-qa-65d258dbdbf8