Learning From History

Comparing Car Design to UI Design

Now that summer is over, it’s time to get back to business!

I have a unique perspective in the software world, having spent a chunk of years as an automotive engineer, working on some pretty cool cars. (And some pretty mundane cars as well as a few pick-ups, for what it’s worth.)

There are a surprising number of corollaries between car design and software design. First and foremost, you never let the engineers style a car. And as I wrote previously, you shouldn’t let developers design a UI.

Both products follow an engineering process. Both start with an idea that evolves and turns into a finished product. Both go through testing and a release cycle to the public. There are a remarkable number of similarities between the two, even though one is made from matter and the other is based on electrons bouncing around in the ether realms.

If we assume that there are valid similarities between the two disciplines, let’s take a look at the car development process and see what we can learn.

The preliminary stage of a car project is the market research. What kinds of cars or trucks are people interested in? How good is the competition in that market segment? What do they offer that’s compelling, and what features are a waste of money? Not just from the engineer’s perspective, but from the customer’s perspective—what is important and what is unnecessary?

Once you’ve determined the market need for the vehicle, who the target market is, what the critical features are that the vehicle needs to have, you go to work in the styling studio.

A team of designers throw out concept studies, often competing against each other, with cool design ideas. The best concept wins! Then the studio goes to work fleshing out the styling study. Determining wheelbase and doors and seat room front and back and trunk space and engines and rooflines and so on. The basic parameters that the cool shape has to fit around are determined.

Next the design is “fleshed out” and then put into flesh. Full-size clay models are created to see the shape of the car. In today’s day and age computer designs are created of the exterior. All of these details are executed with one final goal in mind: creating a vehicle design that will turn heads, entice customers into the showroom and persuade them to buy the car.

The old adage is, “Styling sells. Quality brings them back.” First and foremost is the styling. Create a great style and the customer is captivated.

How many software companies create the UI first? I have read that Apple created ten different working versions of the iPad before building it. Last I checked, that was a successful product launch.

Conversely, another company developed a product called Windows 8, working out the user interface in advance of actual product development. Critics haven’t been as kind, which I’ll cover in more detail in a subsequent post. As importantly, how they developed their UI is different–and significant.

Most companies design software from the inside out. They create the architecture, work out the software structure, code the software, and then append the UI on top, making sure that all the cool features they developed reside in a menu or button, and the features are grouped together according to logic the developers dictate.

But is this the way that users think? Is this the way that users will intuitively use software? Customers will flock to software that emulates how they will naturally work. Make the product too hard to use, bury features in menus that make sense only to uber-geeks, require too many clicks to execute functions, and the only way to succeed is if there’s a government mandate or the competition sucks worse than you do.

I say the solution is to take a cue from the auto business: style the UI up front. Work out the User Interface so that the customer will intuitively follow through the UI to complete what he needs to get done. Work out the User Interface so that the layout makes sense to the customer.

I was going to say “Make the UI logical to the customer,” but that assumes customers are logical. Some are, some aren’t. It’s been oft touted that a woman’s logic is different than a man’s. Do young people follow the same logic as old people? College grads vs painters and sculptors?

Logical isn’t bad. It just doesn’t work for everyone. I could do several blogs debunking the idea of “logical,” but the important point is that “logical” isn’t necessarily how the customer will use the software. The key is to make it intuitive. Make it so that the customer can sit down with the idea of performing certain tasks and easily perform those tasks. Throw in a little aesthetic on top of that and you’ve got it made.

NOW that you have a good, functioning concept of how the USER will interact with your software, code the whole darn thing! You’ll end up with a software program that can’t help but be successful.

And really, that’s the simplicity of the First Pillar of Going Viral: Great Product. Great product is defined by how well it matches what the customer will intuitively do (with few bugs and no major ones).

In the next blog, I’ll cover some well-known products and look at how well or poorly they adhere to this principle—and their success in the marketplace.