When it comes to meeting the requirements of delivering a website or corporate application then the simple act of observation is a very easy (and cheap) technique to make sure you meet the underlying requirements for a system.  “Underlying”?  Because you can sit people down in a room and do traditional requirements interviewing for as long as you like but you won’t get all the requirements.  The truth is you never will but you’re certain to get more if you can fit in some observation.  It’s the same principle with recruiting staff: if you only give them an unstructured interview, then you deserve more good luck wishes than the candidate.  If instead you give them a structured interview, get them to undertake a short piece of real work, observe them in action and review the output, you may just hire the better person.  It’s a bit more effort to do the right thing: time well spent for those of you that have ever hired crap staff!

With observation, you might sometimes hear people talk about ‘ethnography’ or ‘contextual research’ but ‘observation’ seems a bit more plain speaking: let’s not try and impress people with arcane terms for the sake of it.  And let’s face it, whilst observation takes some skill and practice, it’s not that difficult to do once you learn what role is most appropriate for the situation.  And no, you don’t need to spend weeks shadowing people: a day or two can be spent accompanying people in their day-to-day tasks but in most cases, even an hour or two with someone in front of a pc or at their desk to see what they do, system or no system, gives an extra dimension to your understanding of what they need.  You’ll always want to do more than you can but don’t be put off by only getting a small amount of time to do this.

So how does observation fill the gap that traditional requirements gathering fails to fill?  Here’s a few reasons:

1. people talk in stories about what they do and these are once-removed from what actually happens, sometimes consciously and sometimes not – once you write up these stories, you’ve created a double abstraction from the truth,
2. people don’t remember everything – how can you seriously expect anyone to think of all their requirements by sitting them in a room and read over a draft document a couple of days later on email?
3. people really don’t know everything that they want – it’s a bit like expecting people to be totally self-aware,
4. people self-blame for getting things wrong and don’t report them – you only get to see the “ah, silly me!” moments through observation and more times than not it’s silly design more than silly user.

Observation can be a little challenging to start with and you need to be in the right frame of mind depending on the situation, seniority of staff etc.  Use common sense.  Remind people that they’re not being assessed or reviewed but you want to assess and review their current tasks and tools.  Don’t ask questions at every step.  And know when to be quiet.  For more complex scenarios and engaging with senior people then the observer should be more skilled and experienced and should really have some prior understanding of the world in which the users operate or they’ll spend the entire times asking questions about the meaning of terms (eg the relevant business sector for a corporate application) and being more of a hindrance than a help.

Observation will give you a good grounding to establish requirements but will also provide key input into two important pieces of documentation: the user profile (or persona – maybe don’t call them this, more bamboozling to talk up the art) and user scenarios/journeys.  These documents will greatly help the user clarify their requirements and also give the designers/developers some deep understanding of what exactly it is they should be delivering.

Don’t be shy of asking a few questions along the way.  There is of course the simple, killer question that you should ask: ‘how would you expect this system to work for you?’  It’s the sort of open question that could yield all manner of answers but most will say they expect it to be user-friendly.  Whilst you can probe for specifics of what they mean by that, it’s really down to the designers to work out what that actually means, through both design standards and good user research.  Don’t expect users to do your job for you, you have to tease things out.  Observation should help.  Testing out design concepts will help.  The question is always: do people get it?  That is, do they know what to do in the minimum of time?  Getting the information architecture right, following conventions and testing it with users early (pre-UAT) will also help to ensure it is user-friendly.  Good design knowledge and experience gets you a long way but you only know by testing.

If you’re observation testing a product then you might need to give users some clear tasks or ask them to do what they normally do – or some combination.  It really depends on how comprehensive you’re wanting to be.  If you’re testing at the end of a development then you should really be testing against the scenarios you developed with users selected to match the user profiles.  Again be clear you’re testing the product rather than the person.  It can be little bit difficult to stop yourself from helping but you must refrain unless the user gets really stuck: you’re not there to train them.  Ask people to ‘think aloud’ when they’re struggling.  Ask them how they felt about using it.  It’s a general, emotive question but one that sums things up holistically and will represent how much it meets their underlying requirements which are often pre-conscious and difficult for them to express.

So, you can learn an awful lot from a little observation.  It’s about doing the job properly and giving yourself half a chance of getting the user experience right.   Observation gives you a more rounded view of users’ requirements by seeing them in their natural environment.  The often missed added benefit is that these users will feel that their needs have been well attended to and, assuming you’ve built some good rapport and understanding, those positive ripples will work their way out to other users, customers and stakeholders to help build your brand or reputation.