This is a recording of a talk I did at SGC this October.

The audience were mostly students and developers just starting out, so that’s the level I put it on. In order to make this more accessible, I’ve also written a blog post accompanying the talk with some images to illustrate. I hope you’ll enjoy it. Please leave any questions you might have in the comments¹.

What Is This Presentation About?

The presentation touches on UX workflows that I’ve used in most companies I’ve worked for. In some cases, these workflows are unique to me and my way of working. I have a penchant for documentation that other designers may not have, for instance. On the whole, though, this is what UX designers do.

What does it contain?

1. A brief introduction to who I am and what I have done previously.
2. What is UX in games?
3. How does things work in games – we usually start with a feature or the player journey when we design.
4. How do I as a UX designer understand the intent and the problem we’re trying to solve?
5. What does the design phase look like? What tools do I use to communicate?
6. What do I deliver to the team? Wireframes…
7. Prototypes if needed. And of course documentation of the designs.
8. Testing of wireframes and prototypes and implemented features.
9. Iterating on the game based on data and user experience testing.
10. Usually I also finish up with questions around the presentation, but since this is a blog post, post them in the comments.

Who am I?

I have been in games since 2001, I was hired January 1st by Picofun. Unofficially, though, I started in 2000 by writing my thesis at Picofun. It was called “User Interfaces for Role-Playing on a Mobile Platform”. It was about 140 pages and nobody at the institution got it.

I went on to get a job as a game designer and somewhat of a producer at Picofun and we made VERY limited mobile games until the studio was bought by Aspiro who closed the office.

After that I went on to UDS to work on the platform game The Kore Gang, originally developed for the Xbox. At UDS I was a level designer and made some of the outdoor levels but I was also handed the scripting of indoor levels. It was a fun time, I learned a lot, in particular about level design. The company went bankrupt and the game wasn’t published until 10 or 11 years later when it was resurrected, this time for the Wii. Some of my levels are still in there. Fun times.

I went to Finland for two years and worked on Habbo Islands, a game produced in collaboration between Sulake (who I worked for) and Nokia as the publisher. Habbo Islands was an extension of the Habbo Hotel IP, but it was never published. We did finish it though.

After Sulake I went back to Sweden and worked at Terraplay for a little while as a content manager. That wasn’t really my jam, so I applied to Avalanche Studios as a game designer. I got the job, worked as a game designer for a year or so on a Disney project that got cancelled. I went on to be a World Designer for Just Cause 2 where I spent a year or so placing rice pickers, civilian villages and military bases around the world together with my team. I also picked names from a long list of village and military names and named every installation in the world. There were many.

Avalanche had to let about half the studio go when the recession hit in 2008 – 2010, and I was one of the people let go. I did find another job pretty fast after that. I got a job as a one woman design team at Movinto Fun working with the Oriboo. I did pretty much everything that had to do with design on that team, and for that little console. Movinto Fun was funded by venture capital and eventually the money ran out.

I had to leave, but I was snapped up by Avalanche Studios again, this time as a producer on the game Mad Max. I did what most producers do, I worked with roadmaps, long term planning and day to day administration of the project. We used scrum to manage our project and I spent some time presenting the process to the team as well. After a while we realised that Mad Max didn’t have a great user experience and so I applied for a job posting as a UX designer. I got it and worked for the rest of the development in that capacity. In 2015 when the game was published, I left Avalanche Studios.

I was contacted by BioWare, who needed a UX designer for their upcoming game Anthem. I interviewed and got the job and moved to Canada to work as a senior UX designer on Anthem. I learned a lot on that project. After Anthem went live, I left the project and went on to the upcoming Dragon Age: Dreadwolf where I worked as a lead UX designer for about two years. Depending on which admin tool you looked at at EA, I was either a Lead UX Designer, a Principal UX Designer or a Senior UX Designer. From the role I performed I was more of a lead.

The pandemic hit and for a bunch of different reasons I decided to go back to Sweden. I got a job at Sharkmob as a senior UX designer and worked on the game Bloodhunt. I’m still at Sharkmob, working as a UX designer.

I should also mention that I have an honorary doctorate at HiS, which is probably why they keep inviting me to do talks.

What is UX in games?

I’m sure you’ve seen this before, this is a presentation of the design thinking workflow. Design thinking follows the UX workflow closely, which isn’t that strange considering that all design disciplines are closely related.

So what do we do?

• We figure out who the player is.
• We figure out what the feature is supposed to be.
• We help in coming up with solutions to presentation and introduction to the feature.
• We prototype it.
• We test it.
• We iterate on it.
• We help implement it.

It’s about understanding the player and what the player wants. We’re also championing the type of player the game is aimed at.

Not all games are suitable for all players. Creating an understanding for players is important. For a multiplayer game that caters to an audience enjoying social and collaborative work, the features of a game focuses on aspects that are social and collaborative. If the game instead is social and competitive, the focus is different, even if the feature may be very similar.

Say I’m making a player details page. In a collaborative game, I may focus on things like how many gifts a player has given. In a competitive game, I may focus on thing like leaderboards and how many times you’ve defeated another player.

• It’s about teaching the player that features in game exist.
• It’s also about helping the game team communicate those features to the player.
• It’s about teaching the player how to access those features.
• How do they present in game?
• How complex are they?
• How can I as a UX designer make sure that the intent of the feature is clearly understood by the player?

It’s about removing frustration and friction for the player when using the features. If a player is unable to understand the feature or how to use the feature, what is the point of having it? Communicating intent, and getting the developers to understand the intent of a feature can be just as important as removing friction for a player. Balancing complexity and usability is tricky. The more complex a system is, the trickier it is to make it usable. I can make a system easy by applying a step by step wizard for the player, but if I do that, I also take away immediate access from the player. It’s a balancing act and there are a lot of aspects that play in to this.

It’s about teaching the player how to use the feature and making sure it is accessible to the player. We often say that “tutorials are bad” in game development. I don’t agree.
The better we teach the player at the start of the game how to play the game, the more enjoyment they will get from the game in later stages.

This does not mean manuals or chunks of text to explain the game. Those are usually put there because the game team is in a hurry, since they’ve been putting off tutorials and accessibility features to the end of production. Another point I want to make is that accessibility is not about difficulty. Just because something is accessible, doesn’t mean that the accompanying gameplay is easy, but there seems to be some confusion around this where ease of use is also associated with ease of gameplay.

It’s not just about usability, but also about delight.

Sometimes a feature is not about being super easy to use. It can also be about delighting the player. In those instances, you weigh usability against delight, and sometimes delight wins.
I also want to point out that different types of players are delighted about different things.

This leads to a happy player who will then hopefully tell others of their adventures and positive experience. This is not just for the player but also for the game team. Once they know what a user experience designer can help them with, they’re (hopefully) happy to have us on the team. So I’ll try to clarify what this means from a process perspective.

What’s the Initial Step of the Process?

Where does the process begin?

• What is the purpose of the feature?
• What should the player achieve?
• What should the player feel?
• How often is the feature used?
• What is the context of the feature?

It’s all contextual. It depends on what I’m doing and in what context I am currently working. I always try to look at features from a player journey perspective, the overarching goal of the game. Also important – knowing WHO the game is for, because that informs the design. I will keep saying this, because it is important.

It is about onboarding the player to the feature as they play. It is also about progression aspects of the feature – what do I get out of it when I start playing, how does it develop as I play?

• What’s the player supposed to understand about the feature in the first minutes?
• What’s the player supposed to understand in the first 15 minutes?
• What’s the player supposed to understand in the first hour?
• The first day?
• What do we have to teach explicitly?
• What is intuitive or expected knowledge from the conventions in similar games?
• What does the player have to discover on their own?
• What’s the meta game, and how does this particular feature play into it?

Let’s say I’m working on a character creator. Character creators are usually quite special in that they are only used a few times in a game, but they need to inspire delight. Not only that – the feature or system should also help the player do what they set out to do. For a character creator that might be to create a character that represents them. It may be to create a character that resonates with them – representation can take many forms. It may be to create a character that they can identify with. I am this person and this person is me. Taking that into account, I also have to look at what the game team wants the feature to achieve for the player. If there are stats in the character creator, how do I make sure the player achieves what the team wants them to achieve? Do I understand what those numbers do, how they affect play?

What am I supposed to feel when using a feature. Should I feel powerful? Delighted? Represented? For a character creator that might mean that there are options that won’t lock me into a specific gender. It may be that I feel delighted in creating a player character that I feel represents me, that I can identify with.

If the feature is a loot flow, maybe it’s supposed to be as easy as possible? Or difficult, to heighten the sense of stress in the game?

Another aspect that absolutely plays in to how much effort is placed on a feature is how often it is used. A feature that is used rarely might not get as much love as something that is used constantly. A feature that is used rarely might also be more difficult to use than a feature that you use all the time.

Let’s say the game team wants to put an animation of opening a map by unrolling a scroll. It sets a great mood, you almost feel like you’re there. The paper crackles of age, you can almost smell the dusty smell of old paper. It takes about 5 – 10 seconds per opening and just as long to close it. If you use the map once per gaming session, say an hour, that’s fine. If you use it once every 10 minutes, those 5 – 10 seconds are going to feel like an eternity. Giving the player this experience may not be what the player wants in this particular instance.

Also important is the context. If we return to a character creator, depending on the game, they set the tone for the whole experience. They need to be usable and delightful. They might only be used once or twice, but much effort must still be put into them because they have the potential to be very important.

Conversely, a settings screen has to be usable, but it doesn’t have to inspire delight. It may be used often but it still won’t be a screen that carries much weight. Context is super important. It informs priority and weight of the feature.

We also need to consider what the vision for the feature is. To use another example, picking up loot in the world. Depending on how often it happens and in which context, the design of the loot pickup may be very different. In fast paced games I might just run over the loot and it is picked up. In slower games, I might have to open a dialogue and manage my inventory. In some games, opening up a loot dialogue and managing inventory can be a risk factor that heightens tension. It’s all about context.

The vision of the feature informs the context. A looter shooter game handles a feature like loot very differently to a survival horror game. That is also part of the player experience.

What is the Intent and How Does it Fit?

I usually do a requirements gathering pass before I start working. This way, I know that all the stakeholders have had a say. Normally, I want everyone who is a stakeholder in the same room to make sure they can hear what everyone else is saying. Stakeholders include back end programmers. They usually have very good insights into what we can and cannot do. And then I ask questions. Anyone having been put through this exercise by me knows what I’m talking about. Usually we do reach clarity when it’s done though, so I hope it is worth it.

The questions that pop up when it comes to gathering requirements are different depending on the feature created. Who is the player? How does this impact the requirements? How does it impact priority? This can sometimes be difficult to answer, but it is worth it since it will inform so much of the design.

What’s the direction? For a feature like a character creator It might be to let the player be who they are or letting the player feel represented. For a loot flow or a mission transition feature it might be “make it simple”. A clear direction makes it easier to create a coherent game.

What are the game pillars?
How do they apply to the feature you are currently making. Also, what are game pillars? Usually, game pillars consist of around three statements that define what the game is centered around. Pillars focus on the experience of the game, what the player wants and how they should feel when playing.

A few examples might be:

• Explore a deep narrative with friendships and romance that matters.
• Navigate a world full of deception and conspiracies to find the truth.
• Gameplay that is social and accessible.

Having those statements to support you when creating the feature you are creating helps to keep the game on track and on vision.

What’s the razor for this feature? How do we cut off the things we don’t need to focus on what’s really important? What’s a feature razor? A razor is a way to sharpen the design or feature to focus only on what should be there. It’s a statement that helps cut the feature down to the bare essentials. It’s a mental shortcut that helps make decisions and solve problems.

Examples:

• Only what you need, when you need it – this is a razor that we use often in UX and UI design.
• If I think it should work a certain way, it should work that way.

What emotions is the player supposed to feel? I know this is a topic that I talk about quite a bit. But I do believe that if we know what the player should feel when they play, we’ll make better games. Asking what the player should feel when using the feature can be quite eye opening. Not all designers have considered it, even though it is an integral part of the game experience.

It’s totally fine to say “I want the player to feel frustrated” or “I want the player to feel scared” as long as you know why, and what you’re trying to achieve with it.
So how do I work with this information once I have it?

How Do I Work With the Information?

In some cases I start with sketches, and the sketches can be anything from a storyboard to flow sketches.

Let’s say you have a tutorial that you need to define, sketching out the level and where the tutorials should appear might be a good way to set the pace for an onboarding experience. You can also show information hierarchies, and user flows in UIs. How does the player transition from one screen to another?

How is the screen set up? What’s the information hierarchy? Is everything that’s required part of the screens? If not how is it integrated in the screen?

In what situations is the feature used? How is it used? What should the player feel, see, do? Sketch those situations and see if you can capture the basic intent with the feature in your sketches.

Refining the Work

Once the sketches are done and I feel a bit more certain about how to solve the problem, and I may well run the sketches and the design past the stakeholders to make sure I’m on the right path, it depends on what I’m doing.

I create flowcharts to understand the back end of the feature that you’re building, but also to catch edge cases that might not be apparent when you just wireframe a thing. I work with flowcharts in parallel with wireframes, because I always find aspects that affect the flow in the wireframes and stuff that affects the wireframes in the flow.

Flowcharts is also an excellent way to involve back end programmers to better understand the systems underlying the feature and what limitations those systems have.

Wireframes for me as a UX designer are not only about user interfaces. In fact it is very rarely about user interfaces. More often it is about creating event sequences and progression storyboards. I look at how actions turn into reactions and how things are affected in the game based on those reactions. I look at movement and how movement is affected by different actions. I look at the expected response from the game or from other players, and I try to work that into the flow.

I call out callouts (heh) and I am very clear when what happens. Be over the top if you want. Don’t be afraid to have fun when creating the wireframes. It’s always nice when someone in the meeting does a spit take when you present. Being a bit unpredictable also helps sell the design. I use blood spatter, hearts and stars a lot in my wireframes. Sparkly, in love or bloody.

Remember to add tactile, visual and audio feedback. Audio in particular are usually happy to be remembered. Call out UI behaviors, but don’t be too prescriptive about it. Look at where information is placed and what type of information should be in the screen.

Look at flows and behaviors, especially behaviors that go outside the golden path. What is the golden path? It is the expected behaviour of the player, what they should be doing in the UI. Players rarely stick to the golden path. Look at information hierarchies and information structures such as “how do I sort my inventory?” Do you have rarity? Should that be the first consideration? Et cetera.

How Do You Use It?

Prototyping is usually the last step before implementation. Why do we create prototypes? Usually it is to make sure that a feature works the way we have intended to. In some cases like navigation of screens that are not necessarily intuitive, prototypes can be used to determine if the player understands them anyway.

For a feature it may be the same thing. Does the player understand what to do and when to do it? Why do we prototype? To show movement and behaviors in the UI or in other contexts. A storyboard can turn into a prototype or a video to show expected behaviour. Prototypes can be fairly complex, and involve many aspects of the game or they can be quick and simple to show off a concept. The intent is always to clarify what is going on.

When do we start building prototypes, at what stage? I would say as early as paper. Sometimes printing out a set of wireframes to test out a flow can be enough. Prototyping with prototyping software like Adobe XD or Figma can also be useful if the prototype is player facing and there are a lot of answers that can’t be gotten through simple paper prototypes. You don’t need fancy programs like Figma or XD, sometimes a prototype can be HTML. On one memorable occasion, I built a prototype in Power Point. By the end of it I was up to around 900 slides and it kept crashing. My point is, use what works for you as long as you get the message across and it translates well to how it will act and behave in game.

If a feature is easier to implement in engine rather than in a prototyping tool, it might be worth putting something together in engine to test it out on unsuspecting players.

How Do We Make Sure Intents/ Requirements Are Fulfilled?

Testing is the most important part of why I do what I do, because this is where I find out if I have succeeded. In order to run a good test I need to know what to test. To get clear data, it’s better to focus on a smaller part of the game. Usually I talk to the designers in order to understand what they have concerns around. This is also where all the work we did at the start comes in. Intent, emotions and what the player should be able to achieve are all great things to know at this stage. This way I can test for those things.

• Is the player feeling what I want them to feel?
• Can they achieve what I want them to achieve?

Make sure that the players that do come along to test your game is in fact the type of player you want should play the game. Try to use players from outside your friend group and outside of development. Using other developers is fine for smaller tests or for pure usability tests, but normally those of us working on a game have workarounds, we “know” how the game is going to look when done, and we have other knowledge that we can use to understand a game that isn’t finished. A developer is usually also skilled at the game to an extent that outside players will not be, meaning the difficulty might be unbalanced when you test it on players who haven’t played the game before.

Make sure that you can get a read on both what a player does and why they do it. What and how often is usually measurable through telemetry in game. From that I can see how often a player uses a feature and what they do when using it. Why is often measurable through user research. Having someone tell me that they use a feature as often as they do might enlighten the data.

If a player enters a map often, that might mean that the map is useful. It might also mean that the player can’t remember what they need to remember and so have to open the map often, and it makes them frustrating. Those two situations are very different and require very different solutions.

Once the determination has been made to see what to test, players have been found, data sets have been determined, you get to test the feature. This is your opportunity to observe real players playing your game or your prototype and having actual difficulties doing it. Let the developers of a feature observe (but not interrupt) the testing. Usually they’ll see immediately what the problem is, and can correct it until the next test.

Once the tests are done, do an analysis of how it went, of what the biggest pain points were, where the intent fell short and where the players misunderstood or got confused about the game. Hold up the results towards the expected end result. Once the issues are known, you can start working on them.

Updating the Work

Which brings us to iterations. No feature is perfect out the door unless you are very very lucky. This is why we iterate.

Sometimes it’s useful to revisit the intent with a feature. Is it fulfilled? Did the testing show that the intent needs to change? Did the testing show that the intent is fulfilled, but the players are experiencing something different than you had in mind? Testing will let you know.

Look at the data in combination with a qualitative test. Let’s say a player is saying they use a certain feature a lot, but the data contradicts them using it. In such an instance, there might be a disconnect between what the player experiences – OR what they tell the researchers – and what they do.

In some cases when a feature is used is just as important to know as why a player uses it. How often it is used and so on. By coordinating quality – how the player feels about something – and quantity – how often they visit, what they click on etc, it’s easier to understand what went right and what went wrong.

Once the hypothesis is in place and you think you know what went wrong, iterate on the feature and try to hit the friction points by addressing the issues the research told you about. This is where you should revisit the requirements again, if you haven’t already. Understand what the intent is, understand what you want a player to feel. Try to address it. Once the iteration is complete, which is more or less the entire design thinking flow all over again, test it again. Are you getting closer or further away?

Continue to iterate.

Questions

Why housewives?

Because this presentation is also a UX problem.

• How do I make it memorable?
• How do I not overload y’all with information?
• How do I FIT all the information that needs to be in here in this presentation?
• How do I make it a pleasant experience to listen to me?

My solution this time – because I didn’t know exactly who my audience is – was to make it fun, lighthearted, and slightly problematic, but hopefully memorable.

Honestly, while these images are problematic due to stereotypization, they’re also a lot of fun. We have the same problem in games. We stereotype, but we do it in a fun way. We can still be critical of what we do, despite enjoying it.

1. After a fairly unpleasant incident, I decided to moderate my comments, so if they should take a while to show up, this is why.