How to integrate Design QA in your product development process?
You have probably heard about Design QA. But how do you actually integrate it into your product development process?
“The importance of Design QA in digital product design” defined DQA as such:
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
As you can see, while Design QA (DQA) sounds like a step, there is a whole process and a whole group involved. There are at least 3 parties: designer, front-end engineers, and QA engineers.
I established the design QA process in our organization and it has been running quite well for a few quarters. Let me share some learnings.
Communicating the process with visualization
I started by understanding our development process so I can find opportunities.
Basically, I can share the same “testing” stage with QA. The only difference is that I focus on the UI side, and they focus on the engineering side.
Most of the time, I review the new feature by myself. We also have meetings where the designer, PM, and engineer go through the implementation together.
By the way, I have learned to give very specific instructions. Instead of “this button is too closed to the right border”, use “move this button (circle in a screenshot) to the left by 5px”.
Before shelter-in-place, I sometimes sit down with our front-engineers to review implementation on their machines. At that time, I usually identify the bulk of the issues at that time and take a closer look when they are pushed to a staging environment.
Establish an operational rhythm with these measures
There were a few tactical measures that allow it to happen.
1️⃣ We have a weekly design scrum with all the UX designers, PMs, and front-end team lead. During this meeting, we not only review the progress of design projects, we also highlight the DQA tasks for the current sprint. Our Jira tickets has a field for the designers, so we are able to filter the engineering release board with that field.
2️⃣ Secondly, we join scrums for different product areas. As we hear about the weekly progress from front-end engineers, we will then know what items need DQA.
3️⃣ Thirdly, I would comment on the ticket after I reviewed the design. I will also tag the QA engineer so they have my sign-off to move it forward.
Cultivate a culture 😊
We are now running the DQA process smoothly, and we has less ad-hoc tickets that address design defects.
Designers have more time to design, and front-end engineers have less UI bugs to fix. Isn’t that great?
The other day one QA engineer asked me to validate a ticket as she didn’t see my comment. I was so glad.
What’s the design QA process like in your organization? Do you have any suggestions?
Please leave a comment below and let me know what do you think!
