How to avoid getting designs shot down in the name of consistency
Component-level design helps teams improve UX across a suite of products
Consistency across designs can feel like your enemy when re-designing a product that’s part of a larger suite.
You might offer solid design recommendations for product A, only to be shot down for something out of your control: it differs from how products B, C, and D (in the same suite) are designed. Worse yet, you’re not working on those projects, so you can’t suggest any changes across all these products in a group.
Except that’s not always the case. To do that, you need to think differently than you might about your Design: take a component-level view to try making design changes across your suite of products.
To understand why you need to understand how Engineering and Product teams work. I began understanding it when a Senior Engineer spelled it out for me.
UX Debt, Technical Debt, and the Scope of what you’re asking
“Is this design particular to this page, or do I need to update the rest of the application to look like this?” One senior Engineer remarked, telling me what he was worried about.
We were designing a page that displayed conditionally that the Product team expected 95% of customers to see when logging in. They would see this page if they had a particular subscription (and not anything else).
However, based on their subscription, there were other pages that they might see, and that’s what the Engineer was worried about. These design changes required extensive thinking about how to re-design the page to remain consistent, and it would probably be an extra couple of weeks of work for him. If he didn’t take it on this sprint, the team would be taking on extra “UX Debt” that they’d need to resolve at some point.
UX Debt is the accumulation of design and usability issues that accumulate over time for a product or service without enough attention to UX. It’s the close cousin to Technical debt, which Engineering teams may understand all too well.
In both cases, if you fail to pay down the debt, you run into problems. Working with high debt, in either case, often becomes so overwhelming that there comes a high cost in implementing new features or making improvements in the future.
Luckily, we can use this fact to our advantage. If they have extra time or resources during a sprint, competent Engineering teams will always work to minimize Technical (and sometimes UX) Debt.
If you provide them with minor UX fixes that address UX debt that they can tackle in an Agile sprint or less, you can ensure that Engineering teams across any product will eventually tackle the issue.
This is where the component-level view of UX can be helpful.
Component-Based Design and tackling UX Debt
We often view UX designs by pages for a good reason: it’s the flow we’re most used to when designing pages. However, it’s not always the best way to think about designs, especially in this situation. After all, asking Engineering to “re-design a page” is not a small ask.
Instead, if you’re working to provide the Engineering team with small UX workloads that they can work to address UX debt, you want to focus on more minor elements like Components.
This is where Component Based Design can come into play. Component-based Design is a concept that comes from Atomic Design by Brad Frost, where he advocates for splitting the UI up into smaller, more manageable parts with exact names:
Elements (Buttons, links, dropdowns, etc.)
Components (blocks of elements like cards, navigation menus, etc.)
Compositions (parts with multiple Components, such as groups of cards under the title “Our team”)
Layout (Grids, white space, and more)
Pages
In many ways, this is like flipping the Design on its head: rather than starting from the largest view (Pages), he advocates for first starting with the smallest chunk.
This is why this is it is ideal for this situation. By providing a component for Engineers to use, we provide them with a small chunk of work that can be implemented across the suite of products without a huge chunk of time being wasted negotiating across teams.
This is how we can not only fight against consistent, bad UX across a suite of products but also get Engineers on board with making these changes regardless of the team.
Here’s how to do that.
Updating UX across multiple products requires planning and research
If you’ve never had a chance to work with design systems, updating a suite of products will probably be your first opportunity.
The reason is that components are not only part of your Design system: but you also need to define everything about that component to avoid Engineering asking questions you haven’t thought of (or making their best guess at it). There are three main steps to this process.
Defining design standards for your component based on user research:
We need to ensure that we have thought about most use cases that have come up, such as design standards, use cases, patterns, and more for a component.
That requires doing user research into how people use specific patterns, where they might expect to use them, and more. It also involves organizational research, such as where this component will appear in different products in your suite.
If you’ve never worked with a design system, I like to use Google’s Material Design system as a reference, as they’ve spent a lot of time thinking about their component.
However, if you need a crash course in what to think about, consider these questions:
What is the max and min width of your component?
What are the breakpoints (for responsive Design)?
What interactions will this component have (both within the component and the larger page)?
What is the default state of the component?
Do you support empty states for this component?
Are there mandatory actions a user must take with this (i.e., select this to move forward)?
Etc.
Thinking about these things ahead of time, and passing on the answers to Engineering when you present your component, helps them minimize any back and forth you might have.
Prioritize critical features and components to introduce:
Sometimes, there are many changes that you would like to make across the entire suite of products. However, remember you’re trying to do this while assuring your team that you’re not racking up too much UX debt. As a result, you need to choose which things are most urgent to address while considering other things to introduce.
For example, you could create a ‘pie-in-the-sky’ design prototype that will fix all the common usability errors across your entire suite, but you shouldn’t introduce that to your team. Instead, select a few of the most critical components and then roll those into the prototype you present to your team.
This way, you have a couple of small goals/fixes they can achieve (and things to present to other teams if your Product team agrees to rope in other teams.
The main thing to remember is that for many of these products, these fixes will be rolled out gradually. So you have yet to learn if some teams are entirely swamped or if they can fix things right away.
However, by keeping things small, you’re helping to ensure that you can have the most impact, customized toward the capacity of other teams. Just remember also to communicate that as well.
Communication about scale and scope is vital for consistency
Arguments about consistency from your team often boil down to “How much extra work is UX making us do.” Engineers, in particular, have told me as much, wondering if a design will be standard and backdated to every possible place it could be.
However, other members of the team might feel a similar way. For example, product Managers might have a specific project budget, timeline, and resources. If what you suggest sounds like a considerable effort, they might shoot you down immediately (to keep things consistent).
This is why Component level design helps so much. Instead of saying something like “update this entire page,” it’s saying, “swap out this component across all your products.” As long as you have documentation in your design system, it often isn’t an enormous ask (and Engineering will back you up on that).
We need to communicate that with your team. Ensure that they understand the scope of what you’re asking and, more importantly, that this can be a gradual (but urgent) change each team can make to impact usability significantly.
Bite-size UX improves multiple products while maintaining consistency
In some ways, maintaining consistency while improving UX is a tricky balance.
You need to figure out design components that address questions that Engineering is likely to have, do a bit of future thinking, and prioritize which small changes will have the most significant impact. However, that’s often necessary when working with a suite of products.
This sort of Design often involves multiple teams and is a UX-led effort that requires multiple stakeholders to be on board. As a result, you can’t (and shouldn’t) push to change everything overnight.
Instead, think about the components of a piece that you could address that would have the most significant impact, and think about the plan you could take to ensure that these changes could be made successfully across multiple products.
To think of it in another way, this is a UX-led effort that has the potential to not only improve usability across multiple products: it’s also a way to show multiple stakeholders how small changes in the UX can lead to significant impacts on your customers (and turn them into UX advocates).
So if you ever have faced the dreaded ‘consistency’ response, think about the small ways you could change that. That way, you can have a significant impact across the entire suite.
Kai Wong is a Senior Product Designer and a top Design Writer on Medium. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.