Presenting Multiple Design Options

Interaction design begins with research. You need to understand who is going to use the product and what they want to accomplish. You need to understand their background. What applications they use and like. How they currently solve this problem, the one that your product solves more completely. What are the broad demographics of these users? How comfortable are they with technology?

You also need to understand the technical limitations and the business goals of the project, but user research makes up the bulk of this initial phase.

Developing Options

After the initial research is complete, you start exploring different solutions. This means quickly generating different approaches, different ways to solve the basic problem. Many of these will be dead ends. Their flaws will outweigh the benefits. That particular dog just won’t hunt.

Eventually you will find a number of approaches that have legs. These are the ones you explore in more detail, that you refine and imagine more completely.

A common mistake junior designers make is to focus on a single solution. After a brief outlining the problem, they come back with a detailed set of drawings ‘exploring’ a single solution. They ‘fall in love’ too early and fail to examine useful alternatives.

Once I have an initial set of options, I usually do a second round of research. I think about apps that have similar interactions and I examine how they work in detail. I’m looking for UX patterns I can adapt. This kind of copying is as common as dirt, but you have to be careful that the pattern you are borrowing makes sense. It has to be a good fit for your users. And it has to make sense for the app in question. It’s no use following a trend that doesn’t work well in context. Done poorly, this kind of copying can set the wrong expectations or saddle you with unneeded constraints. Done well, it can make the app easier to learn by leveraging users’ familiarity with similar apps.

How Many Should You Show?

Any reasonably experienced designer is going to have come up multiple design approaches. When it comes time to review these with the client or product team, how many should you show?

Some designers advocate showing only a single option to clients. The crux of this argument is that the client hired you, the design professional, to come up with a solution. You are the expert, so you should pick the design.

If a review is primarily about the visual design, then I understand why this might be preferable. Taste plays a large role in this kind of design. In effect, the client is renting the designer’s taste, and they should present the option they believe is best.

The motivation for showing a single option is to avoid a common pitfall of design reviews. When you show multiple options, the most natural thing in the world is for the client to want to combine elements from the various options. “I like the green from option A, but the fonts and the layout option B.” Only showing a single design avoids this and a whole host of related issues.

However, when designing an application, there are two inter-related things both loosely called design. There are aspects about how the interface looks, and these are largely emotional. And there are aspects about how it works, that are more rational. It’s more difficult to have a productive discussion about emotional design. When talking how something works, it’s much easier to explain your design choices. Of course, this distinction isn’t binary. Many elements of a design, like animations, affect both the emotional feel and the more rational, how-it-works side.

When the design review is focused on how an app works, showing multiple options is often helpful and productive. One approach might be geared to new users, to help them learn how the app works and what options are available. Another might be focused on productivity. It might be more difficult to learn, but more powerful once learned.

When presenting these options, you discuss the strengths and weaknesses of each design. You will often have a productive discussion with stakeholders. You learn what they care about and where their priorities lay. They learn about the trade-offs involved and how different users may have different reactions to the same design. These conversations improve the design because the whole team ends up understanding the problem better.

When the design review is focused on how an app works, showing multiple options is often helpful and productive.

Of course, you will often get feedback wanting to combine elements from the various options presented, the same as with any design. Some of these combinations may be worth exploring. Some will be dead on arrival.

Suppose one design presents a small list of choices in a menu, and the client wants to use this menu in another design. This might be straight forward or it may be impractical. The menu may be small in one case, because a previous action has limited the available choices to 4 or 5 items. When applied to a different design, the menu might have many more options. If the menu would have 20 or 100 items, it will be much harder to use.

No matter what the feedback is, don’t take it as an order. Hopefully, you have set the stage for getting good feedback during the design review. Rather than taking the feedback at face value, you want to understand motivation behind it and you want to tie it back to the design goals. So ask follow up questions, like:

“Why do you want to move the buttons to the left?”
“What problem does moving them solve?
“How does this help the user?”

A good designer can explain the choices they make.

A good designer can explain the choices they make, even when discussing the more emotional side of the design. The vast majority of the time, a good designer will have an objective reason to back up their decisions. They will have a convincing story about the choices they made.

A really good designer will explain all of this proactively, during the design review. This is called selling the design.