|
|
Saturday, March 1, 2003 |
Anyone my age or younger who works in a tech field has probably played a role-playing game at some point in their life, which helps make the technique comfortable: instead of rolling up a "dungeon-crawling party", you're creating a set of characters that will try and find the treasure lurking in a system ("you are in a maze of twisty little dialog boxes, all alike").
I often use personas when I'm writing a project plan: "this is what Gerry the Graduate Student needs", "this is how Randy the Researcher benefits", etc. as a way of helping others organize the abstract needs and benefits of the system. I'm particularly fond of introducing a character or two who will not benefit from the system, and explaining why their needs will be neglected, as one way of trying to avoid feature creep in the planning process. Often, the "system doesn't help them" persona is resembles the programmers I'm working with: they often like things that the end user will not. My mental model for that persona is a very sharp guy from our CS department, who attended a design meeting for a project I was involved in several years ago and announced "I actually don't care what interface you put on the thing; I'm just going to write Perl and use direct SQL calls anyway, so do whatever you want." Not building an interface that we thought would make him happy was probably an all-around win: he didn't want it, we didn't waste time creating it, and the users who wanted a graphical interface got one that matched their taste, not his.
Alan Cooper's software design book The Inmates Are Running the Asylum was my first thorough introduction to the technique, and I recommend it.
If you want an example of using personas, hop over to Mark Pilgrim's Dive Into Accessibility (Thirty days to a more accessible website) and check out the people he introduces at the start of his discussion.