“If I had asked people what they wanted, they would have said faster horses.”
That Henry Ford quote is equally loved and despised by my friends in the startup community. Some see it as a celebration of the mythical designer genius. The next Steve Jobs who’s going to kick the world out of its passéist ways. Others see it as a celebration of authoritarian design in which egotistic designers ignore the people they pretend to help.
In that evergreen debate, user-centered design seems to be the flavor of the month. That approach to design proposes to start with a study of user characteristics, their environment, the tasks they do, and the workflow they adopt. Only once we’ve learned about our users and their need should we take our pen and start designing the product.
User-centered design sounds like a wise approach. Petulant kids invent spaceships that no one will use while us, serious designers, we take things slowly. We talk to people. We show humility. We are wise and mature.
And we suck the whole fun out of the party.
I was recently reading an article touting the merits of user-centered thinking and how it should be adopted by everyone in the software industry — not just designers. They gave the example of a dev who implemented the export feature users had asked for. Our petulant coder dives into the task, wraps it up and ships it… What a mistake. If only they had talked to users, they would have discovered that they wanted to export their work because the software crashed too frequently! Clearly, our petulant coder did not have a user-centric mindset. Clearly, they started with how instead of why.
Breaking news: people hate crashes. They also hate slow apps. They hate unresponsive UIs. You don’t need user-centricity to solve these problems, you need good monitoring and devs who know their stuff.
User-centric design encourages us to ask why, but in doing so it evades the most important question: how many times should you ask it.
Let’s imagine Henry Ford surveying his users with a user-centric mindset:
— So, Mr. Cooper, why do you want new horseshoes?
— Because my horse’s feet are hurting, Mr. Ford.
Welcome to an alternate reality where the Ford Corporation is the maker of the great Model T Horseshoe, trusted by farriers all over the world. You’ll object that Mr. Ford is not that stupid…
— Why do you want to relieve your horse from its pain, Mr. Cooper?
— Because my horse is too slow when its hooves hurt.
Now you’re in the dystopian future where everyone has a genetically engineered super-fast Ford thoroughbred. You can even have it in any color, as long as it’s black. But Henry Ford is not quite done yet:
— And Mr. Cooper, why do you want your horse to run faster?
— Because I need to be at my brother’s place for the Superbowl!
Armed with that knowledge, will Mr. Ford invent the car, will he invent the Netflix viewing party, or will he skip a full century and give us the Metaverse?
The more you ask why, the more you end up with big and generic problems. Big problems have a multitude of potential solutions. These solutions are novel and alien to people. Therefore, users cannot help you figure out which one is the best. You have to build it, place it in their hands, see if they like it or not, and, above all, you have to iterate.
Humility is critical for designers. You need it to kill the countless darlings you will have to kill in order to build a product people want. But dressing up this humility in the fancy clothes of user-centered design is too often used to mute creativity, to artificially slow down energetic exploration, and to turn design into a bureaucratic process that may feel comfortable but is definitely not going to solve humanity’s biggest problems.
So, here’s to the petulant kids. Build that thing.
Phil Beaudoin 
