How to make smarter design tradeoffs

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?

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?

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.

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.

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.