The Homer Simpson car is an invaluable lesson in building products

One of the first things I do in all of my classes is show this clip of Homer Simpson trying to design a car. I’m serious.

It’s a great lesson in how not to build a product.

Watch it, and then let’s walk through why it has so many great lessons for product design and development.

One of the things that makes the Homer Simpson Car clip so interesting is that Homer has real desires in a car that are perfectly reasonable. As designers, our job is to figure out people’s problems and desires and translate those into great products.

Homer wants a large car because he is a family man with three kids and two pets. He’d also like ways to not be distracted by his three kids while he is driving. He wants places to put his drinks.

Homer often 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 of this is great feedback from a user. Understanding the problems Homer faces and understanding his life is a great way to inform design. By utilizing contextual inquiry and user interviewing, we can find out the problems that people like Homer face and synthesize that data, and translate it into actionable requirements to build again.

Where the Homer Simpson Car implodes is that it lets a user actually design the car. Homer is not a designer. He has no idea how to design anything.

So it ends up that Homer has really bad solutions to his problems. He can’t take sensible requirements and make them into good product design. Almost no user can. Don’t let users design your products for you.

But good product design is not about letting your users design your products for you — it’s about solving users’ problems and making their lives better.

A lot of you are allowing Homer Simpson to design your products

“Whhhhhhhat?” I hear you saying. The ability to translate feedback from users (after gathering it in a methodical way) and translate that into requirements is a real skill.

Never ask your users what to build. Ask your users what they are trying to do.

Homer wasn’t wrong

It wasn’t Homer’s fault that the car he designed turned out so badly — it was the fault of the company that asked a random person off the street to design their product. A lot of you are letting Homers design your products and then blaming them when things turn out poorly!

Don’t ask random people to build your products. Take ownership over your own work, and take ownership on your users being successful.

Our most important job as product designers is to take ownership of the success of our users.

How can you avoid building the Homer Simpson Car?

Before you ask, observe

Start off with contextual inquiry. Watch people go about their lives and do their work. After you observe, start asking questions.

Rock your user interviews

User interviewing is a great combination with contextual inquiry. You observe, and then you ask questions. The key to good user interviewing is to ask good, probing questions. Never lead the user!

Translate your user research into thoughtful requirements

Synthesize your research and then translate it into thoughtful requirements. When you synthesize research, you should also be abstracting it. Build your requirements around solving problems for users. Focus on activities.

Activities go across users and often even cultures. Design for activities by translating your research into the core activities your users are trying to do.

Follow a well-defined rubric when designing new products

This is the rubric we use, and here are the guidelines for good product design we follow. It helps get everyone at the company to speak the same language and understand how we define good.