What's my speed?
I'm sure the Holden Cruze was designed and built by engineers that never actually drove any prototypes of the car they designed. It may have even been designed by engineers that have never driven any car.
It is so bad it makes a great lesson to every engineer that wants to build a great product.
Take a look at the following speedometer, which was taken by my passenger from a vantage point a little below my eye level. Forgive the bluriness. Now tell me what speed I was doing?
You can't right? The steering wheel is in the way.
Now, what is the most prominent thing you see (apart from the steering wheel)? That the transmission is in D.
What do your users need most?
The question these engineers never asked themselves is What do drivers really need to see? My answer to this is the following:
- My speed.
- My fuel.
- Any warnings or failures indicator lights.
- Maybe my trip computer. But probably not.
Beyond that, the other stuff is distraction. The least important thing I need to see is the fact that my car's transmission is in 'D'. It's always in D when I drive forward, and if it's not I have more prominent indicators - such as the road going the wrong way if I'm in reverse.
Great user interface matters
Why am I blogging about this? Here's a tip. Good engineering is good engineering no matter if it's mechanical, human-machine interaction or software. The key to useful software is that it is intuitive, and gets out of your way so you can focus on the task at hand rather than the system.
Have you ever driven a great car, or been lucky enough to fly a plane or ride a motorbike, and experienced that sensation where the vehicle melts away so that you are the thing moving along the road, or flying in the air. You lose the sense that you're turning a steering wheel or pressing a pedal, but instead you feel one with the machine. Computer programmers and novelists also attest to being in the zone, where the computer keyboard is forgotton and the brain becomes directly connected to the words appearing on the screen.
Test what you build
I doubt the Holden Cruze engineers actually put real people (you know, the other crash test dummies) in this car. Or even themselves.
Otherwise they'd have found out that:
- you bang your knee on a pointy bit of console every time you go to climb in
- you can't see the speedo without craning your head (or adjusting the steering wheel up to an uncomfortable height)
- you can't read the font for the speedo, and the graduations go in 20 km increments so it's pretty hard to drive at, say, 90 km/h.
- the 'auto' selector for the car lights shows the lights are on via my dash photo above, however I only had parkers on.
- today's date is probably the least important piece of information I car about while driving, yet it's the most prominent piece of information displayed on the multi-purpose radio display.
I could go on.
Use what you build
As software designers and engineers, we must use the thing we build. We must step into the shoes of the user.
This insight came twice during this day - first while driving to my customer's site, and second, while running the planned software simulation.
The simulation went well enough, and it was designed to have real users try and accomplish common tasks on a beta product while I watched - User Experience consultants will tell you this is an essential part of building great software. But I came away thinking that we could have picked up many of those issues ourselves, if we'd just stepped into the shoes of the users and run our own simulation.
Now, I'm not saying we can do away with customer UX evaluations. We never would have picked up the fact that a user thought an icon legend, which explained what various status icons mean, wasn't itself the way to change a record's status. And we wouldn't have been able to get to the bottom of terminology and workflow of the product.
But we've been so busy developing, that we have not had an internal full-scale simulation of using this software, instead relying on customer feedback to improve the system.
So, my first act upon getting back into my horrible hire car for the return trip, was to enter a meeting into my calendar - End of Sprint Simulation. All hands will be on deck for this, every fortnight one day before the conclusion of each development sprint. And we are going to set up a room just like our customer has, and run a simulation using data I took away from my customer's simulation.
Developers, like engineers, need to be users of their products.