When we set out to build Pixelworm we knew, first-hand, we were solving a problem that was real and that had a healthy appetite for time, not a problem we created and hosted in a niche comprised of - just us. A problem that gave designers heartache, developers frustration, and had testers running for the trenches. We knew exactly where in the product development lifecycle this problem arose but we didn’t have a name for it. As of late, a new phrase - of a new phase - has popped up and now, Pixelworm has a new address. Design QA, more specifically Design Quality Assurance.
What is QA?
Let’s start by defining Quality Assurance, which is older than the term digital itself but we will focus on the technological aspect of it. QA is the process of testing a product to make sure every bug (at least for the latest sprint) has been fixed and every planned feature is functioning as required. QA is part of a cycle that involves development, review, and testing and a well cemented one at that. No company or development team in their right mind would distribute a product into the hands of their users without holding it to rigorous QA testing. But what about flaws in the design? This is where Design QA comes into play.
What is Design QA?
Design QA is a new, and much needed, phase that sits between development and testing wherein the latest release is reviewed by UX/UI designers to find and fix inconsistencies between the design files and developed interfaces. It is assurance that the user experience is smooth, consistent, and most importantly, intact.
Why is Design QA important?
There are dozens of design hand-off tools in the market now that, to a certain extent, help reduce the differences that arise when developers code the screens they were given. Unfortunately, these tools are not enough and more often than not interfaces that crack the user experience make it through testing and into production.
Additionally, every new iteration of the product leads to the introduction of new elements, or changes to old elements, that slowly erode the general cohesion of the design. This slow silent creep-up is called design debt as defined in Austin Knight’s brilliant essay:
Design Debt/affects the integrity of the user experience. This is what happens when a bunch of incremental changes collect over time and yield a disjointed, inconsistent, and patched-together experience. — /Design debt
Design QA helps dust off design debt before it piles up to the point of no return where the only solution is refactoring the codebase and starting fresh (spring cleaning if you will) - a process that is time consuming and expensive.
Integrating Design QA into the product development lifecycle can be challenging for a number of reasons. Design may not be prioritized, differences between good design and poorly coded interfaces can be hard to catch, communicating those differences can be cumbersome, and most importantly Design QA can be seen as time consuming and expensive - ironically, exactly what refactoring is.
This is where Pixelworm steps in. By automating the first and most menial task of Design QA (namely finding and listing the inconsistencies) , Pixelworm eases communication, and radically reduces time spent in this phase. Developers can see the design files and their coded screens side by side with components matched and differences pointed out and categorized. The development phase has IDEs, the testing and review phase has Jira, and now, the Design QA phase has Pixelworm.
In conclusion, product development is an iterative process that involves multiple teams, each working in different phases of a cycle that repeats itself until something worth releasing is created. Well-documented phases such as development, review, and QA testing have been around long enough to be considered pillars of this structure. And now there is an invitation to bring Design QA to the table. An invitation we would like to extend as well because we believe in the importance of Design QA - believe in it enough to build a tool for it.