Why We Need Less Design “Alternatives”, but More Design Iterations

It’s so familiar in the life of designers, that a coworker, or somebody who owns the project, to say something like, “can you explore more alternatives?”, or “can we present 3–5 alternatives, and let the boss picks one or two?”.

I am one of those designers who believe less and less in “more” and “alternatives”, instead, I believe in a focused yet continuous iteration of one problem or flow.

There are some reasons why design alternatives are bad for the design process.

“Design alternatives” are often insecure, indecisive and wasteful ways of presenting and consolidating on designs.

Consider the following scenarios:

• Inability to define priorities. I want to include feature A, B and C. I don’t know which one should be incorporated first. Should I even include all of them? Heck, why don’t we just provide 5 alternatives each sporting different sets of features? Who knows the boss or client might like it?
• Lack of user insight. The user might want the ability to shuffle the list of images. Or they might not. Or they might. Heck, why don’t we present 10 alternatives at how we might do this?
• Design or product bias. “Well, I did this for my previous company and it worked great!” — well yeah, what about this product you’re doing now? “It certainly is cool to do a visual collage of these! The customers will love it! You know I love it!” —well yeah, are you the customer? Why do you think a visual style works better than the rest? Oh heck, we can always prototype 5 more collage alternatives. Or even worse, “I don’t like this design. Try something else.” OK, you’re the customer.

In the end, presenting multiple alternatives of a design would usually end up in:

• Combination fatigue. “Can we combine this cute picture of a monkey with a big type all over it, and then add some augmented functionality in it? Oh, don’t forget that correct blue tinge on the eyes of the monkey.” Suddenly, we’re not speaking the language of the users, but more of personal taste and heavy assumptions.
• Micromanagement. Designers have reasons why they do something, be it from technological, cultural or time constraints. It is wise to give them problems, but never micromanage their answers. Even more, if you’re already taking part in nudging or nitpicking the visual elements. Never do that. Depart from the problem, always.
• Design by committee. This is the worst, absolute worst thing that can happen in any design or product. While democracy is good, design needs decisiveness and ownership by the designers. There are some design choices that need to be made to assure that the design has empathy to the users, more than the business goals, more than personal goals. And this is achieved by trusting the designers a bit more.

What is a good alternative? Here’s what I am proposing:

• Design one thing at a time, then iterate. Depart from clarity, focus, and insight for the users, business and other goals. But mostly, it should be the users first. Create one version of one thing, then explore more at the pace of one iteration at a time.
• Set the key question and answer. At the very beginning, set the key question. What am I trying to do? What is the user trying to accomplish? Then, set a few key answers, and follow that strictly.
• Focus on the experience, not the visuals. Visuals can come later, and they are the domain of the designers. Focus on the experience, the flow, the information architecture, and nail them down first. Then you can talk visuals.
• If things fail and you need alternatives anyway: limit to 2, and be deliberate in the reasoning why you need the alternatives. Never combine features just because you like both things. It has to come from the user’s key question and answer.