There is a wonderful scene in the peerless 1980’s UK comedy Yes Prime Minister where the wily Permanent Secretary for the Department of Administrative Affairs Sir Humphrey Appleby is given the results of a piece of research which he doesn’t like. The Principal Private Secretary, Bernard Woolley gives him the bad news “The party have had an opinion poll done and the majority of voters are in favour of bringing back national service.” Without blinking Sir Humphrey replies “Well have another opinion poll done showing the voters are against bringing back national service!”
The brilliant script and impeccable timing ensure that the scene has lost none of its poignancy thirty years later, and like the very best comedy its funniness lies in its accurate portrayal of the truth.
The truth it points to is that in any programme of research, there will be outcomes which suit us, and outcomes which don’t. And like Sir Humphrey, our desires to get the outcomes which suit us can be almost overwhelming.
This presents a significant challenge for those of us involved in high–performing design.
Imagine for a moment you are a product designer, and six users are scheduled imminently to carry out usability testing on your prototype. How would you like that test to go? Well, if you are anything like the author, you would like the test to go brilliantly. You will want your users to say how easy the product is to use, how innovative it is, how powerful yet simple its interface is, and so on.
And it’s not just the author who feels this way. Many people involved in design vest a little of themselves in their work and it’s only human that we want it to be effective.
This subconscious bias can manifest in research involving too–easy usability tests, setting the wrong scenarios and tasks and asking leading questions.
In order to avoid the bias of setting up research to reinforce our pre–set ideas, digital leaders must seek to build cultures where it is OK to be wrong, and where finding out that you are wrong is encouraged. Just as the best of science is based on publishing findings to be peer–reviewed, so the best of design must be based on user–review as a means of road–testing design.
The language of design has evolved to support this and two phrases in particular resonate with this author as particularly helpful.
Design hypothesis not design
All design is a hypothesis until it has been tested by a user and therefore it should be a called a design hypothesis and not a design until such times as that has happened. It serves as a helpful reminder to teams that the design is merely hypothesis – a prediction – until such time as that prediction has been proven right or wrong.
User testing not user validation
Few designers will argue against user feedback as an essential part of the design process, however it is more helpful to call this user testing than user validation. User validation infers that you are engaging with users to validate your work – tell you that you are right – whereas what you really need is users to test your work – tell you where you are wrong. It is a subtle but important aspect of the role of user input.
It is a curious characteristic of humans that we love being wrong. In a room of 100 people, where 50 believe in a religion and 50 believe in no religion, through simple mathematics, by definition 50 of them must be wrong. Yet those 50 people hold on to their wrongness with fervour and enthusiasm. It’s not being wrong that we find so difficult, it’s finding out that we are wrong that stinks.
Being fervent and wrong kills design. That’s why the best design teams make it as easy as it can be to be wrong. Subsequently, we need to change how we talk about design.