A year later, watching Forrest Gump in the cinema, I learnt that the character she had been working on was Lt. Dan Taylor and the shot was of him on a shrimping boat. In the film Lt. Dan loses his legs in Vietnam early in the story. As actor Gary Sinise has two complete legs they had to be lost digitally for the rest of the film. So effective was the removal, and so integral to the story, that the audience did not question it. For an encore ILM went on use Matador to insert Forrest Gump into historical footage of JFK, Lyndon Johnson and Richard Nixon.
The special effects in Forrest Gump, like many of the very best, you simply don’t notice. They are so effective in supporting the story line and engaging you with the filmic experience, your attention is not distracted by them. And so it is with good technology products. All that clever technology, all those incredibly complex algorithms and details of what to do when – they are all best hidden. In their place should be simplicity.
I like to think of the user interaction with a product as a story. There is a plot, the big thing the user is trying to achieve (and that’s “feed the family” not “drive the car to the supermarket”), and the user and product are characters in that story. This gives you a way to tell the story to others (like engineers, designers, sales folks and management). You can tell the high-level story in just one or two sentences and it immediately gives the listener a framework to hang all the other details on.
As soon as you start to think of your user interaction in this way the detail gets really complex, really quickly, but you still have that simple structure and purpose to fall back on. Getting designers and engineers to think about what the user is trying to achieve in this way makes it obvious how simple the product is going to have to be if the user is going to remain focussed on their ultimate objective.
When faced with a difficult problem in the product about how it should act (perhaps when thinking of different circumstances under which a feature might be used), the favourite solutions is: “we’ll put in an option and then the user can decide which way they want it to work.” No! The user is concerned with whether there is enough cheese in the fridge to make lasagne, not whether the engine management system should switch from “performance” to “economy” modes.
So, come on. Think it through. Figure out how to make the product support the user in their ultimate quest and hide all the techie details under the hood.
The use should be obvious, the design clean and the user benefits will flow.
I work on a product which is used by a wide variety of users, to do many different things. The usual response when discussing the proliferation of checkboxes and drop-down lists depends on who’s responding:
Sales: “Let’s divide the product into different tiers and sell those at different prices, and break off some features into options at an extra charge.”
Engineering: “It’s too hard to do this automatically, we won’t slip the schedule if we just insert a user option.”
Product Management: “I don’t want this product to be a collection of hacks and workaround to deal with bad input that doesn’t conform to requirements or industry standards, how can we keep the interface clean and functional without breaking the release date?”
QA: “I don’t care whichever way you do it, just be aware that it’s going to take a lot of time to test that automatic option.”
How does the poor user ever attain their ultimate quest in environments like that?
Thanks for the comment Bruno. Love it, I can hear the conversations now!
You’re right, of course, the realities of delivering a complex product to a wide range of users with all the commercial limits on what you can do means that simplicity is often “aspirational”. You guys obviously sweat that a lot.
My plea is to stop folks just adding complication because they can. So often the response to a user need is to stick a widget on the product which provides an immediate solution, but adds to the complication for ever more.
“but adds to the complication for ever more.”
This can’t be emphasized enough. I don’t know how many times we’ve made the decision to drop the “nice to have” feature to make some release date, only to have to deal with the lack of that feature within weeks or days of making the decision to drop it.
If you know a feature is going to be necessary because you know the user story like Chris describes it, go with your gut and include the feature. Without it, you’re not REALLY making the release date like you say you are.
Thanks Patrick,
I love your comment about the release date. I think we could write a book on “The Mythical Release Date” – how software companies hit release schedules but never deliver a product…