Stop showing design options and commit

Ken Kocienda’s Creative Selection recently did the rounds in our product team leading to a simple change which accelerated and clarified our design process, resulting in a big jump in the quality of design output.

You may not know of Ken but there’s a good chance you’ve used his work. The story is about his journey to deliver the first touch-screen keyboard. Throughout, it partially reveals the culture of demoing within Apple, a process we remarked as being simpler than ours, despite the company being thousands of times bigger.

Software development at Apple is seemingly based around working quickly towards developing a well-reasoned, single prototype of a solution and demoing it to get buy-in to ship, or feedback to improve it.

Rand’s option

The method connects back to renowned graphic designer Paul Rand, known for his extreme style of showing only a single design solution to his big-name clients like IBM and ABC.

Famously, Jobs hired Rand to design the Next logo in 1986. When asked by Jobs if Rand would provide options, he replied:

“No, I will solve your problem for you and you will pay me. You don’t have to use the solution. If you want options go talk to other people.’”

Rand’s process seemed to command a great sense of respect in Jobs, and no doubt this impression influenced the single demo process at Apple, where everyone was expected to bring a Randian level of expertise.

The problem with three options as a goal

When Paul Rand’s process is referenced by designers it’s often laughed off as unreasonably non-collaborative, dictatorial and even egotistical.

But forcing designers to commit to one option by themselves has a great effect. Having a designer work towards a 3 option review, and asking others to “choose” relinquishes the responsibility of reaching a solution to the best of their design ability and expertise.

Three design options is standard in product teams. This is typically to create the appearance of due exploration, but often it becomes a reflection of a lack of trust in a designer to solve the problem themselves. Or making non-designers feel involved in the design process. Or even as a proof of work.

An extreme, famous example of this non-committal approach to design reviews happened at Uber when a designer was brought in to redesign their logo in 2016. He presented 200 options and the logo was then apparently picked impulsively by the CEO, Travis Kalanick.

Compare the level of respect between client and designer in this case to that of Paul Rand and Steve Jobs. And also the result of Rand’s single option approach:

Neither design here is right or wrong. It’s impossible to say Rand’s work is objectively better than the work done at Uber. Subjective bias or not, his conviction changes the value of the work in reality. The conviction has stood up against time. And in the context of digital product design, the result of conviction can drive product changes faster. These changes can remain until they fall down against an objective standard.

Innovation is overrated

While the designer should spend time in the exploration phase, they should not over-fetishise it. Innovation is overrated.

The goal should be always be trying to work towards a single assertion as to what the best solution is, to be able to back this rationale up, while still understanding that we might be screwing this up.

Making decisions to move towards a single assertion is a muscle. It requires dealing with the fear of being wrong by finding reasons to be right.

This is not to say designers should work alone. Finding these reasons requires collaboration. Within the product team, we’ll often do many 1:1s, weighing alternatives with other designers and developers. This is necessary to work through the problem, to have explored and dismissed options that may be asked about. This is different to presenting what you believe should be built, which in my opinion should be a single option.

So how many options?

One. But if not one, the general rule is the more people in the room, the fewer options to discuss. But ideally one. This makes managing conflicting opinions easy.

Here’s some very complex math: With 4 people in the review and 4 options, the minimum number of opinions to manage is 16. With a single option, it’s 4. The majority of the 16 will be lost, and ultimately have no impact. On the other hand, the four have a greater chance to make meaningful, specific changes.

As a designer if you find yourself working towards presenting 3 options rather than presenting what you believe to be the solution, see if you can commit to one only and if this changes your thought process.

On a practical level, now tools like Figma allow us to quickly reach modular, easy to update prototypes and leave no excuse for not committing to realistic solutions early.

How it focused us

Let’s compare two of our recent reviews at Slite. Working on a recent feature, Note templates, we put forward 3 prototypes to the wider team, each representing a very different answer to the problem.

While there were important questions to answer (do templates exist globally or per-channel? are they a premium feature?), comments and questions spread across the prototypes, each resulting in additional possibilities for that approach, but with little direction towards the core problem, despite it being outlined. The optional nature of the presentation was flawed. Our stance was one of asking questions we should have answered.

After retreating for some more thought, we came back to show a single prototype and suddenly all eyes focused on the real impact the prototype would make on the product. Talks surrounded the important questions. Refinements were suggested but there was an understanding that these were secondary.

The design team had strong justifications for each decision. Holding up strong opinions in a simple format helped us move forward faster to test them in reality.

Constraints as a culture

Another prerequisite to this process working is one of trust in the designer, a lack of which may be a reflection of a designers current ability or the design maturity of the company.

At Slite, we try to apply these kinds of constraints not only to design but to all aspects of the company. From number of employees, synchronous meetings, concurrent projects, documentation, and ultimately the product.

It works well. Intents become clearer and more focused. Results happen fast. Decisions don’t splinter into thousands of arbitrary, inconsistent, unmet potentials.

We can all admit to being wrong and having to try again. So if choice and uncertainty in the name of designing collaboratively are actually making collaborating harder, try constraints and conviction instead.

‍