Simple personas and anthropomorphising systems

A number of people have written about the use of personas in system development in recent months, including Don Norman (ad-hoc personas and empathetic focus), although as Norman points out, they've been in use since at least the early 1990's if not longer. There's been some debate about the degree to which personas need to be realistic or fully developed (i.e. with a life history, career, lifestyle, hobbies, and names).

When building a system from scratch, using personas to help identify the real different kinds of users for the product is a very valuable exercise. Making these personas sufficiently detailed to allow for empathetic focus (as described in Norman's entry) is also going to be valuable.

But what about a different scenario, where instead of building from scratch, you're building a replacement system? This in effect is what we've been doing for AIHW with our metadata registry project. While the new system will allow the involvement of several new types of users who could not interact with the old system, these users have been in existence for a long time. And the team at AIHW are familiar with them - sometimes they even are them.

In most content management systems (such as Sytadel), the concept of roles (and usually role-based security) are well supported. What can be done and by whom is determined by what role or roles you have.

Thus a system role is effectively analogous to a persona.

Does it mean then that personas are superfluous in this context? Well, no, not in our experience.

First, the names of roles are quite long - e.g. metadata developer, metadata registrar - and this becomes awkward to keep saying aloud or writing in documentation.

Second, by using the name of a persona (a person), it assists in anthropomorphising the system to be.

And whereas anthropomorphism is often a practice to be wary of when analysing non-human things in the real or a conceptual world, it's precisely what we want to do when designing systems which incorporate some concept of a user.

With our current project, we found it was sufficient for our personas to be represented by names alone. This is just about the simplest persona possible.

So for example, our metadata registrar was called Reg, and metadata developer was called Dell, and Ursula was our general user. We didn't bother writing any details whatsoever about their background, interests or social lives. And we found ourselves arguing passionately about whether Reg would do this, or Dell would want that, because we knew precisely who they represented within the system.

A quick tip - use names that help you to remember the formal role. Otherwise you'll be forever asking, "Who is Penelope again? Oh yes [consulting persona guide], she's our system administrator."

Another quick tip - don't make the mistake of naming the system roles the same as your persona names. While the personas are meaningful for the design/development team, for long term maintenance the role name "metadata registrar" is going to be far more meaningful than "Reg".

(For some more reading, and some different perspectives, see Personas and Plogs, Using personas in intranet projects [via Column Two], Personas & Scenarios in the wild, and An introduction to persona and how to create them.)