LARP and the User Experience – Part 2

Introduction

In my previous post I briefly discussed the idea of personas and how character sheets can shortcut their creation. Well, having opened the can and found that worms were being strewn liberally all over the comments over on my LJ, I thought that’d be a good topic for part two!

One of the things I failed to be clear about is that these techniques are not intended to be used to make plans for an existing individual player. What they are intended for is when you are trying to plan for players or potential players that you don’t yet know and are not necessarily able to talk to, using information gleaned from players that you do have an existing relationship with. This might occur either:

• When you’re starting a new game and have a core of interested potential players that you know well, but when they are going to be supplemented by a collection of further players that you don’t know.
• When you have a larger game and don’t get the chance to interact with all of your players on a regular basis, and want to get an idea of how they might behave and what they might want based on the behaviour and desires of the players you can make contact with.

For smaller games, they’ll be less useful… but for larger games (or gaming organisations) they should help the people running the show to remember not all players are like them, and help them plan for players who are different.

With all of that in mind, the natural place for me to start here (since I seem to be talking more to a LARPer audience at this point) is to talk about the tools and techniques I work with in the day job to understand users, and then to explain how I can see these techniques being useful to LARP. I’ll also add in some tools and techniques I really should use, but don’t always get the chance….

It should be noted that I don’t use any of these tools in isolation as no single one of them gives you a full and clear picture. Instead I tend to mix and match in ways that are appropriate to the task in hand.

 

User Archetypes

User archetypes are rough outlines of “kinds” of user. They details what those people are like, what they might want to do and what resources they have available to them.

User Experience Design

I usually start by identifying a selection of key types of user – for example, in my professional life I might have the following:

• Business buyer – This is kind of person who is given the task of buying in a product to meet specified needs. They’re never going to use the product, but need to understand that it meets those needs. They have budget available to buy a product.
• Technical buyer – This is somebody who has a need of their own, and has the budget to buy a product to meet it. They may or may not use the product directly, but they understand the issues involved very deeply.
• Administrator – This is somebody who will set up the product so that others can use it. They’re likely to work with it to configure it and test it, but are unlikely to use it in anger.
• Occasional user – This is somebody who has access to use the product, but will only ever actually do so when they have a pressing need. They are likely to forget how it works between each use, and will start fresh each time.
• Day-to-day user – This is somebody who is required to use the software every day to do their regular job. They are likely to know how to do what they usually need to do, and are unlikely to be stretched beyond that.
• Power user – This is somebody who stretches the boundaries of day-to-day use, and actively seeks out new ways to benefit from the product. They are likely to experiment and try things that may break.

I actually have several more of these for the day job, and they’re named differently and much more detailed… but this gives you an idea. You’d usually generate these with a mix of pre-existing knowledge, and then flesh them out with a number of user interviews, which I’ll come on to later.

These are useful as a reminder that not everyone using the software is like you. They might only be seeing it because somebody is demonstrating it to them so they can buy it for their company. They might use it for a mere 10 minutes a month, but those 10 minutes might be the most panicked, time critical ten minutes of their working life.

If you’re aware of those different user archetypes, you can start to attempt to plan for them and design the user interface of your product to support their needs.

Once you have these archetypes, you can even work out some characteristics related to each of them. Using the above as an example, some characteristics could be budget, usage, product understanding

• Business buyer – Budget: High, Usage: None, Product Understanding: Minimal
• Technical buyer – Budget: Medium, Usage: Some (maybe), Product Understanding: Some
• Administrator – Budget: None, Usage: High initially, then low, Product Understanding: High
• Occasional user – Budget: None, Usage: minimal, Product Understanding: Minimal
• Day-to-day user – Budget: None, Usage: High, Product Understanding: Medium
• Power user – Budget: None/Low, Usage: High, Product Understanding: High

When you’ve got those characteristics, you can even explore further to see if there are any archetypes you are missing by combining characteristics in different ways. Many combinations won’t be relevant, but occasionally you’ll be able to think of a user archetype that you hadn’t previously considered.

Where this could be useful in LARP planning

Not all players are the same. Different players enjoy different things in a game, and may enjoy different levels of engagement. As an example, there are a lot of derogatory terms around for different styles of play – rules lawyer, primadonna, mother-hen, combat wombat, etc… None of which really help very much when it comes to constructively addressing what people want from a game.

As well as different styles of play, different players want different levels of engagement. Some want to play every game that’s going, and spend every waking moment thinking about those games and discussing them with anybody who’ll listen. Other folks want to play a game once a month. Neither is wrong, but they need different things from their games.

My very first, rough stab at some archetypes for LARPers might be as follows:

• First time larper – This is somebody who’d never larped before, and is either at their first event or about to be so. They’ve not done this before, don’t know the rules, setting, conventions or terminology.
• Casual larper – If they’re free and there’s a game on, they might turn up and join in, but they’re not going to commit to being there each and every time.
• At-The-Game larper – They’ll be at almost every game, but they’re only interested in playing when they’re at those games. They’re not interested in continuing to play online between games, or putting in detailed downtime actions. If a game’s nearby they might discuss it a bit at the pub.
• Active larper – They’ll be at almost every game, and will probably submit downtime actions between games so they can tie off loose ends and hit the ground running at the next game. They may well discuss recent or upcoming
  games at the pub, and might play the odd scene between games if it’d deemed necessary.
• Lifestyle larper – As well as playing almost every game, they’ll happily continue to play their character online or in spontaneous face-to-face scenes. They’ll submit thorough and detailed downtime actions so that they’re fully aware of what’s going on and already have a plan of action before they arrive at the next game.

This doesn’t cover playstyles at the game at all, and doesn’t cover things like enthusiasm for costuming or hoiw comfortable they are with physical activity… but it’s a start point.

If you were trying to encompass all LARPers, I’d suggest that there’d be a lot of sets of archetypes which would be combined to create the final archetypes. Some examples might end up being “Active, Gamist, Physical Larper” or “Lifestyle, Performance, Abstract Larper”. More likely, though, is that you wouldn’t be trying to cater for everybody, and would be able to just create a set of 10-12 archetypes that covered most of what was needed.

In terms of characteristics, the list above only really considers three: Experience, Commitment and Out-of-Game Enthusiasm.

Taking character choice into account

The above list also only consider the players themselves, and not the characters their are going to portray – this is particularly relevant as people often choose to play somebody very different from themselves – being able to do so is a large part of the appeal for many people. If you then only consider the player, you are missing out what can be learned from their choice of character.

Thankfully, when players create or choose their characters, they are making a statement about what they want from the game.

Many game settings come with established groups that characters can be part of, and the choice of group implies that the player wants to have some engagement with the values of that group – either as somebody who supports those values or who rebels against them.

Similarly, many game systems come with predefined skills or abilities, and the choices players make when they initially chose or create are a statement about what they want or expect from the game. For example, a high level of combat ability and little else suggests that they wish to use that combat ability. A mix of combat ability and other skills suggests they expect there to be combat, but implies they wish the other skills to be important or relevant as well. If they have no combat skills, it suggests that they may wish to be able to avoid combat.

When looking at choices made on character sheets, you have to take the context into account – if combat is a default part of the game setting for instance, a choice of combat skills is essentially a choice of “I’d like my character to last more than an hour, please!”. In situations like that, what’s more important is where the choices the player has made for their character differ from the wider baseline. For example, if almost every character has taken basic comb at skills, those skills are not indicative of a choice. However, the players in that same game who have chosen to take advanced combat skills on top of the basic have effectively made a statement that they want to use those advanced skills. Similarly, players in that same game who have chosen to not take any combat skills at all are effectively making a statement that they want the skills they chose instead to be relevant.

When you are creating archetypes, it may well be worth thinking about commonly used combinations of important skils. If most of your first time players tend to be combat focussed, then that’s something to consider including in that archetype. If there’s a specific subset that chose to be completely non-combat, then perhaps they need to be a new archetype.

A lot of work for 10 players!

You might be thinking “But I only have 10 players at my LARP! This is too much work!”. You’re probably correct, especially if those 10 players are all you’re likely to have. Your time would be better spent going down the pub with them a few times and having a chat. However, for large systems or organisations with hundreds or thousands of players, this kind of thing suddenly becomes very valuable. I’d say that coming up with a few archetypes becomes worthwhile when there are more than 30 players, or when you have a high turnover of players and are trying to find out why.

User Interviews

User Experience Design

Whilst interviews can be useful when trying to come up with initial User Archetypes, I find they’re more useful when you’ve already made a first stab at getting some archetypes, or when you’re ttying to understand a particular need. I find this for two reasons:

1. If you already have some archetypes, you can try to find people who are close matches to those archetypes. Your interview can then be used to better understand the archetypes and flesh them out, or it can be used as research towards creating a persona (more about them in a bit).
2. If you already have some archetypes, you can try to find people who don’t really suit any of them. The interview will help you work out why they don’t fit, allowing you to modify existing archetypes to include them or add a new one that suits them better.
3. If you already know of a need or requirement, but you don’t really understand it, the best approach is to find somebody who has that need or requirement and talk to them. You can then understand the need better, and find a way to express it in your personas or user archetypes and cater for it in future.

There are a lot of different techniques to user interviews, and they’re generally a tool I don’t get to use very much… but where I do I’ve found the following guidelines to be helpful:

• Plan at least some questions in advance – If you try to interview on the fly, you’ll end up asking leading questions, and will get answers based more on how you asked them than what you wanted to know. People tend to like to “do well” in interviews, and so will often try to say what they think you want to hear, even if you tell them not to!
• Avoid value judgements – It’s very easy to imply value judgements just by using the wrong word or even tone in a question. If the interviewee thinks that you don’t value their point of view, they won’t give it openly.
• Avoid direct questions about what they want in favour of indirect questions about what their needs are and why – You may get a direct and honest answer, but it probably won’t be useful. It’s far more likely that you’ll get a direct answer without any context or nuance – and the chances are that you already know the direct answer, and it’s the context and nuance that you’re lacking! Instead, try asking what they want to achieve and why. If you asking this kind of question in couple of different ways around each thing you want to know, you’ll usually get the direct answer that you’d have got from a direct question and more information about the context and nuance.
• If you can, have somebody else making notes, or video the interview and nake notes later – if you keep stopping to write notes, it leaves the interviewee with nothing to do but worry about if their answer was good or bad (it’s clearly one or the other, as you’re making a note), and means that you might miss something if they’re talking whilst you write.

Where can this be useful in LARP planning

The uses in a LARP Context are almost exactly the same as in a UX context. Interviewing some players will help you understand your players better. If you’re using user archetypes or personas they will help you flesh those out more too. If you’re not using those tools, the interviews can be useful just for some insight.

If intervi
ews are too much trouble, questionnaires can be useful too, but beware that ticky-box and multiple choice questionnaires will only ever give answers within the ranges you planned for, and questions that require written answers will be difficult when it comes to comparing answers. Both approaches are valuable, but have limitations. Other approaches that can be useful for getting responses based on thought rather than gut reaction are questions that ask the recipients to rank words or phrases in order of preference or importance, or that ask the recipients to place phrases or words under different headings.

Personas

User Experience Design

Personas may seem a lot like User Archetypes at first glance, and in many ways they are similar. Personally, I see Personas as a “next step” from user archetypes, and if used well they can be very powerful. Essentially, you build a fictional person based on one of your archetypes (or several fictional people if the archetype is quite broad), and you give them a name, goals, feelings and a context. Perhaps the best way to think of this is that a Persona is a character sheet and background for a fictional user, whereas a persona is just a character class in a sourcebook. You use the Persona’s “character sheet” to roleplay through a scenario involving your product or website.

This technique might seem a bit bizarre, but it is very effective indeed when it comes to helping you find bumps and glitches in the overall experience of the site. It helps get you away from your own knowledge of the product and lets you see problems you were blind to before simply because you already knew how it worked. In roleplaying terms, using your own knowledge of your product or site would be metagaming, and thereforce cheating!

The technique I tend to use for creating personas is one called Pragmatic Personas (by Jeff Patton), which is based around using knowledge you already have or can easily infer. How and why you already have that knowledge can vary – you may have already developed archetypes, or interviewed a bunch of people, or you may just know your users really well already and want to capture that tacit knowledge (knowledge in people’s heads, not accessible to others) and convert it into explicit knowledge (knowledge that’s recorded, findable and usable to others).

This technique has four stages to it, which I’ll outline below:

1. Identity

Pick an archetype or role and give it a name. If you’ve already created some user archetypes, this is a quick and easy step. Next, give the persona a name. A useful trick is to make the name and archetype alliterative – for example, “Oliver the Occasional User”. This makes it easier to get a quick grasp of the persona and so makes it quicker and easier to pick up and use. Giving them a quick sketch (that makes it stand out against the other personas) can help here too, as you can use the sketch as an icon to represent that persona.

2. Context

Write a quick summary of the situation of the persona. This covers their life in general, not just their interactions with your product or site. It should include other important things in their life, particularly if they may have a bearing on their involvement with your product or site. If they’re so busy that they only get to use your product or site occasionally, that’s an aspect of their life that should be noted – not just that they don’t use the product or site much, but why they don’t, and just as importantly, why they do use it on those rare occasions that they have time.

For example, “Oliver the Occasional User” has a job that doesn’t involve using your product, but once a month his boss demands that he generates a report that includes data that is only available from your product, and that he does it by lunchtime. So once a month he grits his teeth and tries to remember how to use it… and has to re-learn the product quickly enough that he can get the data and put it into his report in under an hour. He considers that usage an inconvenience and a distraction from his real job, and it always leaves him in a panic as he doesn’t really know what he’s doing.

3. About

Create a bulleted list of the goals or characteristics of the persona. This can be built from the identity and context. If you already have archetypes and have worked out sliding-scale characteristics that differentiate the archetypes (as explained in User Archetypes above), this is quite quick and easy. You simply build a sentence around each characteristic for the persona. Then, you look at the context and pick out any goals you can and note them down.

For example, “Oliver the Occasional User” might have the following:

• Oliver has no budget to speak of – he’s a minion, not a master
• Oliver uses the product very rarely
• Oliver doesn’t really understand the wider capabilities of the product, and doesn’t really need to
• Oliver has to produce a report on [Data X] by lunchtime
• When Oliver uses the product, he’s panicked, in a hurry and under pressure
• When Oliver uses the product, he’s going to be frustrated and annoyed by change, because it makes his life hard at a time when he needs it to be easy

4. Implications

Once you have the about section fleshed out, you can dig into it for things you can do to make this persona’s experience of the product a good one. You can then list those things as bullet points:

• We must never tell Oliver he has to spend money – he doesn’t have any! Only display license renewal demands to people who can pay them.
• We must never expect Oliver to spend time learning the product – he has neither the time nor the inclination.
• We must never require Oliver to understand the underlying principles of the product – he just wants his data and doesn’t care about the product.
• We need a clear reporting interface to find and create reports on [Data X] – Oliver doesn’t have time to research how to do it – he just needs to do it fast!
• We need to avoid scary error messages in the reporting interface – Oliver’s already panicking – if he thinks he’s broken something he might have a heart attack!
• We need to make it clear that the reporting interface can’t change, damage or delete data – If Oliver knows he can’t wipe or corrupt the data whilst creating his report, he’ll be less panicked about doing so.
• When we change the reporting interface, we must make the changes minor and easy to understand – If Oliver comes to the reporting interface and finds it totally different, he might have a heart attack!

Once you have all of those, you have a set of requirements to start designing around, and a set of tests to work through when the product has been built.

When the product is being developed, you can pick up Oliver’s persona and roleplay through his use of the product. If you find that he’s being expected to understand the underlying principles of the product, or is presented with scary error messages, you know that these are problems that need to be addressed.

Where this could be useful in LARP planning

The uses for Personas are probably geared more towards the out-of-character logistics and bureaucracy of a LARP, although they could be useful for identifying problems with plot uptake and engagement as well.

In terms of OOC logistics, you might build a persona for “Fi the First Time Larper” that looks a bit like this:

Identity: Fi the First Time Larper

Context: Fi is a first year physics student, and
is about to attend her first ever LARP. She’s never done this before, and is a little bit nervous as some of her LARPer friends tend to get a bit obsessed about it… and she’s worried people will think she’s weird. She doesn’t know the rules and one of her friends helped her design her character. She’s using borrowed costume that doesn’t quite fit, and isn’t sure she’ll be able to afford her own that’s as good as what her friends all wear. She doesn’t have much money, and has no idea how her friends manage to pay for all their kit and events. Fi enjoys watching TV, reading and going to rock clubs. She is also a member of her university’s musical theatre society and is involved in putting on a show once a year.

About:

• Fi has next to no money, and worries about how much things cost
• Fi has no car, and relies on lifts of public transport
• Fi has a lot of spare time in the holidays, but only weekends in termtime
• Fi has no lasting commitment to the game, and worries that if she makes one, it will eat her life!
• Fi has no experience of LARPing and minimal experience of tabletop roleplaying, and is worried she won’t “fit in”.
• Fi doesn’t want to feel like a weirdo
• Fi is both enthusiastic (or she wouldn’t be attending) and a little scared (they’re all a bunch of nutters).
• Fi is worried that she won’t understand the rules, or that she’ll be buried in trying to learn them all at once.
• Fi is worried that she won’t know what’s going on

Implications:

• We must keep the cost:value ratio low enough that Fi can afford to play. This doesn’t mean we must be cheap, just that we must represent value for money. Comparisons to other activities students are prepared to pay for are a good idea. (Publicity)
• We must make sure the event is accessible by public transport, or provide a means to collect people from nearby transport hubs (Logistics)
• We must try to schedule events within holidays, or run events that Fi can can travel to, play and get back from within a weekend. (Logistics)
• We must ensure that Fi doesn’t have to be so heavily involved that she must give up her other hobbies – it must be possible for her to miss a game or two and still be involved. (Plot / Publicity)
• We must not require that Fi spends her entire life involved in the game to stay involved – she must be able to just play at events without being sidelined. Make online play in downtime an optional extra, not a requirement! (Plot / Setting / System)
• When Fi arrives on site, we must ensure that she is made to feel welcome and not out of place. Welcome team? Newbie guides? Player Mentors? (Setting / Publicity / System)
• We must ensure that Fi knows that people from all walks of life enjoy LARPing – including people with serious, respectable jobs. (Publicity)
• We must make sure that Fi’s initial enthusiasm is channelled into getting her involved and active – if we ignore it, we’ll lose it. Newbie plots? IC structures to bring in new characters and get them involved? (Plot / Setting)
• We must make sure that Fi can pick up the basic rules quickly and easily, then pick up the more complex stuff as she goes along. We must not require her to memorize a whole book of rules before she joins play. (System)
• We must find ways to introduce new players to the setting and IC structures without swamping them with unfamiliar terminology or ideas. (Setting)
• We must find ways to allow new players to engage with core plotlines without knowing all of the history from previous games. (Plot)

This gives us a whole bunch of requirements that should be met for Fi’s experience to be a good one. If the team running a LARP were to meet all of those, they’d support new players pretty well. To use the persona when planning their games, they’d just need to step through what they think Fi’s experience of the LARP should and at each step, think “what happens now?”. If at any point you can’t think of an answer, or if the answer relies on Fi magically knowing what she’s meant to do without being given any clues, then there’s a problem that needs to be addressed.

Essentially, the Persona above is a character sheet and background for Fi, and the LARP organiser would play her as a character, roleplaying through the scenario of her arriving at her first LARP. Wherever Fi’s player gets lost, confused, or has to rely on out of character knowledge, you’ve found a problem with Fi’s experience, and an issue that you need to address.

This roleplaying of what Fi goes through, the decisions she makes and the actions she takes is called a user journey or a user flow, and I’ll discuss these in more detail in a future post.

In Conclusion…

The above are three techniques from User Experience Design which may be useful in planning or running LARPs. in Particular, I see them being useful to large LARP events, or large societies which run linked smaller events. Individual small games may find them useful if they have a playerbase that don’t know each other that well, but will almost certainly be in a better position to talk to all of their players, rather than having to use these techniques to represent them.

As with the previous post, I’m very interested in feedback and comments on any of this!