CIO upfront: Don’t build ‘The Homer’

How a mindset change can deliver a better product, writes James Hartwright of Certus.

Comments

Back in 1991, in The Simpsons episode Oh Brother, Where Art Thou? Homer is tasked by his long-lost brother, the head of a car company in Detroit, to design a car for the everyman. The resultant car is such a disaster it bankrupts the business. Now, making a bad product or app is unlikely to bankrupt your organisation but, done badly, it can be very painful – if not only to your ongoing employment!

So where did Homer’s brother, Herb (played by Danny DeVito), go wrong; and how can you avoid it?

Here’s a four-step plan to maximise your chances of getting it right and delivering a product that delights.

Step 1: Get as close to your customer as possible

Herb: “Homer, I want you to help me design a car that will appeal to the people of this country. I want to pay you $200,000 a year!”

Homer: “And I want you to let me!”

Herb fell into the trap of thinking that one person, even an everyman, could cover the core features needed. Also, as we’ve seen in many design sessions, Homer brought all his biases into the design process - even firing an individual who came up with their own idea that he disagreed with!

Your starting point should be to bring in people who currently use your product or website/app: let them help you create the new product or its next iteration.

Do not sit them all in a room and just ask them “what do you want?” or “what’s missing?” Think human-centric: work through what’s important to them, go wildly and excessively creative (ask “what’s your utopia?”), even go through their “day in the life”. Next, mock up some interfaces and interactions and experiment: you don’t need a sexy prototype here either – humans are geared to abstract thought.

Also, make sure you get a good cross-section of types of users to cover all aspects of the product. You’ll find common features, but you may also discover unmet or unarticulated needs that you hadn’t even contemplated. Your mindset should not be “how can I get you to use my product!” it should be “what brings you to use my product (and brings you back)?”.

If you have an existing system, gather and analyse the information you already have, such as app/web logs and page tags. These will allow you to visualise the customer journey – effectively to see the common behaviours of your users. You’ll see some well-trodden paths, but you may also find people getting stuck, which we call a ‘stutter point’. Both will be valuable in your discussions with users. If you don’t already capture this information, there are tools out there that can help you quickly and easily capture and analyse it.

Step 2: Iterate and iterate quickly

“All my life, I have searched for a car that feels a certain way. Powerful like a gorilla,yet soft and yielding like a Nerf ball. Now, at last, I have found it,” said Homer.

Homer and his design team were locked away for months, drawing together Homer’s monstrosity into a final product. When unveiled, Herb realises he’s doomed.

As we all know, it’s way easier to fix something up in the first few weeks than it is when it’s two weeks until launch. Don’t wait to test a perfect product when a workable prototype will do – and building and refining prototypes is becoming cheaper and cheaper to do.

Also, don’t forget to take your prototype out ‘on the road’ and put it through its paces in real-life scenarios, for example, if your app is commonly being used in bright sunlight you’ll need high contrast for improved readability.

Using a 'design thinking' approach and weaving in data science means you avoid suffering the same expensive fate as poor Herb.

Step 3: Ensure you keep focus on the things that matter

“Some things are so snazzy they never go out of style!

Like tail fins... And bubble domes... And shag carpeting...”

In the excitement of building a new product you can very easily add features that don’t add to the experience (and you can waste a lot of time getting them ‘just right’). Map out the core features (the MVP or ‘minimally viable product’) and keep on checking back that you haven’t lost focus. You can always come back and build those extra features later; oh yes, don’t discard them when you’re whittling down to the core – make them part of your backlog of future work. For those of you who haven’t picked it up yet, this is a core part of the Agile methodology.

Whilst constructing your new app, make sure that you add some contextual tags or logs – it makes the customer journey analysis process way easier ongoing…

Step 4: Keep an eye on how the product is being used

The fourth step is to keep an eye on how your product is being used: you may find that the ‘flow’ you had doesn’t quite work; or doesn’t work for a certain group of users.

Look both inside and outside your organisation post-implementation: drawing out common themes of feedback about your product not just from the call centre or email complaints. Go out and look at reviews and social media posts – and look for trends, sentiment, and tone – even better if that feedback is positive.

Repeating the analytics part of step one of the process is a must – you may find new stutter points; ironing those out before you take the product any further is crucial.

So, what?

“The Homer” never made it to market successfully; although a real-life version was later used in the 24 hours of Le Mans race in 2013. It’s clear that the car was aimed at one person and their use – Homer – and from that point it was doomed.

Thinking about the user experience and adjusting your mindset towards those needs is core to a methodology called ‘design thinking’ – to create desired outcomes that benefit the end user.

Note the words ‘desired outcomes’ – it’s not about everything that the customer might want; it’s to match their needs with what you need – and sometimes what’s technically feasible.

All that data analysis: it’s part of data science – and in this case focusing on the behaviour of your users to look for those desired outcomes. Used effectively, it can bring clarity to what looks like a mess of unconnected data.

Using a “design thinking” approach and weaving in data science means you avoid suffering the same expensive fate as poor Herb.

One final point: more than 26 years after the episode aired, some of the features Homer selected (or a variation of) have made their way into cars. Homer would therefore be a great person to have in your user group – just not the only one.