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 do they currently solve the problem your app will make easier? 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 research.
After the initial research is complete, you start exploring different solutions. This means quickly generating a lot different approaches, different navigation options, 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.
As I’m refining these approaches, I find myself doing 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. 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.
A common mistake junior designers make is to focus on a single solution, that they explore in depth. 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.
How Many Should Your 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 design review is primarily about the image being presented, the feelings communicated by the design, then I understand why showing a single design would be preferable. 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 one, but the fonts and the layout option 2.” Only showing a single design is a way to avoid this and a whole host of related issues.
When the design review is focused on how an app works, showing multiple options is often helpful and productive. The options you present will differ in their approach to the problem. One option might geared to new users, to help them learn how the app works and what options are available. Another option might be focused on productivity. It might be harder to learn, but simpler to use once learned.
When presenting these options, you discuss the strengths and weaknesses of each. You will often have a productive discussion with stakeholders. You learn what they care about, where their priorities lay. They learn about the trade-offs involved and how different types of user 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 in more detail. 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 could be straight forward or it may be impractical. The menu may be small in one case, because a previous action by the user has limited the available choices to, say, 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, then it will be much harder to use. You explain that the second design is using a different approach and that then menu is not a good choice in this context.
No matter what the feedback is, you don’t take it as an order. Hopefully, you have set the stage for getting good feedback during the design review. Rather than taking he 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.
At the end of the day, design is a rational process. A good designer can explain the choices they make. 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 have made.
A really good designer will explain all of this proactively, during the design review. This is called selling the design.