Understanding the User's Perspective

Recently I encountered what I thought was an interesting allegory in regard to software development and understanding the user experience.

My three year old approached me with her bottle of milk and requested more, insisting it was empty.

Exhibit A - One non-empty receptacle

I assessed what was presented to me:

1. There was milk in the container
2. The straw reached the current milk level
3. The straw was not blocked (I didn't feel like milk. I did not enjoy this test)

It worked for me.

So I returned the bottle and went back to ... cooking dinner. Right, let's go with that.

The user child came back telling me the page bottle still wasn't working, so I asked for a demonstration.

Of course, the user was doing it wrong.

All programmers know this is the eventual outcome because the user is always clicking the wrong buttons at the wrong times. The real challenge is working out what to do next.

In this case, I filled up the bottle with more milk. Any other outcome with a boundary-pushing young child will not be acceptable.

However, once gratified, I also educated the user with not only the appropriate use but why that's the case. I think the reason "why" is as opposed to "just because" is partially what's wrong with society's ability to comprehend and assess new information.

Have you worked it out yet? 

She was turning it upside-down to have a drink. This meant thanks to gravity, the milk was no longer near the end of the straw, and it was deemed 'empty'.

I figured she turned it upside-down because that's how most of the other drink bottles work. Then I realised that's not accurate. Most of her bottles involve sucking liquid up a straw. I'm not sure why she often makes this mistake with this particular bottle, but I figure if I teach her some basic physics, not only can she potentially work out the problem herself next time, but maybe even apply the reasoning to other problems.

So perhaps two lessons

1) Watch your users. Don't be creepy about it, but somehow I'm always stunned by a number of notes I make when watching users operate software.

2) Educate your users. There are so many ways you can give your users cues as to how to use your software, but the best-designed tools don't need instructions. They're inherently intuitive.

When testing our own software, the more we can think like users instead of developers, the better our product will become.

Sounds like an old adage, but what do you think of the analogy? Have you encountered similar ways to relate to non-IT folk?