How to make smarter design tradeoffs
Discover ways to please most of the users most of the time
Everyone talks about design principles as if we can create the best products as long as we push for the maximum on each design principle slider.
In reality, sometimes we need to compromise one design principle for another. More often, we need to deal with the conflicting interests among design principles, technical constraints, and business goals.
The design process is about making tradeoffs considering all factors while aiming for the optimal UX. How can we make smarter tradeoffs?
What are the tradeoffs?
Before a product finally comes in front of you, it has gone through numerous planning sessions, meetings, approvals, and pushbacks. You think you are smart and can quickly spot some obvious improvement. The fact is this “improvement” might be lying in the product team’s backlog, waiting to get picked up when resources are ready.
Throughout development, we are constantly deciding on tradeoffs. Which research method should we use given our time and budget? What design principles should we prioritize more? If we cannot technically build this, what’s our second-best UX solution? Should we postpone the deadline or cut some features?
When do tradeoffs happen?
Tradeoffs can happen anytime, especially when principles or goals from different disciplines fight.
Even two design principles can fight each other. For example, if you have to make a tradeoff on the number of clicks and the effort to think, use more clicks and make the user think less.
More often, tradeoffs happen across disciplines — the constant balancing (battle) among business objectives, user goals, and technical constraints.
Tradeoff principles
As with all decision-making processes, when it comes to tradeoffs there are some principles that can guide our thinking.
Using big picture goals to derive low-level solutions
Every product should have a long-term vision. Often, many low-level decisions can be guided if the high-level goals are concise.
For example, a meditation app’s goal is to give users peace of mind and help people to practice listening from within. Yes, every product wants to be spread through words of mouth. But is it a good idea to add a “share on social media” button at the end of a meditation session? Definitely not, in this case, the higher goal of promoting peace of mind should eliminate all the social interactions, such as sharing, competing, etc. A nice end of meditation screen should be something simple and elegant so that you can carry on the peace into real life after.
Effort & value
The effort & value matrix is a classic way to find out what we want to prioritize. Before putting features onto the matrix, we need to evaluate the effort and value needed to pursue a feature. While effort info can be gathered by asking designers and developers to estimate, value is something different people might have different opinions on.
In order to understand the value of solving a problem or developing a feature, we can ask ourselves:
- How often does this problem occur? Is it several times a day or only on occasion?
- How many users will face this problem?
- How much pain does this problem cause? Is it a minor annoyance or would it cause the user to switch to other products?
- How will you solve the problem so that the user won’t feel frustrated getting used to something new? Should it be incremental changes through several releases instead?
Making compromises, not sacrifices
When you cannot achieve the optimal states for both features A and feature B, instead of cutting one completely, you can think of it as a compromise. If A is more of a priority, the question now becomes within the constraints of A, what is the best we can do for B?
For example, for the purpose of security, some products make the login process quite complicated. They require not only credentials but also approving log in from a different device. From a UX point of view, it adds to the difficulty of use. But think differently, given the constraints of security requirements, how can we introduce ease of use? In this case, we are compromising ease of use, but not completely sacrificing it.
Knowing when to follow guidelines and best practices and when to break them
There are guidelines in design, development, and product decision-making. We need to know when to follow which and when to break rules so that specific use cases work. These mostly come from experiences.
Using user research as an example, the ideal method can be found in any textbook. While in reality, we often need to remodel research methods to make them work within our project’s budget and timeline constraints. The adjustments we do range from reducing the number of participants, choosing participants who are not the target audience, testing through a video call instead of real context, etc.
“Testing one user is better than testing none.”
- Steve Krug, the author of Don’t Make Me Think.
Common design tradeoff examples
There are also some tradeoffs we as designers can make decisions on, without going through discussions and debates. Below are some common examples of design tradeoffs.
Minimize cognitive load > Minimize motor load
“Some types of mental processing are more challenging than others.”
- Susan Weinschenk
According to 100 Things Every Designer Needs to Know About People, humans operate 3 types of loads:
- Cognitive load. For example, when you need to do the mental calculation, remember passwords, etc.
- Visual load. Everything you look at on a screen requires visual load.
- Motor load. Such as moving the mouse, pressing buttons, etc.
These 3 types of loads use different amounts of mental resources, with cognitive using the most, visual in the middle, and motor using the least.
“Reducing the number of clicks” should not be the golden rule if you are clustering so much information on one page just to reduce clicks. Information overload causes more thinking. And the cognitive load is more painful than motor load, i.e. a few more clicks.
Below is an example of Slack’s company sign-up process. It only requires 3 fields of information. But spread out into 3 screens, with 3 clicks. It crafted the exact info you need at each step so that you don’t need to think much. And mostly you won’t remember how many times you clicked.
Clarity > Consistency
One other rule is that when making something slightly inconsistent can make the message extra clear, compromising consistency for clarity. But be cautious, don’t overdo it. I once worked on a project, where the client wants to use a new design style every time when preparing to announce a new event. Using the rule once can make one event stand out. But using it for many events, it’s just inconsiderate choices of design.
Aesthetic v.s. Usability
Mostly, the rule we follow is to make a product usable before making it beautiful. We know most arguments on that front, so here I am going to cover some cases, where aesthetics can mask usability issues.
According to an NNG study, “Users are more tolerant of minor usability issues when they find an interface visually appealing.” In the study, a user encountered many minor annoyances when interacting with the product but managed to finish the task. In the end, when asking about the experience, she praised the aesthetic appeal, such as colors and photographs, and rated the site “very highly in ease of use”.
Security v.s. Ease of use
This depends on the situation. For big companies, the cost of error is too high. Security is more important than ease of use. They might require multiple identifications when logging in. Also, many companies’ internal tools tend to prioritize security more because all employees are trained and need to use the product anyways.
However, for smaller companies who are building products for the public, you might want to prioritize ease of use first. First, get people to like your product, and use your product then deal with security when the time comes.
Existing pattern v.s. New pattern
If we are building a product based on a pattern library, one tradeoff we need to consider is whether it’s worth the time to create a new pattern or should we stick with the existing one. To create a new pattern, we need to consider what existing elements can this new pattern utilize, how the pattern will be used in the future, how much time it takes to build the pattern, etc.
While the existing pattern can save time for design and development, at times it might not be the best solution for the user given a specific situation.
Cross-discipline tradeoffs
Mostly, tradeoff decisions cannot be made by designers alone. Here come the “debate” meetings, where cross-discipline team members need to fight for their optimal solution in their domain.
NNG provides the “Trade-off Scale” as a tool for teams to visually prioritize user needs, features, project factors, etc. so that we can focus resources on the most important ones.
To et cross-discipline team members to agree on and prioritize features, here are the steps introduced by NNG:
- Step 1: Ask stakeholders and team members to brainstorm important attributes or user needs.
- Step 2: Cluster them into themes.
- Step 3: Agree on a shortlist of 6–8 factors. Then put importance for each attribute. Note no two attributes can have the same level of importance to force the team to make a decision.
Conclusion
Like in life, there is no one right decision in product development. Within different contexts, there are different priorities, goals, constraints, and tradeoffs. In order to make the optimal decision within all limitations, we need to first keep in mind the high-level goals and in the meantime look at the details and specifics. In order to launch a product and continue shaping it towards a better future, we need to learn how to play the game of tradeoffs.
“You can please some of the people all of the time, you can please all of the people some of the time, but you can’t please all of the people all of the time.”
- John Lydgate
