Designing Better Web Applications with Personas

At Sereno, we've been using Personas in projects for many years. In case you've never come across them before, personas are short character studies of the people who are going to use your website or application. They're usually fictionalised descriptions of real users, and they help you think through your design process from your user's point of view.

Last week I was treated to a marvellous session using personas run by branding & design expert Guy Anderson at Zero G Media. Not only was it a pleasure to see someone who really knows their craft run this kind of session but not having to actually lead myself, I was given a valuable opportunity to see how personas work from the other side of the fence. The key element with personas is taking your newly created character and then letting them loose on the new system you're creating. Setting a couple of well-chosen tasks and then really thinking through how you're going to make this work for Anna, Ahmed or Alan ensures your design will actually meet your user's needs. So as I sat back and let Guy do the work, I also got to thinking about session length and application complexity. I wondered if there are any useful metrics or rules of thumb we can apply when planning persona-led design sessions.

There has to be a correlation between application complexity and the length of time clients and developers get together to help create solutions. The only way you can do this on complex projects is to break this down into chunks. But how much time will your client need to put into the process - what are your planning overheads? UX experts will know this stuff and will quote for a (we hope) bells and whistles output based on their length of involvement in the project. But with smaller budgets, or for apps that run on Intranets or for back office systems, we simply need a low road approach that gets the job done with the minimum of fuss. To be clear - I'm not suggesting we try and shortcut this process but we simply don't need the same level of engagement as we do for, say, a consumer based iPhone App or complex web service application. I went back through the literature and couldn't find anything on estimating effort for this so I thought it might be helpful to make a stab at this myself by reviewing a few of our recent projects. Much of the following is taken from a web app we recently created for a client. We needed to create an internal equipment ordering system. Staff need to select items and raise orders; managers need to review and approve those orders; admin staff  process the orders; and finally, suppliers need to interact with the system to acknowledge POs & supply delivery details. In this instance we have four basic types of user on the system.

In an ideal world, we'd have a couple of personas for each user type but as we're not living in an ideal world, four personas will do just fine. We have about four basic screens per functional area (browsing, placing orders, editing, deleting etc) but probably at least twice that for the administrators who'll need to set up the products, categories and generally run and configure the system. You'll need to get your designers and client team together, set up your personas and set to work. Assume a useful rule of thumb to be one hour of design time per screen for this kind of project. Of course, you don't actually know exactly how many screens you'll really need - but you can estimate sixteen core screens based on four screens per area of the system. And I'm only talking about the high-level hard-working screens here. You'll soon discover that these screens will breed like rabbits.

But that's OK.

This starting point enables your team to really gain a shared understanding of what you need to do. Plus, plenty of the screens will be really easy - some will only take you a minute or so. Knowing the parameters like this from the get-go means you can properly plan two full-day sessions and be pretty confident you'll have this ordering system sewn up and ready to pass on to your programming team. If you want to make a start with finding out more about personas, try Steve Krug's concise classic Don't Make Me Think or for something a bit more in depth, I'd recommend Steve Mulder's The User Is Always Right. If you are interested in taking your design reading into a more general area, I first read Don Norman's The Design of Everyday Things almost twenty years ago, and it was the book that opened my eyes in this area - essential reading!

Living with Complexity is his latest.