What is a Design QC?
Visual communication is the most effective way to pass product information to the audience. Being a designer we create eye-pleasing visuals, making sure our product is conveying the exact message to the user about what they are looking for. We provide the best solution and our client expects the same final output as a successful product. But what if they come to us saying, “The actual site is not that appealing as it was looking into the mockups. It’s not getting the response as it was expected when we approved the designs.”
There could be so many reasons for the failure of the final output, like lack of promotion, long loading period, functionality collapse, the site isn’t optimized for SEO and whatnot. Bad UI is one of the reasons people leave a website within 10–15 seconds. They like to explore a product/website which is visually appealing; so many times they don’t even bother if it’s functionally working or not. As a visualiser, we can make sure about one thing that our product is getting developed as per approved designs. There are tools like Zeplin & Invision which help the dev team in giving the exact specs but they can not make sure if the product is on the right track or not. At this point design QC comes into the picture.
Design QC is nothing but a design review in which we make sure whether our product is getting developed as per brand/design guidelines or not. Our responsibility doesn’t end after handing the designs over to the development team, we have to make sure the brand visual strategy is being applied & consistency is maintained to achieve the business goal.
Why is it needed?
Consistency is the core element of good visual design. It won’t stress out your users and can help in building trust in your product. As your product scope grows there are chances to lose the track of visual guidelines. New features, flows, keep getting added and it becomes very crucial to keep track of. There might be a case of having a huge design & development team working on a single website or an app. Every individual has his/her own way of working which may affect the final output. Also, they can lose track & attention to details while achieving an expected goal of tickets in the respective sprint. To make sure all the team members are on the same page, it’s the designer’s role/moral responsibility to guide them in the right direction.
One of the scenarios can be explained here. Browsers are getting better these days. They allow users to control their browsing experience which I would say is not that new. Adaptive/responsive layouts change as per the device due to fluid grids. Designers create visuals using units in px. It’s an absolute unit and prevents design elements like fonts, margin/padding, grids from being resized when the user zooms the website. Rem is a relative unit. It helps in setting units based on the units of the root HTML element. It also allows you to scale the entire project by changing the root unit value. That’s why developers use it. But they need to convert px into rem as you know 16px = 1 rem. Here designers need to check thoroughly if everything’s in the place as while developing our pixel-perfect design may change.
It’s good to include this step in the project right after the developers are done with their coding and before they hand it over to the testing team which can save a lot of time. It’s easy to fix the issues when they are small and are at the initial level rather than handling the chaos.
How to do it?
Your effortless design QA depends upon the process you follow. If you take a bird-eye view in an initial stage & plan things accordingly, it can save lots of time & energy. Start creating your components using Atomic Design principles which will be reusable. The reusable component approach helps a lot not only in maintaining consistency but also in making changes all over the site with less effort.
Step 1: Create a checklist of components/key screens & make everything development ready
After you are done with all your creative stuff, start making a checklist and create a component library. A component library is always a perfect guide for a dev team which includes all your assets like icons, images, color palette, inputs, headings, body text, responsive elements, etc., so whenever you make any changes to it devs can have an updated version. Ensure you also include hover states & transitions (if any) into it. You can also create clickable prototypes to give an exact idea about how components should behave.
Step 2: Start with design QC
After you provide everything along with Zeplin or Invision access to the dev team, have the latest build on your local machine so that you can thoroughly review the implemented UI version. Go through each n every page and confirm the overall interaction of the site. Reviewing & considering your key pages & global components will help you to analyze your product with a broader view & not a single element will be overlooked. Check each and everything like, is the design/components consistent all over the device? how do elements animate? are components having equal & expected margins in between? do typography and color palette match with the design library? etc.
Step 3: Document your observations
In this process, you’ll discover the gaps which need to be filled. Once you get to know the same you can start documenting all the points. You can choose any way you & your team are comfortable with. I’ll tell you two of them which I use the most.
The first way, take the screenshots of the page/component which you think is not as per visual guidelines. Include those into a document along with your observations like how the current UI is & how it should be. Try to give as much detailed information as you can like margin, padding, font size, color, etc. You can also add the component library link for the respective page/component through which dev folks can compare the gap there itself.
The second way, you can create an excel sheet template as a sample reference & put all your observations against each component along with the library link. The more complex your product is the larger your document is going to be so coordinate with your teammates and mutually finalise the option you want to go ahead with. You may need to do 1–2 more revisions of this process to check if the details which you had jotted down are fixed or not.
- Design & development both things go hand in hand, so developers should be involved in the design process to check the coding feasibility for any complex design. Sometimes due to 11th-hour scope change, developers implement new requirements in coding itself & design has to compromise. At these times designers should be involved while developing the pages in terms of following the brand guidelines.
- After releasing the build testing team starts their work of analysing the brand quality. But before they come into the picture, a design QC step should be performed, where you can review the coded UI and fix them along with the dev team at the right time.
- Agreed that your team members don’t get time (according to them) for these small changes, as they are in a race of chasing the goal of closing the tickets. In that case, if design implementation is being neglected you can make it an official step of the process by assigning an extra ticket. Not necessarily all changes have to be done in the same sprint; you can prioritise them and assign accordingly or there can be one more sprint named Hardening Sprint in which all such technical or visual fixes are done and closed as per the priority.
- It may happen that you’ll be unable to implement each and everything due to some constraints like time, approvals, etc. which you can’t control. What you can do is set up a necessary process, implement and communicate about it from time to time, so that your efforts are seen.
- There’s also a possibility that some part of the new requirement is not feasible to implement. In that case the designer, developer, PM & respective team can take a call with the stakeholders.
The Design QC can be a complicated process but is an essential one. As developed code needs to be tested similarly to the implemented UI too. The first thing that will connect users with your product is the design, not the code. The QA engineer will always be there for product testing but as the designer is involved in each and every process right from the beginning, s/he can lift up the product more effectively. So designers should take the lead and make sure that their creativity is reflected in the finalised product.
After all there’s a saying:
“Good design is good business.”
- Thomas Watson Jr., businessman, second president of IBM
Copyright: All the images used in the article are used for reference only and the ownership belongs to the Source.