The 3 E's that make up the "right" solution

Efficiency
Refers to the cost of the solution. It is about the time, effort and money that goes into creating the solution.
Elegance
Refers to the quality of the solution. It is about how well the solution is designed in terms of performance, attractiveness, usability, etc.
Effectiveness
Refers to the merits of the solution. It is about how well the solution solves the problem or achieves the goals. It is usually measured with metrics like NPS, engagement, task completion rate, etc.

So how do you get to the "right" solution?

As UX experts and product designers, we often design multiple solutions to a given problem. This is part of our messy, non-linear design process. A great designer not only develops creative solutions that meet both user needs and business goals, but also forms strong opinions and confidently proposes the right design solution. Developing strong decision-making skills is also critical for designers to grow professionally.

To propose the right design solution, you need the right tools to support the solutions that work and discard the ones that don't. Here are a few tools you can rely on to help you form informed opinions and make confident design decisions:

1. Focus more on the disadvantages than the advantages.

We all love our designs. Listing the advantages of the solution we created feels good and is fun! But it's just as disappointing, or maybe even more disappointing, when they don't work in the real world.
Stress test and critique your designs to list as many drawbacks as possible. This is probably the best way to narrow down your solutions. In other words, focus more on the question "Why should we NOT choose this solution?" than "Why should we choose this solution?".

Here are some suggestions for stress testing solutions on the go:

• Does it work on smaller screens? Does it work on touchscreens?

• Is it localization friendly? Is it translation friendly?

• Does it work at slower internet speeds?

• Is it accessible?

• Does it work with important edge cases?

Evaluate how well different solutions score on these questions, and say goodbye to those that don't. Find the critical issues and decide on the solution that is most robust!

2. Define the ideal features of the solution

Once the team has defined the product goals, the next step is to identify and define the features that are important to the final solution. These will serve as guardrails as you explore different solutions.
For example, if the team decides that "speed" is the most important feature, developers will focus on code quality and performance, while marketers will work to market the product as a unique selling proposition, and so on. And as designers, we should make sure that every micro-UX decision we make is in line with the core feature(s). To build speed into the solution, constantly question the need for additional steps/actions when designing flows, and remove anything that doesn't add value or slows down the user. Think bare minimum and reversibility.

Here are some other suggestions:

• Is saving users time the most important feature?

• Is it most important that the workflows are foolproof?

• Do we build clarity and trust first and foremost?

• Is it critical that users follow our recommendations?

Identifying these characteristics upfront will help you steer clear of solutions that don't meet these requirements. If you're still considering multiple solutions, choose the one that meets the most important characteristic.

3. rely on basic experience values.

Experience values are defined at the corporate or higher product level. These are by no means rules that you must follow, but guidelines that allow for a common language within the company to create coherent experiences. They are even more relevant and useful when a company has multiple design teams working on different sub-product lines. If your team or company doesn't already have such guidelines, you should assess the need and work toward defining them based on your product, business, and users.
When user actions are reversible or easy, we make them as effortless as possible. And in cases where they're irreversible or risky, we add positive friction to ensure users clearly understand the associated outcomes before taking the actions.
You can simplify your design process by combining experience features with solution features. A hot tip is to identify such experience features that are "relevant" to the problem in advance and use them in the solution phase.

4. Align with established patterns (or maybe not?).

This seems like a no-brainer, right? Not really... Established patterns are highly trusted and often have little to no learning curve for users. So in most cases, using established patterns works very well. But the idea of using an established pattern for a problem usually comes from the designer's intuition - and intuition alone doesn't necessarily lead to the most "effective" solutions. Think of the "Tinder swipe," for example. It was a design decision not to follow an existing pattern, but instead to introduce something more appealing and arguably more effective for the given use case.
Use new patterns, concepts, and nomenclatures only if they are well thought out, introduced, tested, and likely to be better. In all other cases, you should revert to established patterns as much as possible.

5. Estimate the effort required to create each solution.

As designers, part of us always wants to create shiny, appealing designs. Who wouldn't want to have those in their portfolio? There's nothing wrong with that. But as designers and other product owners, we build products for our users to solve their problems. Nothing should come before you and your needs. So if you have two or more equally good solutions, you should choose the one you think will give you a higher return on investment or require less effort.
There is no greater return than delivering solutions and solving problems quickly. This point also illustrates the importance of close collaboration between designers and developers.

6. estimate the cost of undoing each solution.

Often you get into situations where you don't have time for user testing or you don't have the infrastructure for A/B testing. This situation only becomes difficult when you need to deploy a solution very quickly. In such cases, you should not only look at the effort required to develop each solution, but also weigh the cost of rolling back each solution and choose the one that poses the least risk. Here are some clues:

• Is this solution reversible?

• Would we lose trust if we reverse it?

• Would we create a lot of support debt by reversing it?

• Would we introduce a new user behavior that is difficult to undo?

This point also illustrates the importance of close collaboration between designers, product managers, and customer support.

7. Don't forget the 80/20 rule*.

Sometimes a solution does not work equally well for 100% of use cases/users. This can be very difficult to achieve. In such cases, it may not be very wise to invest time, effort and money in finding the perfect solution. This is where the classic 80-20 rule comes into play. Discard the solutions that don't work for at least 80% of the use cases/users. Pick the solutions that work best for the most important use cases/users and make sure the tradeoffs are clearly documented. This way you can deliver faster.
But * if a solution is really important for 100% of the use cases/users, you should break down the problem further and/or choose a tailored approach that could include different solutions for different use cases/users.

8. evaluation of solutions in terms of long-term visions and short-term goals.

Developers can relate to this very well - especially when thinking about issues such as infrastructure, scalability, etc. When developing and optimizing for short-term purposes (in the interest of quickly delivering value to users), we sometimes overlook the backlog that could result for the future.
If the problem domain you're in is constantly changing or growing, it's a good idea to have a long-term plan. In such cases, you can focus on developing solutions to the immediate problem, but also explore how those same solutions can evolve to meet future needs. Use the results to evaluate the merits of the various solutions. If the problem space is fairly stable, it is usually okay to work toward short-term or local maximums.
Also consider how your solutions might impact or affect other product work streams in the company. If so, you should consult and collaborate with those teams.

9. Use data and research at every step of the design process.

No one can object to well-tested data - be it internal data or well-researched external data. The best designers use data to validate pain points, understand their size/severity, and identify opportunities to create data-driven solutions. For example, pre-selecting "smart defaults" speeds up operations in most cases. Rather than guessing based on intuition, use data to identify and use the most popular choices. Exceptions include cases where you want to introduce new behaviors or where the risk of making the wrong choice is high.
Also use research and user testing to get closer to your users. For example, knowing how tech-savvy your users are can help you make many UX decisions related to your product design and content - e.g., language, tone, font, etc.

In short, use data, research, and user feedback to invalidate solutions that may not work and validate solutions that can.

10. Test the fluidity of designs.

When working in low-fidelity, we sometimes tend to overlook the higher levels such as interactions, transitions, animations, and continuity. It's only when you create a high-fidelity prototype with a full image that you discover gaps like the number of actions, potential distractions, and jumping off points. This is another way to test the merits of different solutions.

Conclusion

Think beyond UX

It's important to realize that it's not enough to evaluate a solution only from a UX perspective. No user is going to evaluate a product based on individual disciplines (UX, engineering, etc.). It doesn't matter to them. All that matters is whether we are meeting their needs and wants in the right way.
We are equal owners of the product, just like any other colleague in the product process. It is our responsibility to solve the right problems in the right way, making sure they work well in the real world and have a positive return on investment for the company. Broadening our view and perspective helps us see the big picture, and that context helps us make the right
decisions - yes, even those tiny UX decisions - that make the product what it is!

Get feedback not only from other designers and executives, but also from developers, product managers, data scientists, customer support, the sales team, or anyone else you think can add value to your decision-making process and take the pressure off you.

Avoid "bikeshedding."

Don't spend too much time on trivial decisions that have little or no impact on the final solution. Postpone them as needed. Use the time saved to make decisions that are critical to the solution.

Fair Effectiveness and Elegance

Document all key decisions and associated trade-offs made during the design process. Once the solution is delivered, use them as benchmarks to measure your effectiveness and elegance.
Finally, analyze the metrics to identify gaps and opportunities for improvement.

Efficiency Review

Conduct team and/or process retrospectives to understand what went well, what can be improved, and what went wrong from a process perspective. Identify opportunities to improve the efficiency of decision-making processes.