Before you can build anything, you must understand what it is you are building. And you can only know what to build if you understand who will be using it - users.

Users are often seen as the bane of any developers life, but this tends only to be because there is a big difference between how a user sees the system, and how the developers and maintainers see it.

"First, understand the users' world, then figure out how your design fits in"
- Giles Colborne, Simple and Usable

Developers have a deep knowledge of both the product, and the whole problem domain; they know that of course you'll need to enter the confabulator serial number and it's model number in order to read it's manual - after all, "that's how it's stored in the PU36 document server we use".
Users just want to read the manual though, and their confabulator is under the desk where all they can see is the front of it, the serial and model numbers are hidden on the sticker underneath, why can't "they just let me see a list ?"

This disconnect is all too common - when the system was built (or since it was built) no one (re)considered the wider scope of how it would be used, they just wanted to build something that worked and stayed working. What the developers needed to do was understand their users better, so they'd think about including some pictures of the different confabulators the user might have.

One of the ways we get inside our users heads here at Extravision is to use 'user personas'. These are easy to understand and get started with, yet can be surprisingly powerful.

The idea is to come up with a few different stereotypical users. If you were designing a car dealership you might have a family upgrading their people carrier, a company director who needs a new sports car and someone buying their first car.

Each user persona is then fleshed out with details about the way they work, in what environment and what their key goals are, often as a series of stories. You can find a good example on http://www.steptwo.com.au/papers/kmc_personas/index.html. For a family buying a new car they'll have visited the manufacturers web site and entered some details there while they browsed the range, but they'll also have brought their kids with them while they shop, who will interrupt the process. They'll also need to leave by a particular time to take the children to a party.

Now you know who your users really are, and how they might go about buying a car (or writing an email) you can begin to find out what users really want, which is the subject of the next article.