Did you ever happen to spot some inconsistencies in your product’s design that were not there in your prototype? The color being a bit different, some changes in the font style or micro interactions not working the way they are supposed to.
You think that some of these errors could have been avoided if a designer was shown the coded version before the app release. And you are not alone in thinking like this. There is a solution to combat this problem.
The answer is… Design QA.
So what exactly is Design QA and how does its implementation resulted in streamlining our product cycle. Here are some tips and tricks for you that we learned along our journey.
Defining Design QA:
Design QA is a cross verification process done by designers. It entails checking for any inconsistencies in your copy, visual aspects, micro interactions, and the likes of the code developed before the release of your product.
Why is it neglected from design sprints?
In many organizations, design sprints are very elaborate, taking a full week or longer. And this is prior to the developer hand off. Once this is done, designers move on to other projects with no further updates on the previous product. Bringing designers back for the review is not considered by many. And some other common reasons we hear for neglecting design QA are:
- A misconception in the design world is that a designer’s work is done after forwarding Zeplin links and Invision prototypes. But that is seldom the case.
- Design QA discussion can cause friction between designers and developers, making it an uncomfortable conversation to have at times.
- Design QA is seen as an add on step in an already elaborate design sprint. When teams are working under time constraints, collaborating with designers for more reviews is not ranked high on the priority list.
Why did we implement it in our process?
The reasons for design QA to be a part of our process is nothing different from what the experts vouching for it say. We pitched it to our clients explaining its importance and what benefits will they get after its successful implementation. Some major factors that drove us to inculcate it within our process were:
It’s a pretty underrated time saving hack
Design QA will be good for your long term goals. Getting a few extra hours of your designers is better than a few extra days of your developers to search, spot, and iterate for design inconsistencies after the app release.
Better collaboration between your designers and developers
When designers and developers are in the same room (or call) it will help in solving the issues at hand quickly. Your designers will be aware of the technical issues that developers are facing and will account for such issues in the future.
Developers will also get insights into how designers have envisioned the final product and code to bring out the same in the product.
No surprise design inconsistencies
A designer’s work does not end after a simple functionality test of buttons and interactions. Instead, they evaluate the design elements behavior right from the speed of the interaction to the feedback of an action being performed, will there be a slide-out option or slide in, you get the picture.
Minimum design debt
Design debt is accrued over time when small changes and improvements are kept for the next sprints every time they are brought up. As this pile keeps on growing, it results in a bad user experience. And there will be a point where no amount of small tweaks will make it better and you end up rewriting your whole product.
Integrating Design QA in our existing process ensured that we never went back to square one because of design debt.
You’re convinced that it belongs in your process, now how do you implement it?
We know that it is easier to say rather than execute any changes in your workflow. But how to transition from ‘thinking’ to ‘doing’? Here are some tips that have helped us in including design QA within our workflow.
- Start out together
The first and most vital thing that we have learned is to involve stakeholders from various product stages in the initial meetings. This helps in seeing the feasibility of the product’s features and setting the right expectations for everyone onboard.
- Sort issues on the basis of priority
You will face numerous issues when testing the final product from the design point. But not all these issues have to be solved right away, some can wait till the next sprint cycle or are the icing on the cake type features.
When discussing with your developers, define priorities to get the critical issues addressed before ones that are only for aesthetic value addition, this way you are making your developers life a tad bit easier.
- Have a checklist ready
We all know how good our memory is when we need it the most. Having a reference checklist when design QA is carried out will ensure that we don’t miss out on essential checks. Look for text alignment, colors, content placement and spacing.
You also need to check for the accessibility of the design. Here again, a checklist sorted on priority basis makes it easier for everyone involved.
- Start the review the moment you get your hands on functional prototypes
We believe that there is no fixed timeline that needs to be followed when it comes to review cycles. Infact, the earlier the review cycle starts, the better. Waiting till the last moment can lead to unexpected delays in the launch of your product.
Getting a designer review on the product’s features will keep the development going in the right direction.
- Give reasoning behind your feedback
Just saying that “this does not look/feel right” defeats the purpose of reviews. You should back your reviews with proper reasoning and even document them for references. This will not only help your developers but your designers as well to evaluate what they like the best and why.
Design QA has helped us ship perfect products reflecting the original design intents. This has worked wonders for us, especially when collaborating remotely. To get your stakeholders onboard, you can utilize the same reasoning that aided us in actively streamlining our workflow.
