Visual Quality Control
Visual Quality Control
A necessary step or another bottleneck of software development?
Hi, it’s Arek! Welcome to Fundament, a newsletter that enables growth in UX and product design. Not subscribed yet? Join for free now:
Collaboration between design and engineering can take different forms in different organizations. Designers can be more or less involved in software development, but whether they like it or not, they are essential to this process. I don’t mean that designers should code (although I think some should–I’ll explain it in another article), but rather, they should not switch to new tasks right after handoff.
Design in the software development process
Let’s take a look at a simplified process of developing a new feature:
Define: the problem is identified through product discovery.
Ideation: a designer works on a solution to the problem.
Validation: the solution is verified with the product team and users.
Handoff: a designer prepares the final documentation for engineers.
Development: engineers pick up a ticket on the sprint planning.
So far, so good. I’m pretty sure this process resembles your day-to-day job as a product designer.
But I also hope there are also two more steps:
Visual quality control: a designer validates the implemented feature before it enters the production environment.
Health monitoring: a product manager and a designer monitor how often the feature is used and whether users find it satisfying.
Read more about the point no 7 in of my previous articles:
Last chance to grab our latest ebook for FREE
Only until Saturday, 31 August, get our latest ebook, Portfolio Done Right, for FREE. Subscribe to Fundament to receive your 100% discount code.
Portfolio Done Right is a 90-page guide that will help you with:
Building an outstanding portfolio that lands (not only!) entry-level jobs
Structuring your case studies not to bore recruiters to death
Enhancing your resume so it’s shining yet simple
Writing compelling cover letters to grab the attention of recruiters
Getting prepared for job interviews and the entire recruitment process
What is visual quality control?
Visual QC is a step in which a designer can play with the implemented feature they initially designed and check whether it was brought to life as intended. It’s a stage when a designer can stay Stop and not let users see the feature if something’s wrong.
By some, this can be seen as a bottleneck.
A designer who dares to think he is a big deal stops the whole pipeline.
Visual QC, when done right, can clearly be beneficial. It can improve the final user experience and move product metrics to the green side. It’s the quality gate that stops half-baked features from rushing into production, cuts confusion, and avoids expensive rollbacks.
When someone tells you that you are unnecessarily slowing down the whole process, you are probably working in a feature factory, and someone should change their job. I have a suspicion that it should be your product manager, but it’d be easier if it were you.
When visual QC can be a bottleneck
A few years ago, at one of my previous jobs, we tried to introduce visual QC to our highly automated software development pipeline. Every JIRA ticket used the same cookie-cutter template, no matter its complexity. One of the senior product managers responsible for setting up the automation and streamlining the process for every product created seven or eight swimlines, already making it unnecessarily tricky. The only way he would consider when he heard about visual QC was to introduce another swimlane.
We created another bottleneck. Despite automation excluding all back-end or bug-fixing tickets, every task labeled with design or front-end had to go through the quality gate, vastly slowing down the development processes.
Where did the problem lie? Not every ticket required designers' action. Some were really small and irrelevant, not bringing significant change to any user flow. It didn’t make sense to check literally everything our front-end engineers were pushing to the staging environment. Without us going to JIRA and giving it a stamp, it couldn’t move forward.
As a result, we witnessed a blame game between designers, engineers, and product managers. It wasn’t a healthy environment for a number of reasons, but introducing visual QC as part of the already poorly thought-out development process definitely didn’t help.
One team, one goal
Both designers and engineers play in the same team and have one shared goal: make the product with the best user experience possible that people love and know how to use. The earlier everybody on the team understands this, the better for them and the product. That’s why visual QC shouldn’t be perceived by engineers as a tool that enables constant observation of their actions. It’s not something you bring to your pipeline when designers and engineers have trust issues (well, in fact, it can be one of the ways to help fight those issues, but probably not the primary one).
When adding visual QC to your software development process, you have to communicate the goal clearly. You want visual QC to ensure your users get the best experience possible, there are fewer bugs in production, and there’s nothing to be rolled back. It doesn’t exactly mean that with visual QC, you’ll only chase the errors made by engineers. Have you ever felt that a particular feature feels odd when implemented, but as a set of static screens in Figma, it looked perfectly fine? Maybe you should build prototypes and test them with the users before handing off designs to the engineers, but sometimes, it’s impossible to make prototypes for everything.
Giving designers more ownership
Odd things happen when the process I mentioned at the beginning of this article ends at step five. Designers design the mockups, hand them off to engineers, and… forget about this feature and switch to the next one. There’s no actual ownership of the work produced by designers. The responsibility and accountability are weakened.
Once you add visual QC to the pipeline, you force yourself and the other designers on your team to be more engaged and take on more responsibility for their decisions. If being a pixel pusher doesn’t make you happy and you want to have more impact on the product you work on, this is the first thing you should tick off to make it happen.
The nature of teams in today’s tech companies makes it super tricky for ambitious product designers to have an impact and feel fulfilled. Over the past few years, many responsibilities, such as talking to customers, facilitating workshops, or having ownership of feature production from end to end, have shifted from design to product management. The visual QC won’t bring it back, but it can be a stopgap of the good old days when designers were not just Figma monkeys moving rectangles eight hours a day.
Tips on performing visual QC
A few ground rules have to be set not to make the same mistakes that my team and I did a few years back and to avoid turning visual QC into a bottleneck of the software development process. Here’s a bunch of tips on how to make visual QC useful step by step:
During sprint planning (or another ceremony), discuss and decide which tickets (features) are significant enough to put them through the quality gate. You might want to check all new or vastly updated user flows and develop your own criteria for more minor tickets.
Together with your engineers, decide how the workflow of visual QC will look. How will the engineers let you know that something is ready to be checked? Do you want to tag each other in JIRA tickets? Communicate on Slack DM? Shout at a daily standup?
While performing visual QC, focus not only on the actual visual part, components, and pixel perfection (not recommended to concentrate on this item at all until your entire team agrees you care about it). Spend a fair portion of your time playing with the feature and checking if it works as intended. Are there any unexpected holes in the user flow? Is it really what we want to give to our users?
Once you perform visual QC, let your engineers know if you find anything worth fixing before pushing the feature to production.
Don’t try to automate this workflow in any circumstance.
How did you like this episode of Fundament?
😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡
Upcoming events
UX Bielsko-Biala vol. 3
Fundament is a media partner of a local UX meetup in Bielsko-Biala, Poland, on Friday, September 6.
You can expect lectures by industry experts and iconic moderated networking, which has already become a hallmark of our meetings. The organizers prepared for you the opportunity to win many fantastic UX prizes, and all participants will receive gift packs and refreshments.
The meetup is open to everyone who wants to explore the secrets of UX design—both experienced designers and those starting their adventure in the world of design. People working in other areas of IT are also welcome, such as Product Owners, Business Analysts, Product and Project Managers, programmers, and testers. Regardless of your role in the team, if you are interested in UX, this event is for you!