Design is all about the search for form. For software, this means answering questions like “What should this software look like?” and “What interactions should be allowed?”.
At my previous company, the products we developed were all server-side backend type software that talks to machines – of course there is always a human user somewhere in the system, but they could be really hard to find sometimes. And most of what we did wasn’t about the user at all – it was about the client (usually a bank or a big retailer). They had questions like – will this software be stable under heavy load, e.g when the Easter shopping season comes? Will it be secure enough? Will my Visa and Mastercard audits pass this year? Can we take my POS terminals out of the loop for those audits and so reduce the cost? And so on.
Then I started work at Polymorph almost a year ago. And suddenly, EVERYTHING is about the user. Will the user care more about this information or that? Will this interaction confuse them or draw them in? Are we risking alienating the user by disregarding X?
If we think we can figure out what our users want and need from our software without involving them in the process, we are kidding ourselves.
I find it instructive to compare the design of software to the design of physical objects. For a physical object to have a positive impact on people’s lives, it has to plug into the existing behaviours of those people. Take for example the rocking chair. The reason it is a timeless successful design, is that it plugs into existing basic human needs and behaviours – sitting and rocking, for the purpose of soothing yourself or the infant in your arms.
The design of an object or piece of software should also take account of the user’s personal narrative. We all have a personal narrative. You know, the story you tell yourself about yourself. For most people the only audience that really matters for this, is themselves. Take for example bumper stickers: What bumper sticker you choose to put on your car is entirely to do with what you (want to) believe about yourself. You know people in traffic don’t care about your bumper sticker, because you don’t care about theirs. For our software designs to be successful, they need to take this “personal narrative” into account. And so, we find that if we want to make software that is relevant, useful and actually gets used – there are some things that are not negotiable:
- We want to talk to real users to get to know them, and form some idea of what they would use the proposed software for, and why this would be important to them.
- We want to run user tests; where we don’t just get users’ opinion on whether they might like a given feature, but also get to see how they actually use what we’re proposing to build.
People who design physical objects have understood this for a long time – which is why rapid prototyping is such a familiar phrase, and 3D printing is turning into big business. 3D printing is the easiest and cheapest known way to put early prototypes in the hands of actual users, so you can see how they use it and what needs to change in the product.
There’s another great reason for talking to users early and often, and getting regular feedback in general: Since you’re reading this, I’ll assume that you’ve come across the phrases “known unknowns” and “unknown unknowns”. For example, as I’m writing this I know that there are things I don’t know about your family life. Questions like: Are you married? Do you have children? Do you have any siblings? There is a far greater universe of things that I not only don’t know about you, but I can’t even formulate a question, because I don’t know what information I’m missing. For example, you might suffer from an irrational but absolute terror of the colour green. Now imagine my trying to convince you that using a green-themed app will make your life better somehow!
There is a far greater universe of things that I not only don’t know about you, but I can’t even formulate a question, because I don’t know what information I’m missing.
There are two important points about these unknown unknowns:
- We could stick our head in the sand and feel better for a while, but the truth is that at some point they will inevitably leak around the edges of our world and affect our projects and businesses.
- The only reliable way to uncover them is to build something real and send it out there into the real world – then observe closely to see what happens.
This “randomness” that is inherent in the world we live in, is no bad thing – and it isn’t to be feared or loathed (that would be a bit like fearing or loathing gravity). Instead, it is to be acknowledged and catered for by remaining flexible. Indeed, this is why Agile software development practices exist in the first place – short iterations that aim to deliver usable product increments for the purpose of gathering feedback, is a great way to uncover these unknown unknowns early on. Once we’ve uncovered the new information, we can adjust to reality. Before we run out of time and money to build the product.
If you are not convinced yet that there’s a strong need for individual users to be approached, met and facilitated into testing the new software – then consider the experience of the US air force in the 1950’s. They took 4000 pilots into a study and measured 10 physical dimensions of each of them, then averaged out the answers to arrive at a physical description of an “average” pilot. They then told aircraft designers to make sure that new aircraft must fit an “average” pilot ±30% in each dimension. So they built some aircraft based on this requirement. After the ensuing crashes and fatalities in these new aircraft, they dug a little deeper and found that not a single one of the 4000 pilots fell within the 30% range on all 10 dimensions. If you picked out 3 of the dimensions, only about 3.5% of the pilots in the study fit within the range. This gets even worse when you consider that the US air force (like any other air force) are pretty strict about the physical dimensions of the people they recruit in the first place. So you would expect the pilots to be fairly homogenous… but no. Clearly not.
Now Imagine designing software to fit a hypothetical or average human psyche! If we think we can figure out what our users want and need from our software without involving them in the process, we are kidding ourselves.
