I’ve often used the following reductionist metaphor with designers I’ve hired and managed to explain why code is more important than design (and, of course, why they’re better together).
There is a contest to build a car that can travel across the country. There is a team of designers and there is a team of engineers.
The design team approaches the problem as they normally would. They review the goal, they conduct interviews with the users to understand their needs, and they lay out use cases and success paths to inform their decisions. They get to work designing the most comfortable, ergonomic, beautiful, and effective car to achieve the task at hand. Not only would it win, it would do so while being an absolute dream to ride as onlookers lust after it.
The only problem is . . . they can’t build it. They perhaps can string together a few pieces, but the core functionality doesn’t operate, leaving them with only beautiful instructions.
On to the team of engineers:
They approach the challenge mathematically. They look at what is required and the raw input / output that will be needed to accomplish the task. They toil away to build something that will function, with thoughts of the person using it a distant concern. They arrive at a build that works, works efficiently, and that will succeed at the task. It’s uncomfortable, unintuitive, and difficult to operate. In short, nobody wants to operate it, but it will achieve the task.
Race day comes and the design team watches as the engineer team’s monstrosity drives away, winning the challenge in the most uncomfortable fashion possible.
I explain this silly example to illustrate a core truth: outputting something that actually works beats out well-designed concepts every time.
Designers are quick to point out the famous Steve Jobs quote: “Design is not just what it looks like and feels like. Design is how it works.”
This is certainly true, but Steve Jobs was also famous for something else: shipping. Design here is in the context of how things work. Work, as in function, as in actually doing something. A prototype in a design file does not fulfill this process.
Also said by Steve Jobs: “Design is a really loaded word. I don’t know what it means. So we don’t talk a lot about design around here; we just talk about how things work. Most people think it’s about how they look, but it’s about how they work.”
If you were trying to build a software company and could only hire one person, it would be prudent to hire the developer first to actually build something people could use.
Why I used this metaphor is all about setting a baseline. I’ve found designers who herald design as the utmost important fail to effectively serve others. It’s a reminder in humility and to bring any who would hold design above all back down to earth and back onto the team.
In speaking of a team, let’s enter one more group into our imaginary scenario: engineers and a few designers.
The new team meets together to review the requirements (build a car to travel across the country). They all meet to discuss how best to approach the problem:
The designers employ their empathy to help guide construction to produce something that is intuitive to use, comfortable, effective, and even desirable. The engineers push back on some points for practicality, fully adopt others as it helps in the goal, and put together the build plans based on the useful suggestions. The team produces a great-looking car that accomplishes the goal but does so in a way that keeps the user in mind and even makes it joyful to drive (perhaps someone would even want to buy it).
In short, the marriage of the disciplines produces the best result by far. The team is so much stronger than a sum of its parts or separated into the groups. When the designers serve the user and the engineers, it produces amazing results.
Always keep in mind the core truth that code is more important than design—and so much better when together—to help you stay humble and in service to your users and your team.
