After his talk for the PALINET & event yesterday, Jonathan Clark of Elsevier came over to me and said, “You were nodding a lot, does that mean you liked the talk?” It was (for me) the best talk of the day!!
Jonathan talked about user-centered design and how it has been used at Elsevier. It’s important to note that most of us can’t afford to do some of the things that Elsevier did – but that doesn’t mean we should be limited in following the principles outlined.
The presentation started with a story. Jonathan used to be a scientist, so he thinks he knows how scientists think – he’s got the inside track and he can design the perfect tools for them. His colleague is married to a scientist – and so she also thinks that she has the inside track. The two of them always get into arguments on what design is best for the user – but when the user is asked – it’s always different from what they thought. The fact of the matter is, that even if you’ve worked with the user, been in the user’s shoes, or are married to the user – you are not the user – and you don’t know what they want or how they think without asking them.
First and foremost, we have to be user-focused in our design of web applications. By starting with the user you can avoid what Jonathan calls opinion wars. Opinion wars are what was defined in the scenario above – everyone thinking they know what’s best for the user. Stop thinking for your user and ask your user – observe your user.
The second principle is that product development should deliver just what’s needed. I know this sounds somewhat slacker-ish – but the fact is, there is no reason wasting time and money on something fancy when the user just wants the simplest tool. This will hopefully help you avoid requirement wars – discussions where everyone thinks they know what features are going to be required to make the new system the best.
User-centered design has three steps:
- Understand the user
- Design for the user (possibly using personas)
- Evaluate the user interface (not the user) – the users aren’t stupid it’s your interface
A tool of user-centered design is stories. Stories are short 1-2 sentence descriptions of the users’ wants. These stories usually look like this:
“As a ____________, I want to ____________, so that I can ______________”
This gives you a clear picture of your user and the goals he/she has.
The other method that Jonathan discussed was Agile development. We went over this a bit in my systems analysis class last term, but Jonathan’s definition was much simpler.
The Agile development methodology is iterative and time-boxed – meaning that there are specific iterations and each iteration has a goal assigned to it. You complete the goal in a set amount of time and at the end you have a working product for that goal (not a wire-frame or a screenshot). With Agile programming you need a dedicated team and you need to be customer-focused. Lastly, you have to intensively test the product – with the user!!
This means you have to show your software to the users – and frequently, don’t worry so much about it not being perfect or looking just right, the goal is to see if the product does what the user wants/needs. This testing with and showing to the user will lead to constant refinement and a better product!
In short, when the product revolves around the user, you get a better product. You also (theoretically) get teams that have a common focus – which leads to better collaboration by all.
Jonathan made me want to go out and pick up a few books on the topic!!if you’re interested in seeing the slides.