Eggbox

Eggbox in Transit - soon to be settled again!

Category: Professional (page 2 of 3)

Pertaining to UX, UI, software and other stuff I get paid for

Of multi-dimensional sausage visualization and user experience design

I’ve been thinking of this post for a while, and have decided that rather than trying to come up with a better way to explain it, I’d just explain how I picture it in my head.  Consider this post to be one-part UX design related and one-part insight into my mental processes.

It’s a UX related thing, but I’ve not been able to work out how to explain it particularly clearly. It’s a discussion of the complexity of designing a user experience versus the complexity of the resulting experience, and how it’s far from a one-to-one mapping between the two. By which I mean that a really simple experience can be really complicated and troublesome to design, whilst a complex looking design is often the result of a *lack* of complexity in the design process.

Continue reading

A user experience gripe… about users?!

A Gripe About Users? You! Out of the UX club! Now!

To be clear, this is not really griping about users… but is instead a gripe about the way that businesses handle contact with users, and the way that they research and prioritize future work.  The users are merely the intermediary in this particular gripe.

To clarify further, I’m not talking about the kind of software that you’re generally familiar with, like MS Word, Google Chrome or Adobe Photoshop…  I’m talking about the kind of software that most of you will probably never see.  Enterprise software.  Software bought by businesses, rather than by people.  Software used by interchangeable cogs in corporate machines, rather than by people (or, given how the software works, that’s how it often seems).

So… what’s the gripe?

Well, I’m afraid I’m going to be a bit long-winded about explaining it, and start by explaining a couple of other things first.  Things that relate to how users complain, where they do so, and what happens as a result.

First, users complain when things don’t work or when things crash.  In these cases, users complain in the form of support requests or helpdesk tickets.  This results in bugs or defects (or whatever the company calls them) being raised in whatever tools are used for such things.  Usually there’s an urgency based on how quickly a fix would be needed and a severity based on what the impact of the problem is.  This is good and proper, and results in work to rectify the problems being scheduled and fixes released in some way.

Second, users complain when functionality they want just isn’t present.  In these cases, users complain in the form of an RFE  – a Request For Enhancement.  This will go through a process to see if enough users want it to justify the development time, and then it’ll be entered into an appropriate work scheduling tool, with a priority based on how many users want it and a “size” based on how many person-hours it’ll need.  This is good and proper, and results in work being done where there’s an appropriate amount of demand.

Thirdly, users complain when a piece of software works, but in an obtuse, counterintuitive, unresponsive or otherwise hostile manner.  In these cases, users respond by grumbling a bit and maybe swearing a little.  Or a lot.  Occasionally, they’ll raise a bug too, but it’ll get logged as low priority because, when it boils down to it, the user managed to get the job done.  Or they’ll raise an RFE… but it’s unlikely to get prioritized because the feature already exists.  As a result, pretty much nothing will get done.

What does this mean?

This all means that users learn how things work, and so stop bothering to complain about the painful stuff unless it’s the software equivalent of a leg falling off.  We never get to hear about pain, or about early symptoms… only about the moment that the patient fell over and died.

Obviously, this makes addressing the non-fatal problems a little more awkward.

Surely user testing is the answer?

Sure, it helps.  But only if the problems that are found can get prioritized and get some development time allocated to them.  What tends to happen is that the problems get identified, and then get logged as bugs or RFEs, which promptly get prioritized exactly as explained above.

If you do user testing, you create an expectation with those users that things will improve.  If you then don’t act on what you find, you’ve failed to deliver on an expectation, and that’s bad.

So how do you get anything done?

As you might have guessed, a large chunk of my professional life is spent around those third types of complaints.  So I’m pretty familiar with the “we agree it’s a complete dog, but we’ve got more important things to do than fix it” answer.  It can, on occasion, be a touch demoralizing.

So you have to find other ways to get work done.  Ways to sneak it in under the radar.  Like keeping a record of tweaks you want to make in a part of the UI and sneaking them in next time something else is being done in that area.  A bug in an area with ropey UI?  Fix the bug and tweak the UI at the same time – commit it all at once.  A bit of new development that requires some new UI?  Where’s the jump-off point that leads to it, and can we rework that jump-off point at the same time?  Can we push the work back up the navigation architecture to the layer above and sneak some extra changes in at the same time?

The problem with sneaking work in like this is with QA (Quality Assurance).  If you’re stretching development work beyond it’s original scope, you’re also stretching them – probably even further.  By taking slightly longer to develop something slightly better, you’re invariably squeezeing your testing time further and putting more load on that department.

A trivial change in the UI has to be tested in many environments, and with many different kinds of input – both good and bad. The load a UI change puts on a QA department can be exponentially greater than the load it puts on development.  If it’s extra work being squeezed in to improve the user experience… that’s work that QA may not have budgeted for, and so it makes things late and gives UX a bad reputation for delaying things.

What needs to change?

I think we need a new model for handling the third type of user complaint that I mentioned above, or we need to adjust the criteria for prioritizing them.  The problem is that we’ve spent so long conditioning users to an environment where it’s not worth complaining about mere pain – only about the aforementioned “limb dropping off”.  They’ve become so used to nothing being done about things being cumbersome and awkward that they’ll suffer in silence rather than complaining.

So two things need to change:

  1. As mentioned above, software companies need to make a viable route for handling “this works, but is like crawling through barbed wire” issues.
  2. Software companies need to then prioritize those issues and allocate development resources to them.

When those two things happen, UI developers and User Experience professionals may start to lose some of their reputation as interfering troublemakers.  Until then, we’ll probably have to keep sneaking work in under the radar, making everything late in the process like the meddling troublemakers we have to be.

Community Content is POO

I beg your pardon?

In some circles, the title of this post alone would be enough to get me thrown under a bus… and not for the language. I’d be hauled over the coals for the very fact that I’ve dared to besmirch the great god “Content”. But if folks are preparing to throw me under a bus, then at least they’re paying attention… so hopefully I’ll be able to get them to read what I mean by that statement first. It may not save the world’s ears from the horrible crunching sound as the bus casually rolls over me, but at least I stand a chance of getting the message out. So what actually is the message?

Community Content is essentially “Community Poo”…

…But that doesn’t mean it’s a bad thing. Poo is a sign of life (It really is! it’s technically one of the seven or eight acknowledged indicators of life), and finding it somewhere is a sign that life has been happening at that location. If it’s fresh, it’s a sign that it’s happened recently. It’s also good fertilizer, so it creates places that life (and activity) can thrive… but if you were to start declaring “poo is life!” you’d probably get a few funny looks and maybe a special jacket that does up at the back and makes you hug yourself all day long.

The same is true of community content. It’s good stuff, and it’s great evidence that a community has been active, but it’s not the community itself. A set of diverse forum threads with loads of posts in are not a community, but they are evidence that a community has passed that way. “Community content” is the trail of droppings that gets left behind by the real community, which is happening up at the front where the interaction is happening.

If you want to help keep a community healthy, it’s probably a good idea to keep an eye on the community poo, but it’s not *all there is*. Not by a long shot. Despite what Gillian McKeith might tell you. You should look at the ebb and flow of the community and look at the people that come together to form it. You should listen to what they say and how they choose to behave, not just at what poo they leave behind.

So what should we be focussing on?

If you want to keep a community healthy, it’s probably a good idea to keep an eye on the stuff that produces the poo. That’ll generally be the users. You want them to keep pooing, becuase if they’re not, it’s a sign that they’ve either left or died… neither of which is exactly promising for the longevity of your community. But don’t get hung up on preserving every bit of poo for the rest of eternity. Particularly memorable community poo will preserve itself – it will live on in the memories of the *people* who make up the community.

What are you getting at? What’s the point of this post?

If I really have to spell it out for you, the point of this post is that businesses should stop fixating on the community content and instead focus on the engines that generate it. Keeping the community alive and healthy so it can produce more community poo is far more important than lovingly and painstakingly preserving all the community poo that was ever produced.

All you lovely readers out there? Wherever you lot converse and discuss things, you create community. The stuff you leave behind when you move on? The content – the forum posts, tweets, status updates, blog posts and comments and all that stuff? That’s community poo. It’s the leftover sign of community interaction having happened. It’s fertile and creating it is good and healthy, but if you’re fixating on it too much then you’re doing it wrong.

Don’t look a pile of poo and call it a nice meal. Don’t look at a heap of forum posts and call it a community. In either case, you’re looking at what’s left over after the best bit’s happened!

The trouble with online identity

I think that most people who design and work with online communities have, by now, learned that identity is an important issue. I’ve certainly been harping on about it for years, and have repeatedly found that it’s a tough nut to crack. People say that they get it, and that they realise that it’s important, but then they’ve repeatedly shown that they didn’t get it.

Now, I don’t know if this is normal behaviour or not, but when people repeatedly don’t get what I’m saying, I find it frustrating. I’ll keep digging around until I find out why they don’t get it, and I’ll keep trying to improve my mental model of the problem until I can find new ways to express it. After all, a clear and understandable expression of the problem is vital if you want to get past the blocks that are in the way.

Every now and then, getting past the blocks makes me realise a gap in my own thinking, and a lot of the time it comes down to language. I don’t mean that I’m writing in english and you’re reading in french (although you might be – I wouldn’t know!), but that the word identity comes with too many meanings. Particularly when you’re a fuzzy, imprecise UX guy talking to rigid, precise developers. Thankfully, having a fair bit of fairly arcane coding in my background (fast fourier transform code and neural networks – particularly Kohonen SOMs) I am often able to speak enough developer to get by.

It was stepping back from working on online communities to work on our product that brought me to something of a realisation about how I’d been communicating something about communities. Or more accurately, how I hadn’t been communicating something.

I’d been banging on and on about how identity was important, meaning one thing. The folks I’d been working with had heard me banging on about identity being important, but hearing something entirely different. Identity meant different things to different people on the team, and that was muddying the waters – I was saying identity was important and that we needed to focus on it more, and they kept going off and focussing on the wrong thing. What they were focussing on was what I’m going to call the system identity, whereas I was talking about what I’m going to call the self identity.

But what’s the difference?

To the developers, the purpose of identity was separation and identification of individuals. It was a means to say “this person in this system is the same as this person in that system”. A way to reliably tell who a person is, and to match up that person in one systerm with themselves in another. It’s how the software tells one user from another and can tell who people are. I’ve taken to calling this one the system identity.

To the social and community folks and the front end users, that’s not what identity means. To those people, “identity” is how each user expresses themselves. It’s a means to say “this is who I am, this is what I do and this is what matters to me”. It’s a way to express what it means to be who you are. I’ve taken to calling this one self identity.

So, using this terminology, you can make it clear what kind of identity you’re referring to.

System Identity is knowing that the UserID 1138 is Jed (and only Jed) and user 1149 is Bob (and only Bob). It’s how the system differentiates you as an individual from other individuals. It’s used by the system itself to differentiate users and associate them with other things.

Self Identity is Bob’s profile letting people know that he can help them file their TPS reports on time and that he likes skiiing. It’s also Joe’s profile letting people know that he likes muffins, playing squash and going out for drinks on friday nights. It’s an expression of what being Jed or Bob actually means.

Both are valid uses of the word identity, and both are extremely relevant in social or community software. You need a strong model for both forms of identity if you want your online community to thrive and be successful. You need to be able to reliably tell users apart behind the scenes, but you also need to allow users to differentiate themselves and present themselves in a manner of their choosing at the frontend.

You must be able to clearly distinguish users at the backend through their system-identity, but you also need to let users distinguish themselves from each other in the frontend through the way they choose to express themselves and present themselves. This latter method of distinction relies on the self-identity. It might be through personalised avatars and signatures, or it might be through and expressive username.

In a real world analogy, the system ID would be the passport or ID card. It’s an official document that states who you are. It’s typically reliable and is useful for proving who you are, but generally says little about you as a person.

In the same real world analogy, the self ID would be your skills, your personality, your fashion sense, your taste, your interests & your hobbies. It says a lot about you as a person, but doesn’t necessarily serve as a unique identifier.

One says “I am unique individual 1138. Nobody else is unique individual 1138. I am only unique individual 1138.”

The other says “I am bob, I like beer and fishing. My tastes are these and you should read what I say because…”

For an online community (or social network) to work, you need to understand both of these and have an appropriate approach to dealing with them. You need to be able to reliably differentiate between individuals, and those individuals need to be able to reliably express why you should care what they say.

Speak Out With Your Geek Out – User Experience Design

Amongst several other things, I’m a user experience (or UX) designer. This can mean a lot of different things to a lot of different people, but to most people in day to day life, it means something along the same lines as “…” or “wurbwurbwurbwurb”. It sounds like some kind of pretentious made up job about “living life to the full!” and “squeezing every drop of experience from every moment of life”, but it’s not. There’s a lot of nonsense out there about the field, particularly because it’s caught a bad case of the buzzwords in recent years, but the actual field itself? Good and solid.

At the lowest level, it’s a job that focusses on the the activity of doing things, and making it so that a user’s (or participant’s) experience of that activity is appropriate instead of shit. Simple as that. I’m not even going to say the job is even to make the experience good or fun, although it is what you’re going to strive for as much as possible. For some tasks, fun may be appropriate. For others (say, a self service online form for handling the mortal remains of your recently departed but beloved pet) is generally not going to be fun whatever you do with it.

Similarly, most of the time, using enterprise software on a day to day basis is not going to be fun because most of the time it’s work. It might have elements of entertainment in it, but it’s still going to be work. My job as a UX guy is to make it not suck, and to make it as easy as possible for you to deliver what you need to deliver inside the ridiculous deadlines that you’ve been set without feeling like you’re stuck in a “choose your own adventure” book and have just turned to “page 46: Your eyes are gouged out with a grapefruit spoon. You die in pain”. If I can slip a few “heh… that’s cool” moments in there as well then we’re golden.

Enterprise Software isn’t really something that many people will say is a passion or something to geek out over, and I’m right there with them. It’s functional, and as a general rule the definition of success is “we made money instead of losing it”. But inside that, you can still geek out. You can still get passionate and enthusiastic about making things smoother for the end users, more slick so that the people you’re selling to can see the appeal without having to get all the details. For people in my line of work, we look at the bottom line, and that’s not how much money one accountant gave to another… that’s the experience of the guy at the end of the chain who actually uses the software to perform a worthwhile task.

Now, I do this as a profession, but it’s actually a passion as well. It’s something I can geek out over. Give me a tough problem and people who know their specialities (and know when they’re lost, when they’re winning and who care about what they do) and I’ll be happier than a pig in a nice clean brick building with a warm straw floor and some apples and cabbage.

I may get stressed. I may get frustrated. I may even get angry. I might make us retread the same problems and conceptual disconnects seven or eight times before throwing my hands in the air and leaving the room before I explode… but when the problem clicks (and it will) then we’ll have really done something. The easy problems get boring pretty quickly. The meaty ones? Those are where the “hell yeah!” moments come from. You can’t geek out over solving an easy problem – it’s just empty.

I geek out over those “hell yeah!” moments. I geek out over user experience design in general, but mostly it’s because of that click when something goes from a muddled mess to the right thing to build next. The moment the lights go on and you can see the solution and the path to it. The best thing? You’re never finished. There’s always more of those moments just a little further along the way. Things can always be a bit better, and it’s geeking out over stuff and getting passionate about things that’ll get you there. Sometimes it’s even getting angry or despondent about them, because those things make you identify the problems and hit them with sticks until they damned well get out of the way.

I’m a UX Design geek. It’s about making hard things easier, complex things simpler, and helping the people who have to do them be the ones who get the job done and go home happy. That’s why I geek out over it.

This is the first of my “Speak Out With Your Geek Out” posts. There will be more.

Barcamp London 8 – Day Two

The Journey In For Day Two

Since I’m worthless without a good night’s sleep, I’d decided to head home overnight and return reasonably refreshed for the second day of this event. This means that much like day one, I had to start the day with a journey in from just outside West London and a fight with the London Underground (which was, as is traditional, mostly closed). Unlike day one, though, I couldn’t just sleep on the train. I had a presentation to prepare for, as I’d decided on a topic to speak about and planned for my first act of the day to be picking a spot in the grid to accomodate my session.

I’m not going to write much about prepping my session (or presenting it) as I’ve already covered it elsewhere. Suffice to say that I created most of it on the train and tube, then finished it off whilst waiting for the first session of the day.

First Session – The Future of Barcamp London

Or “Tapdancing for Beginners” or “Dutch for Beginners”, as it became known to the participants who arrived early enough. This was a session presented by several of the key figures of Barcamp London, most of whom were looking like they could perhaps have done with a little more sleep at some point that week! Organising this kind of thing cannot be easy, so they deserve applause for being able to function at all – especially as they were also active participants in the event as well the the organisers.

The session itself was a plea for more people to get involved in running more barcamp or hackday style events, rather than continually growing a single, already oversubscribed Barcamp London. They also talked a bit about how their contacts and experience can help with that, and about how their resources might be brought to bear. Which I think is an awesome idea. Whilst I love the two large barcamp events, I can tell it’s going to be hugely frustrating when I lose out on the ticket lottery for one of them… if there are more events, then missing them occasionally will be less gutting. More events will mean more people will get a chance to participate, and the barrier to getting started won’t be quite as high.

Second Session – Why Online Social Media Isn’t a New Thing

Presented by Glenn Pegden / Tilt

An interesting session with a few gaps and a bias worn openly on its sleeve, this was a bit of a travelogue through early online communities and communication tools, starting with things like dial up BBSs, heading on through MUDs, MUSHes and talkers to things like Usenet and Prestel – all of which clearly are precursors to current social networks. I mentioned the open bias, though… and bias probably isn’t the right word. The speaker is clearly passionate about the Monochrome BBS, and a large chunk of the talk focussed on how that grew and evolved, and how a lot of current social network features could originally be seen there – and still can as it’s still running and in active use.

I never really got on with old-school BBSs and talkers, although I did dabble a little at times… mostly due to friends and acquaintances who used (or, indeed, use) them. Even with that in mind, I’m always interested to heat people who know a subject and care about it – and that’s what was happening here. Now that I’m more familiar with console / terminal based things than I ever was when they were state-of-the-art, I might be tempted to give Mono a look at some point. Back when this kind of thing was the only option, I was focussed on other things. Non text-based user interfaces were almost the enemy to be defeated, or at least the status quo to be surpassed (with the exception of text adventures, which were mighty). The fact that they’re still around says they’re getting something right, and it’s worth digging in to understand that and learn from it.

One thing that was touched on in the talk (which I think falls under “getting something right”) was the idea that the barrier to entry required by something in a terminal window kept the quality of discussion high. When getting in requires a certain amount of effort, people who make it are a) more likely to make worthwhile contributions and b) more likely to stick around. I’ve often said that community is often as much about exclusion as it is about inclusion, and this is a case in point. It’s a community for people who are savvy enough to want to get in and be able to get in.

Third Session – From Faraday to Fender: The Physics of the Electric Guitar

Presented by Dylan Beattie

I may not be a musician, but I am enthusiastic about music… and guitars feature heavily in a lot of music I like. Adding in the fact that I enjoyed a session from the same speaker last year, I kind of had to go to this one, really… and I’m glad I did. This was a fairly rapid run through of how and why guitars work, covering harmonics, scale lengths, string gauges, tension, the whammy bar and a fair bit more besides.

The whole lot was presented with humour, enthusiasm and an electric guitar, making for an informative and entertaining show overall.

Fourth Session – Levels of Digital Engagement with Customers

Presented by Lloyd Davis

I don’t actually remember much from this session. That’s not because it was a bad session, because it was actually quite interesting, but more because it wasn’t what I was expecting. I was expecting something about growing (or differing) adoption of online tools, but got something about engagement between brand and person. Like I say, interesting, but wasn’t what I expected. I’m also not quite sure what I can really say about it based on my hazy recollections, so I’m going to pretend I said something insightful and move on.

I probably just needed more coffee.

Fifth Session – University: Why did I bother?

This was a discussion session focussed around whether or not people felt university education had been worth it, was currently worth it, or would be worth it in future. There were no particular conclusions drawn, but I felt I had to chip in – I’ve noticed a trend amongst tech geeks to do two things… first, they dismiss any subject other than computer sciences and second, they then say that their computer sciences degree wasn’t worth the time and effort. It shouldn’t be too hard to spot the issue there. Thankfully, in this discussion, that didn’t seem to be the case.

For reference, whilst many folks I know seem to have decided that I’m a computer scientist or somesuch… I did my degree in Industrial Design. It was very, very worthwhile for three main reasons. First, it taught me that I didn’t want to be an industrial designer. Second, it taught me how to think design (some other things helped – more later), which is essential for what I do now. Third, it passed the time until my industry of choice became a viable option. I couldn’t have planned to work on the web before starting my degree – the web was there, but design wasn’t really a word that could be applied to it at that point. I was halfway through my degree when it became a career option.

I’m now going to digress a bit and flesh out that “more later” from above. Thinking design was also helped by two other things in particular: Fencing and Gaming.

Yes, my current physique hides the fact that once upon a time I was a passable fencer – I was actually school champion for two years running, one of which I think I even deserved. One of the things my instructor taught heavily was ODA – Observe, Deduce, Apply. See what people do, deduce how to use that, then apply your deduction. Whilst I don’t fence anymore (alas), I still do a lot of o
bserving and deducing… and when I can, I apply.

As for gaming, well, again, a lot of the kinds of game I do rely on being able to help the players suspend disbelief, move past constraints and percieve what you want them to. Learning to mess with people’s heads in a gaming environment has it’s uses for other fields as well.

But enough of that digression…

Sixth Session: A Rough Intro to User Experience Design

Presented by… wait, that’s me!

Yes, this was my slot. I wanted to present a slightly different view of User Experience design, whilst also explaining what it’s about. So I did. With sketches. I’ve already blogged about the session and how it went.

Lunch and Conversation

I ended up sitting having lunch with a few good folks, some of whom I can identify, some I can’t. I know I talked to @jack_franklin and @kaythaney – if you’re one of the other folks, please prod me on twitter and say hi!. It started as overflow questions from my talk… and rambled around a fair bit, including me pimping Leah Buley’s “UX team of one” talk and the UXLondon conference. I’m pretty sure I extolled the virtues of one other thing as well, but I can’t recall exactly what… I also kind of forgot to actually eat much, which was probably foolish.

The Blur & Journey Home

From here on out, it’s a bit of a blur. I know I went to an interesting talk by @DigitalMaverick on crowdsourcing and the closing session… and that I had a reason for not attending a session between the two, but I don’t recall much about any of those. So I’ll apologise for the disservice to those who ran the sessions I was at, and wind this post up with a mention that my first good, uneventful journey of the weekend was the last one, which got me home intact and without incident. Which was a good thing, since my brain had clearly shut down by that point.

Barcamp London 8 – Day One

What is BarCampLondon?

BarCampLondon is a participatory unconference. It’s generally techie and geek focussed, but the talks can be on any subject at all. The “Unconference” part basically means that there’s no pre-established running order – just slots in which talks and sessions can happen. What happens in them depends on what people decide to talk about and when they decide it. This is the second time I’ve attended a BarCampLondon, and once again I’m going to try to write up what I can remember of it… I took an assortment of notes over the weekend, so I should have at least a few recollections to work with!

Arrival

The TFL website did a bang up job of making sure I was good and prompt. Knowing that half the tube was going to be broken this weekend, I looked to see how long it thought it’d take me to get here… and to see what route it recommended. Of course, I immediately spotted that it was telling me to use the Waterloo and City line before it opened, so I thought “I’ll give myself an extra 20 mins to handle that”. This meant I had to leave the house a bit before 7am. So naturally, I got there way too early. I arrived at the venue at 8:30am – fully an hour before things were due to kick off. They did offer to let me wait indoors, but I decided to go for a walk instead. I don’t get enough exercise as it is, and the weather wasn’t too horrific.

Unfortunately, there’s not much of interest in the gap between Angel and Old Street, so I basically wandered aimlessly for around 30 mins, then returned to the venue to wait inside. I ended up sitting with Jamie Knight (and Lion) and Alison Wheeler, who’d arrived between my first and second arrivals, whilst we waited for the world to be ready for us.

Welcome Session

Next up was the traditional welcome session, where we were told what’s what and informed who was paying for everything. Quite a good round of sponsors – they’re on the BarCampLondon 8 website. They also pointed us at the Lanyrd page for the event, which was handy. The session ended with the advice to get to the grid quickly and start filling it with the first batch of talks…

…which was slightly scuppered by the grid being on a small, crowded landing on the ground floor. The crew weren’t happy about letting too many people near it at once, so we couldn’t all go and add things and decide where we were going. The result was that I got to the grid when there were only two sessions on it. I probably missed a couple of early talks simply because they weren’t up on the grid yet, and I had to move away to let other people in to put them on there. Whilst I generally can’t fault the organisation, I will say that this probably wasn’t the wisest place for the grid – I think it’s more important that people can actually get at it than for it to be central!

First Session – Location Aware?

This was a fairly discussion heavy session, hosted by Alison Wheeler. Discussion sessions are frequently interesting, but are often difficult to write anything about afterwards. Two things that I distinctly recall – location aware services present two different issues, either of which can be problematic for some people:

  1. They tell people where I am, so they can find me when I might not want them to.
  2. They tell people where I’m not, so they can get at my stuff when I’m not there

A further point that was raised as something that makes the previous isses worse – many location aware services don’t give you much (or any) control over who can see your location data. Twitter was held up as an offender on this front as if there’s location data attached to a tweet, there’s no way to let somebody see the tweet without the data, and no way to remove the data without deleting the whole tweet.

In relation to the “letting people know where my location aware device is they can mug me and steal it” issue, one of the audience passed on a comment from an iPhone thief in San Francisco… “If I wanted to steal and iphone in San Francisco, the best way to do it was ask somebody the time. When they took out their iPhone, I’d take it”.

Second Session – Secret Life of Bees

Presented by Kerry Buckley

Earlier on, I described barcamps and being “vaguely techie”. Perhaps “geeky” is a better description, and this session fits that heading very well. It was an introduction to Beekeeping, which was really quite well attended, so it shows that a lot of geeks find it interesting. How it wortks has always been a bit of a mystery to me, so I was quite interested.

Amongst other things, the speaker put paid to the idea that the queen is in some way “in charge” of the hive – it’s blatantly the workers who run the show. They just need an egglaying machine to keep the hive running, so they either find a queen or make one by feeding a larva Royal Jelly. They also feed larvae differently to make drones… who are essentially useless except for being the other thing required to make the queen produce eggs, which they only do once. when eggs aren’t needed, the workers kick the drones out to starve to death, rather than wasting resources to feed them!

To sum up: I learned a few things I didn’t already know, and my vague interest in it as a topic remains.

Third Session – Lifestylelinking Open Source Project

Presented by James Littlejohn

At first, this was one of those “this all sounds very interesting, but I have no clue what you’re on about” sessions… but as it went on I managed to pull the various threads together to get a picture of what it was about. If I’ve got it right, this session was about an open source project called LifestyleLinking, which is a web application supporting automated content discovery based on information gleaned about your personal interests. Essentially, you point it at your blog and some other resources, and it works out the kinds of things you write about, then gathers resources based on that information and reveals them to me in an organised manner.

It all sounded a fair bit more involved than that, and it sounded like it would refine it in a lot more detail than my description suggests – but I’m still not 100% certain of any of that! I suspect I needed to be a bit more awake (or at least caffeinated) to get more from this session. As it is – I’m intrigued and would like to know more…

Fourth Session – High Performance CSS

Presented by Anthony Kennedy

This was an interesting session on optimising your CSS for file size and reduced HTTP requests. I’d have quite liked more details of the subsequent topics that the speaker had (quite reasonably) steered clear of for time, but the stuff that was left in was all good – and presented in a clear and interesting manner.

Fifth Session – Running Meetups using Social Networks

Presented by Nathan O’Hanlon

I was interested in this one as I’ve toyed with putting together a couple of meetups in the past – one gaming related, one tech related. I may still do so in both cases.

Anyway – Nathan has organised quite a few meetups, it seems, starting with pub meets in New Zealand, and lately the London Web Meetup. He gave a whole bunch of advice on how to go about setting them up – starting with being clear about your requirements for the meetup. His requirements included things like being able to network and keep sane as well as things like having an appropriate sized venue with a flat rate rather than a minimum drinks spend.

He also suggested hooking in to a pre-existing community, which is good advice as you can’t force a community int
o existance. That said, you can encourage and develop them – and social networks can provide a means to do that, which is part of why I was interested in this session.

After that, he went on to talk about a few older methods of getting things rolling – such as having a clear agenda, a good URL and a name that’s better than “The [place] web design meetup”. He talked about getting a core team together and discussing what works and what doesn’t, and adapting accordingly. He also mentioned once again that the venue is key – and this is where I find problems with arranging meetups or geek nights around here – I can’t find a venue that I think will work for anything other than a bunch of people in a pub.

Then came the newer methods, which were a bit more twitter focussed – namely asking your speakers (if you have them) to retweet, and when you tweet about the meetup, include speakers’ twitter names – the chances are that they’ll retweet. That way, people who follow your speakers will know about your meetup.

Of course – that’s all for before the meetup itself. What about during the meetup and after it? He suggested starting off a hashtag for the event and announce it at the event, so that coverage of the event can be found afterwards. Likewise, he suggested retweeting some of that coverage from the meetup’s own account – that way you’re publicising the event, the community and the hashtag as well as the original poster.

Sixth Session – Books for Freaks

Presented by Paula Schramm

This was another discussion session, focussed on an assortment of book recommendations. The speaker set the ball rolling by recommending Eat Pray Love by Elizabeth Gilbert, The Dispossessed by Ursula LeGuin and Medea by Christa Wolf.

Palfrey suggested The Star Fraction by Ken Macleod and The Android’s Dream by John Scalzi.

Ryan Alexander suggested Ender’s Game by Orson Scott Card, Blue Champagne by John Varley, Understanding Comics by Scott McCloud (Which I heartily second – I’ve also heard him speak at a UX conference, which was awesome), Born Standing Up by Steve Martin, Wikihistory by Daniel Warzel (aka: “Everybody Kills Hitler Their First TIme Out”), Emergence by Stephen Johnson and The Immortal Class: Bike Messengers and the Cult of Human Power by Travis Culley

Jessica Meats suggested the young adult SF Hunger Games trilogy by Suzanne Collins and took the opportunity to pimp her own first novel, Child of the Hive.

Ian Johnson suggested the Thursday Next series by Jasper Fforde and An Ode Less Travelled by Stephen Fry.

Melinda suggested Feed by Mira Grant (which I also second heartily – Zombie political thriller, what’s not to love?), Old Mans War and Agent to the Stars by John Scalzi (I heartily second the first of those – I’ve not read the second yet).

There were further suggestions, but I didn’t manage to note them down.

I tried to get a couple of recommendations out myself, but generally time was running short and so the same couple of people were rapid-firing the last of theirs and I didn’t get a chance… but if I had, I’d have put up Anathem by Neal Stephenson (which is best summed up by this webcomic) and Accelerando by Charles Stross… the latter of which has a couple of problems but is awesome nonetheless – it’s like future shock in book form.

Seventh Session – How Photographs Tell Stories

Presented by Paul Lowe

I didn’t get any notes on this one, but it was an interesting walk through documentary photography…

Eighth Session – Why I’m Not Using HTML5

Presented by Jamie Knight + Lion, with an interlude from Glyn Wintle

This was an interesting session which I think was derailed a bit by the security aspect added by Glyn Wintle. I was quite interested in the accessibility concerns that Jamie was raising, but they didn’t really get much of a chance to come through…

Ninth Session – What’s Wrong With “It Just Works”

Presented by David E (eastmad) & Abizer

This session seemed a bit like a good idea at first, but seemed to hinge around the idea that everybody should want the same thing and one approach should be sufficient to please everybody… I left partway through.

Tenth Session – Improvised session on how DIY is ruining the world.

Presented by Paula Schramm

This rapidly turned into an economics discussion, and so went over my head entirely. The concept of money and the psuedoscience that’s grown around it bugs me.

End of Day One (for me, anyway)

At this point, I’d pretty much had enough of being sociable. I’d had a rough week, with some pretty significant personal upheavals and my mood was starting to crash. I thought it best to leave for the day before I started getting cranky at people… so I set out for a slightly smoother train journey home and a reasonable night’s sleep.

A Rough Intro to UX Design

Introduction

Over the past weekend, I took part in Barcamp London 8. There will be another blog post about the event in general in the near future, but for the moment I’m going to focus on the session I presented there, which was titled “User Experience Design – A Rough Intro”.

In true barcamp style, the presentation was more than a little “seat of the pants”. I didn’t stay overnight as I really don’t function well without sleep, so I started my second day by leaving the house a little before 8am to begin my journey to the venue. At this point, I had no clue what I was going to present. The previous day, a couple of folks had suggested they might be interested in a talk outlining what User Experience Design actually is – so I thought I’d see what I could come up with for that. So when I got on the train, I pulled out my sketchbook and started to scribble some ideas down.

 

Lo-Fi Presentation

At this point, I’m going to leap ahead a bit and mention a decision that I made later on… namely that I wasn’t going to use my laptop at all in the presentation. I’d started out carrying the laptop around on the first day, and found it to be something of a pain in the arse. It’s not a big, bulky laptop… but you still have to shift it about, power it up, put it into standby and generally fight with it. If you wanted to shake somebody’s hand whilst carrying it and a drink, you had to juggle things or find somewhere to put it down. So I decided on Sunday that I’d only get it out if I needed it. Initially, I thought I’d need it for my presentation… and I had been planning on doing some sketches, taking photos of them and then using those photos in my slides.

But then I remembered four things:

First, I hate making slides.

Second, many of the presentation rooms had “visualisers” – which are like a hi-tech version of the old overhead projectors – they’re basically a webcam that points onto an illuminated plinth so that you can put things on the plinth and have them projected onto a screen. This meant that photographing my sketches and building a presentation around them would basically be a waste of time. So the laptop stayed in my bag the whole day – and all I lost were the updates via twitter and lanyrd.

Third: When you use presentation software, you nearly always have to compromise between what you want and what it’ll let you do. You can spend hours trying to convince powerpoint to do what you want. Generally, you don’t need to spend hours trying to get your hands to do what you want – they get pretty close right away thanks to a handy neural interface.

Fourth: Wordy powerpoint is a barrier to communication. People read the screen instead of listening, and then get bored whilst they wait for the slow, boring talky man at the front to catch up with their reading.

So rather than using my sketchbook to come up with some ideas and doodles to put in my presentation… I decided that the sketches would be the presentation. They would be both my slides and my notes – sketching them was my sole preparation.

Sketch One – What is UX Design?

After a bit of fighting with the visualiser, and trying to get my sketchbook to stay open in the right places (the lo-fi equivalent of the inevitable laptop cable swapping and associated “nothing works like you expected” discoveries), I started off with the following sketch:

Sketch of things people say about UX design

When I had this up on the screen, I tried to make two main points:

First – if you ask anybody who’s not a user experience designer to explain user experience design, you’ll get a different answer.

Second – if you ask anybody who is a user experience designer to explain user experience design, you’ll probably get several different answers.

Whilst I was explaining this, I went through the responses in the sketch… so I’ll do that here too:

“Isn’t it just part of design?”

Yes. So’s pretty much everything else. Design is a word with a very broad scope. As an example, it can cover anything from designing fancy gilded patterns on the cover of a wedding photo album, through planning the underlying architecture of a piece of software to deciding how a piece of industrial machinery should be constructed to make the most efficient use of materials.

“Useless. A good web designer does it already”

A good web designer should indeed be doing it already, but it’s not necessarily their main focus, and as such they may not be able to give it the time it deserves. If they can, then that’s awesome and I don’t think you’ll see any good user experience designers complaining!

“Isn’t it just part of product management?”

As with web designers, a good product manager is indeed probably doing a certain amount of user experience design… but again, it’s not necessarily their main focus. They’ll probably be looking at what users want and need, but may well not have the time to get very heavily engaged in how those needs are actually implemented.

“Wishy Washy Nonsense!”

Sometimes it is a bit wishy washy and difficult to pin down. Other times, it’s one of the few forms of design that you can test and apply metrics to. It gets “wishy washy” around the points where you have to start doing something before you can collect data about it…

“Another name for UI design?”

This is another place where there’s a strong overlap – and if you’re working on software or a web application, it’s even stronger. But once again, there’s a slightly different focus – and one I’ll address in a bit more detail later.

“Wireframes?”

It’s quite easy to mistake the outcome of a process for the process itself, and this is a common one. Wireframes are a tool that user experience designers can use to convey ideas to others – but they’re usually a tool that comes quite late in the process. A lot of the time, they’re the first contact developers have with the user experience design process… which is usually a problem, rather than a desired situation for the designer.

“An excuse to pad a CV?”

Alas, much like web design was in the late nineties and early 2000’s, user experience design has become a buzzword. The same way that anybody could say they were a web designer because MS Word had a “save as HTML” button, anybody can say they’re a user experience designer because they know a couple of buzzwords. So the field has a little bit of an image problem at the moment…

What next?

So… having made it clear that if you ask 5 user experience designers what UX design is, you’ll get at least ten answers… I embarked on explaining what user experience design is. You should, by now, understand that a lot of user experience designers will disagree with me. You should also understand that I think that’s just fine.

Sketch Two – Design is a Spectrum

Design is a spectrum - UX Design is a point on that spectrum

There a whole bunch of different forms of design, and they can all fit onto a huge spectrum. That spectrum also includes things that people would argue aren’t design at a
ll, but I’d say are at the very least related fields. The small and non-exhaustive (and not really ordered) list that I came up with for this sketch is as follows:

  • Content authoring
  • User research
  • Ergonomics & athropometrics
  • Cognitive ergonomics
  • Product design
  • Interaction design
  • Graphic design
  • UI design
  • “traditional” web design (which I rambled around a bit, but by which I essentially mean “web design where the designer doesn’t do much UX design).
  • Front end development

This lead me directly on to the next sketch…

Sketch Three – Designers, being fickle beasts, rarely tick just one box!

Circle containing many different design discipines I identify with.

For the next bit, I used myself as an example to show that anybody who considers themselves in any way a designer almost certainly covers more that one point on the design spectrum.

Some of the areas I associated with myself for this sketch were as follows:

  • Industrial design – I’m an industrial designer by training.
  • “Traditional” web design – I did a lot of this in the mid 90s.
  • Interaction design – again, I did a fair bit of this in the mid 90s, but as a distinct thing from web design – they didn’t come together for me until the late 90s/early 2000s.
  • Product design – tied quite heavily to industrial design. It was the “course next door” whilst I did my degree and we shared a lot of modules!
  • Lighting design – I’m an amateur theatre lighting designer, I run the lighting for a local comedy club and I’ve done lighting for several small gigs and events.
  • Theatrical production design – I’ve done a reasonable amount of set and prop design and construction.
  • Interactive fiction design – See many of the other posts on this blog and you’ll get an idea of what I mean!
  • Environment design – Making a physical space convey a mood. This ties in with the theatrical stuff and the interactive fiction stuff.
  • Process design – difficult to quickly pin down – basically, planning and designing ways of doing things.
  • Service design – planning how people will perceive and interact with a service you provide, understanding contact points and how things need to happen between them, etc…
  • Front-end engineering – making things actually work effectively in a user interface, web page, etc…
  • Hardware hacking – I’m an avid (if not very experienced) arduino tinkerer. I’ve also taught people to control custom hardware with software before, as well as teaching them to solder.

The point I was making is that whilst I’m a user experience designer, I also do a whole bunch of other forms of design. I’m far from alone in that – in fact, it’s my belief that anybody who says they’re a designer in just one discipline is probably misguided.

In essence, user experience designers don’t only do user experience design, and people who are not user experience designers may well still do user experience design. It comes down to where you specialise and what you self-identify as, rather than what you actually do. You might not need a user experience designer for user experience to be done… but if it’s not being done, or not being done enough, then a user experience designer means you’re getting a specialist who’ll make sure it gets the attention it needs.

Sketch 4 – Where Do They Focus?

UX design focus on area between user's life and UI, UI design focus on area between user and product backend.

Earlier I mentioned that I’d cover the often misunderstood relationship between UI design and UX design in greater detail… well here it is.

This sketch is intended to show where the two overlap and where they don’t. It comes after the previous sketch because I wanted it kept clear that we’re talking about the roles… not the people who fill them.

The idea is that there are several areas to be focussed on, which are (from left to right):

  • The user’s life, including the following parallel areas:
    • Other things in their life that they want or need to do
    • Other things that they have to spend time on
    • Other people they have to work with
  • The users, of which there are many different types (although contrary to the sketch, it is unlikely that some of them will be small dogs or will have two heads).
  • The users’ interaction with the product (or thing you are designing)
  • The product (or thing you are designing) which breaks down into the following (again, from left to right):
    • User interface
    • Logic
    • Backend (Model, database, etc…)

The Focus of UI design

User interface design focusses most heavily on the areas between the product backend and the user. UI design’s main areas of concern will generally be between the user and the user interface, but it will often need to be aware of and informed by what is going on behind the scenes.

The Focus of UX design

User experience design focusses most heavily on the areas between the product UI and the rest of the user’s life. UX design’s main areas of concern will generally on how the user interface can make the user’s life better or easier, and so it will need to be aware of an informed by the other things going on in their lives.

How do they relate?

As you can probably guess, these two overlap a lot. User experience designers are likely to also do a fair bit of user interface design, and user interface designers are likely to also do a fair bit of user experience design. That doesn’t mean the two fields are identical, just that they overlap – it’s difficult to be good at one without being at least competent at the other. Hence the confusion.

Sketch Five – UX Tools

A collection of people based and diagram based UX tools

The main reason to put this slide up wasn’t so that I could run through a selection of tools and how to use them (although I did do that), but was instead so I could say clearly that these are all tools, not the end result. Too many people seem to think that because they’ve made some personas and produced some wireframes, they’ve finished doing user experience design. Instead, what they’ve done is produce some tools to convey ideas. If those ideas don’t get followed up on, iterated and carried through effectively to the final product, then what you’ve actually done is waste some effort. The real deliverable for a user experience designer isn’t some diagrams or a report – it’s users having a good and appropriate experience with the product. Tools alone, no matter how useful, won’t achieve that – although they do make it a lot easier to get there when used effectively.

The tools I mentioned were as follows:

  • “People based” tools
    • Personas & Archetypes – These are detailed descriptions of different users you may be designing for. They’re very useful when dealing with product manag
      ers, sales, marketing and senior staff… but often too high level for developers to really sink their teeth into – they have to wade through a lot of detail that’s not immediately relevant before they find the gems that are.
    • Pragmatic Personas – I use these as a tool to bridge from the rich, detailed and high level personas (and any other info we have on users) to user stories and test cases that developers can work with. They can be much more focussed on work that’s ongoing, and provide a link between who a user is, what they need, and what the implementation implications are.
    • User interviews – How else can you get to know your users? Actually, there are other ways, but they’re always at at least one remove – using analytics, or discussions with support or sales. None are as good as actually talking to users, provided you’re aware that the user you’re talking to is a single example and may not be representative of all of them.
    • User testing & analytics – if you have something, and you want to make that something better, running it by real users and seeing how they do is a good idea.
  • Box, Arrow and Squiggle based tools
    • Card sorting – scribbling things on cards or post-it notes, then grouping them based on either predefined or emergent criteria. Very handy tool for producing other tools.
    • Information Architecture – A plan for how content or components fit together. If you’re not careful, this can turn into a rigid sitemap or heirarchy rather than a flexible plan or scheme which will allow for future growth to fit in, resulting in that growth being bolted on to the side or crammed in where it doesn’t really fit.
    • User flows – these are a staple of interaction design, detailing the steps a user should go through to achieve a goal.
    • Concept models – sometimes you need to explain an idea in some detail, and you need other people working on your project to really be able to understand that idea so they can keep calling back to it. Concept models can help with that. (example 1, example 2)
    • More sketches than are probably healthy – if you think of something, sketch it. Seriously. Then you can expose the inner workings of your brain to other people without the need for surgery.

Sketch Six – UX Culture

Various people in an organisation, and the kinds of conversations they might have with a UX designer

The most useful thing for any UX designer is to not be the only person involved in and responsible for the user experience. They might be the only person who focusses on it entirely, but they need a lot of other people to be thinking about it as well. They need to be bouncing their ideas and thoughts off everyone else in an organisation, getting feedback from them. Even more importantly, they need to be making sure that people from different parts of the organisation talk to each other about the user experience.

Whilst the ultimate ideal of user experience design is to have the user experience be the sole concern, reality does have this habit of intruding. Release dates, budgets, implementation concerns, sales and marketing issues,etc… do all exist, and when it comes down to it they are often important – without them the product you’re making might never see market. If users never experience your product, you can’t really call it a successful user experience.

The best situation to be in is one where everyone working on the project is able to raise concerns about the user experience, or the work that maintaining it will entail. If a developer says that what the UX designer is asking for is too expensive, there needs to be a conversation between the product manager, the development team and the user experience person to determine if a compromise can be reached, or if a partial implementation is good enough in this release, with an improved implementation in the next release.

What is most important is that everyone is able to understand how decisions can affect the user experience, and how user experience decisions can affect everything else. With a dedicated user experience designer, you have somebody who’s job it is to make sure those implications are clear and understood, and to facilitate discussions around them so that the people who make the final call can do so in an informed manner.

LARP and the User Experience – Part 3

Introduction

In the previous post I discussed how the UX techniques of User Archetypes and Personas could be applied to LARPs. This time I’m going to follow on with a similar approach – showing how User Journeys can be applied to LARP. Again, these will be of more benefit for larger games, although smaller games might also benefit from thinking about them.

User Journeys

Picking Goals

User Journeys are a technique used to determine what a user must go through to reach their desired goal.

In general, they also keep in mind the business goals of the product being designed – if the user goals and business goals don’t meet up, then the business isn’t likely to do well. To put it simply: If the business doesn’t help the user meet their goals then they won’t get or keep the users, and if the users don’t act in a way that gives the business what it needs to succeed… then it won’t.

When creating user journeys, you usually do so with a particular user goal and a matching particular business goal in mind. This pairing of business goals and user goals is a way of ensuring that the business benefits from the customer having a good experience, rather than the two being at cross purposes.

Working through an example of this in a LARP context, we’ll work through an example with the following goals:

  • User goal – “I want to enjoy my first game”
  • Business goal – “We want to increase our regular player base”

The user goal implies that a player wants to get to their first game and have a good time. The business goal implies that the people running the game want the player to get to their first game and to keep coming back for more. These two goals work together, and having both of them listed keeps it clear why the business should be interested in the user’s goal.

Who’s on the Journey

In the previous post I discussed archetypes and personas – these are ideally suited to the process of putting together a user journey. In this instance, the obvious persona to pick up on from the last post is Fi the First Time LARPer, although she’s not the only persona that applies here. Any of the player archetypes I listed in that same post could be relevant, and should have personas created for them an a user journey created for this pair of goals. The other personas would be relevant because whilst they may be long established LARPers, they may not have played this LARP before, and so can be “first timers” in that sense.

That said, for this example, we will focus on Fi for now.

What needs to happen for Fi to achieve her goal?

Several things need to happen for Fi to enjoy her first game – some of which she knows about already, and some of which she doesn’t. I’ll try to list a few of them below. I’m assuming that this is for a larger weekend event that involves travelling and camping overnight. Below is a non-exhaustive list of things that need to happen (or not happen), placed in something near to the order in which the needs should be fulfilled. These needs may not apply to all games, and the order may differ widely, but this seems to make a kind of sense.

  1. She needs to know about the game (we already know from her persona that she”s heard about it via word of mouth from friends)
  2. She needs to know what kind of game to expect
  3. She needs to book a place at the game & pay for it
  4. She needs to generate a character
  5. She needs to get to the game and onto the site
  6. She needs to get to her campsite and get her tent set up
  7. She needs to get into costume
  8. She needs to be able to buy things she needs that she didn’t think to bring
  9. She needs to sign in and collect any special ability related paperwork or props
  10. She needs to start playing
  11. She must get involved in the game
  12. She mustn’t get sidelined by more experienced players
  13. She mustn’t get lost in the rules
  14. She must be able to find her way around the site
  15. She mustn’t be horrified by the on-site hygeine
  16. She needs to eat and drink enough
  17. She must get the amount of sleep she wants
  18. She must always be able to find something to do
  19. If she is injured, she must get prompt, appropriate care
  20. If she decides to return, she’d like to be able to buy her own equipment and costume

That’s far from everything, but it’s enough to be getting on with. Now that we have these, we want to tell a story of how we’d ideally like Fi’s event to go. There are a couple of ways that I’ve used in the past to do this, one of which is telling the ideal story and comparing it to reality, the other is to tell the woeful story of the worst experience, and then identify the places in that story where it all goes wrong and how to prevent them.

In either case, working through the story can be done by just one person, but you’ll get far better results if you tackle it with at least two. With two people, you can make use of a tabletop roleplaying approach. One of you picks up Fi’s persona as if it was a character sheet, background and brief, the other takes on the role of GM, providing responses to the player’s actions and placing appropriate barriers or constraints in her way to make sure things are realistic. The GM also needs to ensure that the player doesn’t “cheat” by using knowledge that Fi wouldn’t have – using out-of-character knowlegde when taking a persona through a user journey is frowned upon just as much in user experience design as it is in gaming!

Finding Fi’s Ideal Story

The ideal story is trickier than it sounds, as you have to make sure all the bases are covered, and that the protagonist never achieves things by magic. In this approach, the GM needs to be firm but fair – they need to make sure that things stay realistic and that people don’t skip over the dull bits – if there are dull bits, you need to know and understand them so that you can stop them from being dull.

Using Fi as an example, in the ideal story she needs to achieve all of the goals listed above. Looking at goal 6 from the list:

  • She needs to get to her campsite and get her tent set up

This seems straightforward at a glance, but the last goal she achieved before that (goal 5) was just to get on to the site. There’s a fair few gaps that need to be filled in between achieving that goal and having her tent set up…

  • How does the friend who drove her to the event know where to park?
  • How does she know where she’s camping?
  • How does she know how to get from the carpark to the area where she needs to camp?
  • How does she get her stuff from the carpark to her camping area?
  • Once she’s at her camping area, how does she know where she should pitch her tent?

Filling the Gaps

All of the questions above need to be answered before she can move from the state where she’s arrived at the site to the state where she’s pitched her tent. There’s undoubtedly more such questions, but these are enough to use as an example. There needs to be a good, reliable and resilient system in place to ensure that all of these questions are answered. The questions about where things are and how to get between them can be answered on a basic by good maps and signage, but human beings on hand to direct people… particularly as the answers may depend on knowledge that Fi doesn’t have yet.

As an example, at larger fest
events there are often multiple camping areas on a huge site, with different player groups camping in different places.

A map showing which groups are camped where doesn’t help if you don’t yet know which group you’re with. The chances are that Fi is camping with her friends and that they will know which group she’s with, so they would be able to fill in that blank. If we diverge slightly from the persona, though, and treat her on her own, she may not now what group she should be with. In that instance, she’d be lost without being able to find out which group she should be with. A marshall would be able to help her check her character details and work something out, further improving her experience. Likewise, if she didn’t have her character details to hand (if they were packed in a rucksack, for example) then a marshall with a radio would be able to call into the operations desk and ask them to look up her details.

This leaves us with four ways to help bridge those geographical gaps:

  • Map – Helpful if you know what your aiming for, but requires you to have the map with you at the time! Can show anything of significance
  • Signposts – Helpful if you know what you’re aiming for, does not require you to be carrying anything. Can’t signpost everything.
  • Marshall – An obvious member of staff who can help direct people to where they need to be. If the player doesn’t know where they need to be, they can help work it out. Obviously, this only works if the player can find the marshall.
  • Marshall + Radio – As above, but backed up by extra information and resources from the operations desk / game organisers.

For the logistical question of getting her stuff to the campsite, Fi doesn’t have much stuff, so she can carry it. However, what if she’d twisted her ankle on a dodgy kerb at a service station on the way, and so didn’t want to carry her bags and a tent? At smaller events she can just ask somebody or get her friends to help… but at larger events it’s not uncommon to have some kind of transport assistance on hand – a quad bike and trailer service (or at least handcarts) are often available for a small fee, although you frequently have to queue for them.

  • Handcart / Other Transport – As long as you know it’s there, luggage transport can be a benefit for people who can’t carry their belongings to camp, if they’re prepared to wait a bit longer and know were to queue.

Then the final logistical gap to be filled is how to work out where to pitch your tent. Again, there are several ways to solve this, some of which are listed below:

  • Another Marshall – Who can explain the layout of the camping area and direct you to appropriate pitches
  • Campside Map – More detailed than the main map, a campsite map on a noticeboard near the area entrace could show the rough layout
  • Marked areas – Marking areas to be kept clear or areas specifically for pitching tents will help show people where they should or should not go

This all covers how Fi can get from goal 5 to goal 6.

An Excerpt from Fi’s Ideal Story

Given the above, part of Fi’s ideal story could be as follows, with the things responsible for filling gaps marked in bold:

“When we arrived on site, the marshall (with radio) at the main gate (Gate A) checked our tickets and marked us off on a list. He said he could check us off with some ID instead of the tickets if our tickets were packed in the boot. He handed each of us a booklet with a map and a few extra guidelines about the site. He also pointed the carpark out to us, and the entrance gate (Gate B) that we’d need to go through when we’d parked. He also said that if we needed help with luggage, we could queue at the sign by that gate for assistance from a guy with a quad-bike and trailer. We weren’t going to need it, but it was good to know it was an option, in case I need it next time I come.”

“When we’d parked, we got our stuff out of the car and headed for the gate. The marshall (with radio) at Gate B asked us if we knew where we were going… when we told him we were camping with the Weasels faction he quickly pointed the route out to us, and mentioned that it was signposted, so we should be fine. He also made a joke about hoping we had a good night’s stealing and backstabbing… to which my friends jokingly replied that honest Weasels would have no part in such things. It wasn’t much, but it helped put me at ease.”

“It didn’t take long to follow the signs to the camping area, and when we got there, we found a map on a board just inside the entrance. It showed us that the area nearest the camp entrance was an “IC” area, which apprently means that any tents within it are In-Character, and that we should only camp there if we’re comfortable with that and can make our tent look like it’s in keeping with the setting. We only have a modern dome tent, and this is a fantasy setting, so that wasn’t for us. Further back in the camp is Out-of-Character, so anybody can camp there, and further back, the other side of a clump of trees was a small quiet area for people with children or who were likely to want an early night. The map also showed where we needed to keep access routes clear, and told us they’d be marked with rope fences. Whilst we were looking at the map, another marshall came up and asked if we needed anything – we didn’t, so we went and pitched our tent in the Out-of-Character area.”

This covers from Fi’s arrival on site to having her tend set up – which is often an area of planning that’s forgotten about as effort tends to be focussed on the game itself.

Comparing to Reality

The next step here would be to see how much the reality diverges from this… At a large fest event, if there is no indication of what somebody arriving on site should do next, newcomers are going to get a confusing and disconcercerting first experience of the event. This could put them on the wrong foot and spoil things for them – being in a new environment and having no idea what you’re supposed to be doing is never a good place to start.

The list of things that fill gaps up above (the things in bold in the story) are all things placed into the environment by the organisers, and it could be considered that they are all affordances, suggesting forms of interaction to the players, whilst simultaneously suggesting what form that interaction will take and what the result will be:

  • Maps – A map invites the player to view the map, which affords geographical knowledge
  • Signposts – A sign post invites player to follow the sign’s direction, which affords a route to the indicated destination
  • Marshall– The presence of a clearly identifiable marshall invites player to ask questions or seek assistance, at which point the marshall affords personalised knowledge pertinent to the question
    • Radio – The radio is an affordance for the marshall – it invites the Marshall to communicate with operations, affording deeper knowledge about the player or situation
  • Handcart / Quad-Bike & Trailer – Invites players to place baggage in cart/trailer, affording painless transport of luggage to camping area
  • Marked Camping Area– Invites players to camp within the area, affords knowledge about permitted camping areas
    • Rope Fences – The rope fences are at once an affordance and a constraint – In this instance, they’re more of a constraint, as they mark areas to avoid.

On
ce you’ve got these worked out, you can see what you’re missing, what the problems are with providing them, and think of ways around those problems.

For example, maps are easy enough to make, but you need to be able to produce enough of them… which means either knowing your numbers, or having the means to produce them on site. If you can’t do that, then having master maps with “you are here” markers at key locations could be an acceptable compromise. If you have no maps at all, then you will have to accept that wherever one of your user journeys (not just Fi’s journey) relies on a map, that part of their experience will not meet expectations. You’ll either have to accept that shortfall or find another way to make that experience work.

Signposts must be planned for and created ahead of time, but you only need to put them on junctions of major paths around the site, so not that many are needed. You also need to be able to securely mount them in some way, which may not be possible in some locations, or the signs may be vandalised or stolen. If, for some reason, you can’t use signs, you’ll need to find other ways to replace them or remove the need for them in each user journey.

Marshalls require human beings to stand around waiting for people to need assistance, and it’s not always the best job in the world. They’re also usually volunteers, and you can rarely get enough of those. If you don’t have enough people, could you make do with less, with some kind of schedule to make sure that one of them visits each location where they are needed every few minutes? Or is there a way you could recruit and train more – perhaps a way to reward them for their assistance? Radios have an associated cost and as such it’s unlikely that every marshall will have one – you need to find a way to spread the benefits of those radios around to make sure that no marshall is left unable to get assistance. Likewise, marshalls need breaks from time to time, and need something to do when nobody needs help – these are things that you need to consider… but the user experience of game crew is something I plan to cover in a future post.

Luggage transport assistance – whilst it’s not uncommon at really large events, it’s virtually unheard of at smaller games. If they have it at all, it’s usually on an ad-hoc basis, asking for volunteers to help – and those volunteers may resent it if the game doesn’t benefit in some way from their work. If assistance isn’t provided, it’s probably worth making sure people know how far they’ll need to carry stuff, and that they can’t drive right up to their tent… and that if they have specific requirements, to get in touch. That way you discourage people from bringing unncessary luggage that they’re not prepared to carry for themselves, whilst letting people with a valid need for assistance know they can get it by asking in advance.

Fi’s Tale of Woe and Despair

This approach can sometimes be bleak, or sometimes hilarious… it all depends if it descends into farce or into tragedy – and you don’t always know which it will be when you start. In the previous approach, the GM was firm but fair – striving to keep realism whilst letting the player progress. In this approach, the GM is a dick. Their aim is to make as much go wrong for the persona in question as possible. Everything that could go wrong for the persona should go wrong.

Sometimes, the persona won’t even survive the story, and sometimes they’ll effectively write themselves out of it by severing their involvement with their experience. When that occurs, you can identify what lead to that departure, and what the minimum changes would be to keep them in the story instead. If the “Fi” Persona is being put through the “first game” scenario above, failing to achieve the first five goals would result in her never arriving at the event, so in this instance we work out what the worst experience would be that still resulted in Fi reaching the site, and pick up from there.

As a result, we sum up the situation at the point that

“Fi the First Time LARPer’s friends have talked her into attending a game. They’ve managed to sell her on it by saying how much fun it is, but they’ve not really given her much detail about what folks actually do when they’re there. They’ve just said ‘you’ll pick it up’ and left it at that. After a lot of hassle, she eventually managed to book a spot and pay for it, which didn’t fill her with confidence about the event… but she’s paid now, so can’t afford not to go. Her friends wrote some skills on a bit of paper and told her that’s what she should play. She doesn’t really know what much of it means as the rulebook may as well have been written in martian. She arranged to get a lift with Bob the Bastard – a friend of a friend who she finds a bit creepy. He kept touching her knee with every gear change on the drive up, and they ended up having a blazing row about half an hour ago – and have driven in stony, awkward silence since. They have just, at long last, arrived at the main gate to the site – several hours late and in the middle of an epic thunderstorm.”

Having set the scene, we can now continue with Fi’s horrific first LARP experience.

“In the dark and the rain, Bob couldn’t really see where he was driving, and the ground was just slippery mud anyway… and he couldn’t actually get to the carpark. He ended up driving into a ditch, leaving the car halway onto it’s side, with Fi’s door against the bank. She had to clamber over the gearstick and the driver’s seat to get out, and twisted her ankle quite badly in the process. Whilst she was climbing out, Bob was getting stuff out of the boot. He was carrying his stuff, but anything of hers, he was just dumping on the wet, muddy ground. When she’d eventually got out of the car and onto her feet, Bob was already marching off in an angry huff, locking the car remotely as he went – leaving her in tears by her wet belongings”

“Fi grabbed what she could of her stuff, but with her twisted ankle she really couldn’t carry all of it, so had to leave some of it. Some of it had already been blown down the track towards the carpark by the howling gale anyway. She tried to follow after Bob, but he didn’t wait for her, and the rain and the dark meant that he was soon out of sight. She tried to find somebody to help her out, but couldn’t see anybody around, so she kept on hobbling through the rain in the same direction until she eventually found some tents.”

“She didn’t know where she was supposed to pitch her tent, but she could see some people around a fire under a canopy further into the campsite, near some fancy looking tents. Figuring they must know something, she headed their way to ask for help, only to be told ‘Can’t you see we’re in character? Fuck off!’. Having run out of tears and feeling alone and unwelcome, Fi went back to an empty patch amongst the tents. She figured that she’d be able to put her tent there now and move it in the morning if she needed to. Of course, putting the tent up in the wind and the rain isn’t easy, and it’s worse with a twisted ankle. Fi eventually managed to get it close to erected, but she was pretty sure it wasn’t up properly – it kept flapping about in the wind and didn’t look very sturdy. It was also soaking wet, both inside and out. Nevertheless, it was up, and she just wanted to go to bed and for the day to be over, so she went inside with what was left of her stuff.”

“Alas, it turned out that it was her sleeping mat that she’d seen blowing away down the road, and her sleeping bag was soaked through and unusable. When she found her phone, she found she had no battery charge left. In the cold and the wet, she changed into some of the dryest clothes from her bag and wrapped herself in the rest before settling down to cry herself to sleep.”

“It was a broken nigh
t’s sleep, being periodically woken by the cold, the tent flapping about in the wind or just by noise from outside. Close after dawn, Fi was woken by somebody shaking her tent vigorously. She felt drowsy and confused, and couldn’t stop shivering, but she got out of her tent to talk to him. There was a guy standing out there with beercan in his hand telling her she couldn’t camp here, and that she had to move her tent as it was blocking a path. She tried to ask him where she should go to, but he just told her (in a drunken slur) to go and ask at ‘Ops’, whatever that was. She asked him where that was, and he got angry and just started unpegging her tent and shoving it with his feet – she tried to stop him, but he was drunk and belligerent and wouldn’t stop until it was clear of what she could now see was a poorly marked path between the tents. “

“When he’d gone away, she set about picking up the remains of her tent and her belongings. By this point she was just too miserable to want to even talk to anybody else, so she hobbled off with her belonging cradled in her arms, and tried to set up her now broken tent away from everybody. It didn’t go up properly, but it was enough that she could climb into it and lie down again, so that’s just what she did, to shiver the day away.”

“Eventually the rest of her friends went looking for her. The search party found her a day later, starving and suffering from severe hypothermia in the remains of her tent. She was in hospital for some time after that, and hasn’t spoken to some of her friends since. She’ll never LARP again.”

It’s a bit over the top, but it shows how easily a few setbacks can snowball into the worst day ever. It also gives an idea of what the effects of a bad experience can be, and what can contribute to making things worse. It won’t be an exhaustive list, but it will show you where you need to pay particularly close attention, and where you might want to have measures in place to try to salvage an experience.

In this instance, Fi failed at goal number 6. She got her tent pitched, but never managed to get it placed appropriately and never proceeded beyond that point.

Where did it go wrong?

Where didn’t it go wrong. However, there are a few key issues that kept coming up, most of which were aggravated by further issues.

  • Poor provision for bad weather. The thoroughfares of the site were not safe to traverse in poor weather, and there was nothing around the try to rectify this or provide alternative routes. This lead to Fi injuring herself upon arrival at the site.
  • No visible staff. The fact that Fi couldn’t identify the staff meant that she couldn’t ask them for assistance
  • Arsehole players. This isn’t something that game organisers can easily fix, but they can certainly work to create a more welcoming environment, or to reward or recognise people who take a bit of time to make the game better for others.
  • Isolation. Fi knew several people on site, but had no means to find them. The one person she did know abandonned her with no information about what she needed to do. After a few interactions with other people, she further isolated herself to avoid any further interactions.
  • Lack of information about where to camp. Fi ended up in a different camping area to her friends, and camped in a poorly marked thoroughfare – both purely due to lack of indication of where she should or should not camp.
  • Illness & Injury. Fi was injured early on, and no staff or other players spotted it or helped her in any way.

What could be done about any of that?

The biggest part of this exercise is to try to find ways around those key issues. It’s not always going to be easy to do so, but it’s important to work towards fixing them. Some examples would be as follows:

  • Ensure that there are game staff available, and that they are visible
    • Particularly ensure that the gate is always either manned, or that there is information there on how to find staff – if new arrivals can’t find staff they
  • Reward or recognise players who give some of their game to help newcomers
  • Ensure that camping areas are clearly identified
  • Educate staff (and possibly players) in identifying people who are in distress and providing at least basic assistance

Which of these approaches should I use?

Both have their advantages and drawbacks – the first gives you and idea of what the steps are along the way, and an idea of what can help you make those steps smooth, but it doesn’t really give a good picture of what happens when things fall down. The second gives an idea of what can occur with a specific set of issues, but doesn’t cover all potential issues – just the ones you think of at the time, which is never all of them.

If you’re looking to design the best experience, the first technique is good. If you’re trying to identify which problems are worst, then following up with the second can be highly beneficial.

In either case, you need to make sure that you work through the journey with multiple personas – not just the one. This could be done either as individual efforts, or with an “adventuring party” approach, with a group of different personas. This latter approach can also help you identify where different personas may be expected to support or hinder each other.

Did you notice…?

Neither of the user journeys above ever touched on the game itself. Both stopped before Fi ever got into character and timed-in at a game. That’s a different topic, and is likely to be the next topic in this series of posts – along with using User Flow Maps to map out less linear courses of events.

Feedback?

Any feedback, observations or ideas? Feel free to get in touch and let me know. Discussion of the topics I raise helps a lot when it comes to writing the next article!

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!

Older posts Newer posts

© 2018 Eggbox

Theme by Anders NorenUp ↑