At the risk of sounding cynical, if you cast an eye over a typical project's practices and perceptions, it can make for ugly viewing. Pick a random sample, and I bet it'll look something like this:
- Interaction design: First create the system, then make the UI look nice.
- Documentation: No need, we're selectively Agile(TM).
- The user: The what??
- Persona Analysis: Create a totally fictional set of "typical" end-users.
Actually, that last one's a real best practice. On the surface it might seem as dysfunctional as the others - and personas have come under fire (pdf download) elsewhere in the industry - but used with care, the practice can be effective.
Popularised by Alan Cooper in The Inmates Are Running the Asylum, a persona is an abstraction of a typical end-user within a particular demographic, describing his or her goals and pain points. A useful way to start writing a persona is to picture that dreaded dinner-party opener: "So, what do you do?" And take it from there:
"Alice works in a video store during the day. She's worried that with legalised downloads taking over, her job might not be around for too long (but she needn't worry, legal downloads are so shackled by DRM restrictions that they're not likely to take over the home entertainment world anytime soon). Alice can operate the anachronistic customer database system on the in-store Windows 95 PC."
Personas are useful for identifying and documenting the expected skill levels of end-users, along with any basic assumptions about prior knowledge of the same or similar systems. They're meant to be used in tandem with usage scenarios (use cases, user stories, whatever) to describe the user/system interaction.
Instead of designing the UI around the system's evolving internal functions, the UI is instead designed around a discrete set of user goals. The persona shapes the UI design, because at each stage in the scenario you'd ask: "What would Alice do next?" or "How would she respond to this?"
So a bit of detail about the persona's private life helps you to empathise with them when thinking about the UI they'll be using.
A common mistake is to define loads of personas, in the belief that you're doing comprehensive behavioural analysis. In fact, the fewer the personas the better, because then you'll end up with a more focused system.
If you try to design for Alice, Bob, Chris, Denise, Eric and Fred, and Xavius, Yasmin and Zachariah, then you'll end up with a system that's as amorphous and ugly as if you'd done no UI design at all. Better to focus on one or two personas and create something that works well for the commonest use cases.
So will persona analysis really make a significant difference to the eventual product? In theory, yes. In practice, maybe. You're already likely to be designing the UI with a particular group of real users in mind, even if they're not normatively defined somewhere.
And that's where many people have a problem with personas: they're about made-up people, not real users. Their definition is often based on intuition rather than real data from exhaustive analysis of your user base. Another problem is that persona descriptions represent "soft" requirements: you can imply a requirement such as "Bob wants the system to remember his last search phrase", but it may or may not be picked up by the development team as a "must-have" requirement.
But, whether personas are truly effective or not, their real benefit is in simply encouraging people on your team to think about the users, and to think about the UI early on in the project. Both of those are good things. ®