In today’s episode of Design Life we discuss the design QA process. People use many different terms to describe this process but basically to us it means reviewing the build. Although we work for companies of different sizes and on vastly different kinds of projects, there are more similarities between our QA reviews than there are differences. A QA is a process that every designer implements as the project comes closer to completion, as a designer you need to check everything is good to go for your launch date. Hitting snags at the end of a project is common, we discuss how we’ve evolved our design QA process to get the best results.
Some companies have dedicated QA teams. It may come as a surprise but Uber is not one of those companies. Instead the QA process falls to the team working on the project. The team gets together towards the end of the project and has a ‘bug bash’ where they test the product as much as possible, throwing everything but the kitchen sink at it.
Finding a QA process that works for your team is a process of its own. Compromise is key. Try to get both your engineering team and the design team to buy in on the process because if it doesn’t work for one team, it won’t work for either team in the long run.
Sometimes visual QA feedback can get lost as the project gets closer to launch. The top priority is the overall functionality of what has been built. As a designer you have certain scope to prioritise which changes need to be made first and which can be made after launch if necessary, so that visual QA feedback doesn’t get forgotten.
Try to find time to reflect on the QA process. It is valuable to do as a design/engineering partnership to see what worked and what can be improved, particularly if the same team will work on projects together in the future.
01.20 – Check in
03.55 – QA process at Uber and Convertkit
13.10 – Pain points in the QA process
22.55 – Reflecting at the end of the QA
