What does a Nobel prize winning physicist know about UX?
What does Richard Feynman, speaking in the early sixties know about user experience research and agile development? Quite a lot as it happens. In this little clip he hits the nail right on the head, and as web publishers in higher education it’s nice to take inspiration from world-renowned academics once in a while…
This clip was used by Jeff Gothelf in his Lean UX for Enterprise workshop that I attended late last year. It’s stuck with me since, but I couldn’t quite weave it into my presentation and write up. (I opted for Charlie and the Chocolate Factory instead.)
What Feynman says
In general we look for a new law by the following process:
- First we guess it
- Then we compute the consequences of the guess
- Then we compare those computation results to nature, or we could say, to experiment or experience
If it disagrees with experiment it’s wrong.
And in that simple statement is the key to science.
It doesn’t make a difference how beautiful your guess is.
It doesn’t matter how smart you are who made the guess, or what his name is.
If it disagrees with experiment then it’s wrong.
That’s all there is to it.
Richard Feynmann, Cornell University, 1964
What that means for us
When we, as a business, attempt to solve a problem we have through website or software development, first we guess it. Or the customer coming to us with requirements guesses it.
And often that’s it. Development is undertaken based on a series of assumptions or untested hypotheses.
To paraphrase Feynmann:
- It doesn’t matter how beautiful your design concept it.
- It doesn’t matter how smart the person is that conceived the development, or what their position in the organisation is.
- If it doesn’t demonstrably work as a user experience delivering the desired business outcome, then it’s wrong.
Another great quote in the same vein, but from this millenium…
The worst way to design a website is to get five smart people in a room drinking lattes and posting post-it notes…The next worst way is to get 10 customers in a room drinking lattes and giving their opinions on the new design.
So my challenge to you is to help your colleagues and customers to phrase their requirements as hypotheses, then expend some of the energy you would normally put into delivering their requirements on validating what they’re asking for. Find out more from my previous post.