I fell in love with design because of the beautiful mockups I would see on sites like Behance and Dribbble. Detailed design specs impressed and inspired me equally as much — so thoughtful and comprehensive. But, guess what? As a designer, your design specs actually don’t mean squat. At least, relatively speaking. Specs don’t make money or determine product quality. They don’t change behaviors. They don’t help your users achieve their goals. In the world of digital products, only your live product can do these things. Design specs are stepping stones. If all the beauty, logic, and research you put into them never make it into the live product, your digital product will fail. That’s why it’s so important to own the product.
What does it mean to own the product? It means you, as a designer, are just as responsible for the product’s quality as the engineering team. It’s on you to make sure the team builds the live product as designed.
Doing this well is rather difficult. It requires us to cross the great divide: the chasm between design and engineering’s understanding of the solution. This communication challenge is a huge issue in product development. Companies have devoted millions of dollars and entire products to solving it. And while products can help us improve, the real solution to this problem lies in processes, not products.
People have written plenty about how to ensure less gets lost in translation between design and code. Get developers involved early on. Walk them through the designs and give them a chance to ask questions. Be available and respond to questions fast. Understand the limitations of your front end framework. Work with engineers to learn some basics of front end coding (we’re talking some responsive grids and CSS transitions here, not a comp sci degree from MIT). But, rest assured, even if you do everything right, something will get lost in translation.
How to Catch Quality Issues
The first challenge here is making sure you actually catch quality issues. You might be thinking, “Isn’t that QA’s job?” Yes, it is. But owning the product is the entire team’s responsibility. That being said, designers are best equipped to spot discrepancies between the designs and the live product. Why? Because they created the designs and intimately understand them. Plus, not all issues will be simple discrepancies between the design and product. You might discover a usability or accessibility issue you hadn’t considered. Because our design tools are so static, such things often go unnoticed. There’s nothing like using the real thing.
Despite the designer’s suitability to find these issues, many teams don’t involve design in QA. Or they do so haphazardly, expecting engineers to reach out for design QA at some undefined time. I’ve been on several teams taking this approach and it never works well. You need a formal step in the development process for your designers to vet the requirement in the live product. Ideally, designers will be able to interact with the product when reviewing. Screenshots and live demos are nice, but they don’t allow for proper attention to detail. Demos are rushed
and often performed without a user’s actual task in mind.
This brings me to my next point: when reviewing, do so with a purpose and a plan. First, review the flow from the perspective of your users. Assess the product in light of everything you know about their goals, behaviors, and environment. Next, do a pass looking for obvious visual errors. Then a pass focused specifically on responsive behavior. And last, take a close look at any copy in the flow. Pay attention to the product’s performance — how fast are pages loading? How will this affect the user’s experience? This might seem like a lot of work, but getting it right the first time is so important. Once the feature goes live, any UX enhancements are likely to find their way to the bottom of the backlog. Depending on your organization’s maturity, new feature work often outranks these types of enhancements.
Also, no discussion about quality can be complete without mentioning usability testing. Testing your designs before they go to development increases your confidence that you’re launching a high-quality product. Doing so will catch usability and accessibility issues that will be costly to fix later.
How to Fix (Or Not Fix) Quality Issues
We’ve talked about how to make sure we catch quality issues, but what do we do when we find one? There are two ways this can go wrong. On one hand, a team can focus too much on the fine details, at the expense of velocity and the big picture. On the other hand, a team can ship a poor quality product that doesn’t drive engagement or achieve business goals. We want to land somewhere between these two extremes. Finding the right approach is a delicate balancing act brokered by designers, product managers, and engineers. The designers want the product to work a certain way, but building it will take time. Is the time investment worth it?
Too often teams take shortcuts to answer this question. A common response goes something like this: “Oh, it’s just MVP. Ship it the way it is and we’ll improve it later.” Or the opposite extreme: a designer insists on pixel perfection, no matter the cost.
Both of these approaches are quick routes to failure. First, MVP should not be synonymous with low quality. Your paying customers care about quality, even if they are early adopters. However, their idea of quality may differ from yours. For example, unless your audience is a bunch of designers or developers, they don’t sweat the fine details as much as you do. They don’t care or even notice if spacing is off by a few pixels. Their idea of beauty differs from the canonized trends found on Dribbble, a playground for exploratory design aesthetics that are often an acquired taste.
Instead, users care that your product is:
- Useful: Does the product solve a painful problem in a way that no other product does?
- Usable: Is it easy to use? Can users complete their tasks with limited frustration?
- Accessible: Can people with disabilities easily use it?
- Convenient: Is the amount of work users put in worth the value they receive?
- Readable: Is the content organized in a way that makes it scannable and digestible?
- Trustworthy: Does the product look like a hacker threw it together?
Factors like these will actually impact your users’ satisfaction with the product and your business’s bottom line. So when it comes time to decide whether to fix an issue, have a discussion with engineers about impact vs effort. If the fix will improve more factors on the list above, it will have a higher impact. But the effort part of the equation is equally as important. Understanding how difficult a fix is for your engineering team to deliver will build trust with them. Quite frankly, asking an engineer to add a new library or build a completely custom solution to accommodate your subjective opinion about beauty is downright annoying.
Based on the above, your MVP becomes a crafted set of high-quality features with strategic decisions made around quality tradeoffs. Fewer features, but higher quality. Your MVP should not be a hodge-podge of low-quality functionality.
We also can’t forget that building software is not only about meeting your users’ wants and needs. While doing so is critical, meeting the business’s needs is equally important. So, when evaluating a compromise to your designs, also consider business impact. Is the compromise likely to make your product miss its business goals?
Conclusion
Here’s the TLDR. While it’s the entire team’s job to own the product, designers are uniquely suited to finding product quality issues. Designers can increase product quality by:
- Including a formal step for design QA.
- Being intentional in their reviews of the product.
- Being willing to compromise.
- Understanding how compromises will affect what your users care about: usefulness, usability, accessibility, convenience, readability, and trustworthiness.
- Understanding how compromises will affect progress towards business goals.
Need better UX/UI design for your product? Learn more about our design expertise here.
