Design Quality (QA)
Quality doesn’t just happen
What happens once your design is approved, eng has finished coding, and your about to launch your product onto the world stage? More often than not, you end up finding bugs and defects caused by rushed engineering, unpolished UX that was overlooked, and design specs that weren’t implemented as designed. Queue design freakout!
To be clear, this isn’t a rant about engineers not implementing designs right; this is more of a proactive way to plan for QA (Quality Assurance) so that you catch things that will inevitably crop up before it’s too late!
One of the biggest challenges designers face in product teams is their ability to maintain quality standards throughout the project’s duration; this includes the development phase too. As a project evolves, grows in complexity, and timelines compress, a designer will inevitably have to make decisions on the fly that will affect the end-user experience. Being available to make these decisions is key.
If we look at the Architect/Engineer relationship, Architects will design a building in collaboration with an Engineer. They’ll create detailed specifications together, be on-site together, and oversee quality and craftsmanship together until the very end. What an architect wouldn’t do is hope that the building miraculously springs from the ground one day, perfect in all its detail, with very little input except for one or two visits towards the end. At that point, it’s too late to make adjustments or alterations in any meaningful way.
For product design and software development, the same principle applies. As a designer, you shouldn’t assume your job is over once you handoff the specs to eng. The opposite is true; some of the hardest decisions you’ll have to make that will impact the overall quality of the product you put in people’s hands, will be made during the build phase.
I admit, though, it’s not as easy as it sounds. Sometimes there are forces beyond your control that limit your ability to manage quality from start to end — Scope, unforeseen requirements, or technical feasibility can all contribute to a compromised solution. Sometimes there are business structures in place that make it impossible to spend time on quality — like budgets, team resources, or other projects that demand your attention. But if your product’s quality is important to you (like it is for me), then there are some basic building blocks you can implement that can make a huge difference. Let’s break down some key ingredients:
1. Quality takes effort
Quality takes effort, time, and patience. More often than not, it’s the designer’s responsibility (and burden) to hold and maintain the quality bar. You need to be organized and understand how you can influence the product, both directly by understanding your strengths and ability to get involved where necessary; or indirectly supporting your team as a partner.
It’s also important to note that not everyone has the same definition of quality as you do. For example, engineering quality often means extensibility and use of semantic code. Product quality could mean that the product is performant and is driving key metrics. Design quality could mean buttering smooth transitions and interactions, zero latency, and pixel perfect UI. With that said, defining a shared understanding of what quality is to your team becomes essential when measuring the output of the build.
2. Understand the current goal and future needs
Ensure you fully understand the current and future needs of both your audience and your business. Having a clear goal and realizing the opportunity will keep you motivated and drive your team towards a quality outcome without cutting corners and reducing churn along the way.
3. Build flexibility into your process
Locking yourself into a solution too early will most certainly set you up for disappointment. It can leave you feeling vulnerable or make you more likely to abandon any hope of achieving your quality bar when things need to change. Be open to new ideas and accept that your original vision might change (and in most cases will).
4. Know your role
Make it clear to yourself and your team members what your role is (and set expectations early). This could include outlining your process, defining a schedule of deliverables, or setting up routine meetings that focus on design-critique and quality.
5. Be a subject-matter expert
Understand what you’re good at and own it. Leveraging your strengths (especially in a collaborative environment) will define you as a subject-matter expert and, more importantly, a reliable and trusted peer who will be sort after for opinions and feedback.
6. Tools for tracking and communication
When it comes to quality, having the right tools in place is crucial. As a designer, make sure you have all the tools required to execute ideas efficiently and to a level of fidelity needed (which doesn’t necessarily mean pixel-perfect). Look beyond just static templates and plugins too. Think about a universal design system, how your process dove-tails with engineers, and even how you might log and track bugs or defects when it comes to final review and QA.
7. Be a partner to engineers
The quality of the relationship you have with your engineers will be directly reflected in the quality of your final product. I think it would be impossible for me to do my job without the help of engineers. Much like the traditional architect/engineer relationship, the designer-developer relationship is key if you want to build something of high quality.
8. Build bridges
Be the person that connects the team. Whether you are a specialist or a generalist (I’m a generalist), build bridges with engineers in your team, product managers, researchers, data scientists, other designers, the people that use your product (of course), and leadership. Bring folks along for the journey, get them involved, listen to their feedback, and keep them looped in so there are no surprises at the end.
9. Be the advocate
Even if there is no one else, be the advocate for quality. Take ownership of the Quality process, get involved, log and track tickets, invite yourself to release meetings, test, evangelize, and communicate as if your life depended on it!
10. Pick your battles & prioritize
Software never ends, so be prepared to pick your battles and pace yourself. Be patient and understand that some things are more challenging to achieve than others, and in product-land, most things are prioritized by effort and impact; which means you’ll have to make tradeoffs along the way.
11. Eat your veggies
Some people refer to it as dog-food or fish-food; I’ve always liked the veggie reference tbh. It refers to the habit of reviewing and using the products that you design and build. In most development environments, you’ll be able to access the latest build or release (if you ask your friendly engineer nice enough). Once you have it, use it!
12. Define Quality up front
As with most things in design, a clear definition and process are the best course of action. Quality is no different. Not only is Quality a subjective topic, but it can also change its meaning from project to project. I’ll often define it in the context of each project — Does it mean pixel-perfection? Does it mean solving the problems and achieving the goals? Does it mean MVP? Does it mean clear communication and building relationships within the team? Does it mean detailed specifications? Does it mean bug-free? Does it mean all of the above? If so, how do I prioritize it all? Inevitably you will ship something, and (for better or for worse) the quality of what you ship is up to you and how much effort or emphasis you put on it.
