Structure, Not Design By Committee

I wrote this for the Product blog.

In The Simpsons episode “Oh Brother, Where Art Thou?”, Homer is asked to design a car for a company run by his long-lost brother. Homer, to no one's surprise, fails so miserably that he drives his brother out of business. One of the things that makes this Simpson's clip so interesting is that Homer has real dreams for the car that are perfectly reasonable. As designers, our job is to figure out people’s problems and desires and then translate those into great products.

• Homer wants a large car, since he is a family man with three kids and two pets, but he doesn't want to be distracted by his family and pets while driving
• Homer wants places to put his drinks.
• Homer wants an easily recognizable care as he struggles to find his car when he parks in a large parking lot.
• Homer wants a car that is pretty quick because he wants to feel alive every now and then in his suburban dad life.
  All reasonable requirements, right? User feedback is something that should be considered in the design of every product. Honestly, the biggest requirement for any product should be that it solves actual problems.

So why did Homer's car not turn into a great success? The story implodes because the car company also let Homer design the actual car. While Home might be great at recognizing the problems he is experiencing, he's simply not a designer.

Our job, as designers, is to understand a problem and find the best possible solution. We can utilize user interviews to gain insights and test a thesis, but just like any data insight, they should steer our decisions, not fully educate them. Homer fails because he can't take his very sensible requirements and turn them into a great product. It's nothing against Homer, in fact almost no user can.

A camel is a horse designed by committee

Humans (research shows - men much more than women) tend to want to solutionize. When we understand the problem, we want a solution, right? Most of us tend to either take the approach that 'we're not designers, so we can't really say anything' or the complete opposite.

Mike Monteiro puts this brilliantly in one of my most overused quotes throughout the years:

I DON'T KNOW anything about design. Bullsh*t. Look around you. You make choices based on design every day. Even if you can’t design those things yourself, that doesn’t take away from your ability to decide that was the chair you wanted to sit on, or the shoes you wanted to wear, or the car you wanted to buy. You know bad design when you encounter it. From every chair you’ve sat in that hurt your ass, to every coffee cup that burned your hand, to every time your finger triggered the wrong link on your phone, to every airline booking site that pissed you off. You know bad design. You hate it.Mike Monteiro - You're my favorite client

It's true that we all know bad design when we experience it. Attention to the user's experience has been a focus for the last few years, and we've become better at spotting not only bad design, but bad user experiences. Everything from confusing navigation to checkouts with way too many steps and friction.

We need to be capable of understanding all of the context around a problem before we start to design a solution - full disclosure: designers tend to be very quick at coming up with solutions too early in the process too! User research and problems needs to be distilled down to core principles and, most importantly, to a strategy. We need to follow these principles vigorously throughout the whole design process. As the project progresses, we need to stay true to the principles even when feedback starts to appear from every direction. The most certain path to a failed project is trying to please everyone all the time.

Coming from Sweden, I've been on numerous projects where the consensus always seems to win. This, essentially, meaning that no one wins. Sir Alec Issigonis, designer of the iconic Mini car famously said: "A camel is a horse designed by committee."

A structure creates usability

I’d prefer to set purpose and structure for each phase of a project. In larger meetings with stakeholders, we can agree on what problem we are solving, for whom and, most importantly, why it needs to be solved. A smaller team of strategists and UX designers can then regroup and brainstorm on possible solutions given the context and framing that the larger group agreed upon. As we define these requirements and constraints, we make sure what we’re building will be functional and reliable. When creating the wireframes, we can order and arrange each feature in a way that’s logical for the user so the product will actually be usable (keep in mind that usable and useful aren’t the same thing!).

Once that solution and framework is set, the visual designers can work on solutions that will bring the experience to life. For a long time, moving from wireframes to visual design was just considered the ‘making the thing pretty’ stage. Truthfully, taking wireframes into visual designs is not about making things pretty, but rather about making things a pleasure to use and with which to interact. During the visual design stage, we can make our product even more usable, but it also gives us an opportunity to make something that’s a pleasure to use.

To summarize: each step of the project is important in itself, but to have a successful product, it's crucial to separate the desired actions and outcomes of each step:

1. What to build, why and for whom (strategy)
2. How it should work and why (UX principles)
3. What it should look like and how it should act (visual and interaction design)
   By following these steps we can minimize the risk of creating the digital equivalent of Homer's car, or worse, a camel when users specifically asked for a horse.