What do you mean they’re not the same?
After a few popular tweets (15 likes!) about UX design in games, I figured I’d write a few posts on the topic. Out of necessity 1 I’ll have to keep it generic, and the games I use as examples should not be seen as good or bad, they’re just illustrations.
Likewise, the examples I use as real life anecdotes span my entire career of 19 years in the industry.
First I think I need to clarify what UX design is. A lot of people confuse it with UI design which is not the same thing, although it is related. After that brief explanation, I’ll go into the process of how I work. This is sort of the basic information you need to be able to understand the following posts.
What is UX design?
In short, it is the design of an experience. My work consists of:
- Flowcharts
- Wireframes
- Information Architecture
- UXR (User Experience Research)
- Scenario writing
- Interaction design
What is UI Design?
- Visual design
- Colors
- Graphic design
- Typography
- Layout
In other words, user experience design is about function and user interface design is about form.
As an example I’ll use a video clip of the game Mad Max. The way I move from A to B, equipping an Archangel is UX design.
The way it looks, the cool icons and the layout of the screen is UI design
I’ll take you through my process and give you some ideas around how a real life situation can play out. This is only one part of the team. Each department, programming, scripting, art, go through the same process but slightly staggered. Design goes first, programming comes next, art and scripting are almost simultaneous.
Step 1: Requirements gathering
This is where you sit down with the team building and designing the features. Hopefully this is done early in the process, but in my experience you can be dropped into requirements gathering at just about any point.
Best case scenario you get in early, the feature is documented and the devs are friendly and they’re open to feedback.
Worst case scenario, someone sends you a bug with the feature already in game and you get to do damage control and yell at people while trying to fix it with gum and duct tape.
Actual developer story: A colleague sends me a screenshot featuring an interaction prompt to a menu that no one’s ever heard of and no one knows how it got there. We remove it.
Another actual developer story: Designer comes to me with a potentially very costly feature and an idea how it can be done. We sit down, go over the intent of the feature, figure out how to do it at half the cost while preserving the intent.
What comes out of this step? Normally, at this point, there’s a design brief, a document that states intent.
Step 2: Wireframes and flow, design documentation
Here’s the thing. I do design documentation for just about everything. There are a few reasons for that.
a) Understanding the feature. Yes. You have to think it through properly if you’re going to write a cohesive design document.
b) Communication. My documentation is always available, even if I’m not. It also helps people who evaluate the game to make sure that the designs are following Cert rules2
c) Design history. We make design decisions all the time. Keeping track of those decisions allow us to in some cases discard decisions that are no longer valid and make sure we stick with good ones that were made for valid reasons.
d) It makes me expendable. I can walk away at any time with a clear conscience.
Actual developer story: The UIs in the game weren’t following my design on paper, and there were arguments around the screen. I pointed to the design documentation, and we sorted it out.
Another actual developer story: Our lovely and smart QA analysts could write good test cases without much input from the UX team because the documentation informed them of how the UIs were supposed to work.
What comes out of this step? Wireframes, design documentation, flowcharts.
Step 3: Prototype
This is unfortunately a step that’s being skipped more often than it’s being implemented, because prototyping takes time.
I do like creating them though. If nothing else, because a flow is so much easier to demonstrate if you can click through it.
The drawback is that a prototype can sometimes be too raw when the recipient tries it out.
Actual developer story: Me and a programmer worked really hard on a whitebox prototype 3 in game. It was super rough but the complex functionality was there and worked. Our creative director nixed it because it didn’t live up to their visual expectations, and they couldn’t see beyond the magenta squares.
What comes out of this step? Prototype in engine or in a prototyping tool. I once did a 1000 slide ppt as a prototype. I don’t recommend it, but needs must…
Step 4: Review
This I have found is one of the most important steps. You have to review the work you do with stakeholders and you have to get a sign off. This is super important because otherwise nothing stops people from pulling the rug out from under you.
If you have a formal review done with proper feedback. It is much harder to change a design. A formal ”yes” requires change requests4. An informal ”yes” can cost you weeks of unscheduled work.
If my experience is anything to go by, it’ll happen regardless, but having a decision paper trail helps when asking for resources.
What comes out of this step? Usually a bunch of changes either in the form of notes or in the form of bugs. If you’re lucky, you might even get an approval first time round.
Step 5: Implement
At this point you want the whole shebang in the game. With a proper review, all the stakeholders, including artists, programmers and scripters should know what’s being built.
If the project is lucky enough to be able to use prototypes in engine, this step is all about making things real, real data, real art, real animations.
Actual developer story: In one of my projects I’d been very careful to specify how a specific screen flow should work. I handed it over to my colleagues. Once it was in the game I was shocked. The pattern for navigation was totally broken. People had completely misunderstood the pattern and we had to redo it all. The drawbacks of not prototyping or properly reviewing.
Another actual developer story: I once did a very simple game. The game was so simple I prototyped it using animated gifs. The developer nailed it first try when implementing.
What comes out of this step? You start seeing the UIs and widgets in game and can test all the theories.
Step 6: UXR testing
Once the feature is in the game it has to be tested. And once it’s been tested with real players, usually the loop repeats until the players and developers are happy.
Actual developer story: We made a widget that we were sure would work for our players. They could not understand how to use it. We had a perfect 100% fail rate. It was almost beautiful.
Another actual developer story: I was creating tutorials for a game, and I felt that they were very directed. All of them were on an island. After UXR testing, they were a straight line. I literally had to build the player into a fenced path and put obstacles in their way. After that revamp, the players loved the tutorial, and the game.
Step 7: Polish
This happens rarely. Polish is the final stage where we get to fix all the small things that bothers every developer when finaling a game. It’s the last step on the way.
Actual developer story: About 6 months before ship on one of the games, I sat down with a stopwatch and an excel sheet to balance a part of the game that no one had had any time to look at. I found a lot of interesting fixes we could do, and the game was better for it.
- Necessity, also spelled non-disclosure agreement.
- Cert or certification is a step all games that ship on 1st party hardware – Playstation, Switch or XBox, basically any console – must pass or the companies making the hardware can deny a release
- Whiteboxing is pure functionality without any art whatsoever. It’s used to demonstrate function, not art.
- A change request is a document containing a call for an adjustment of a system; it is of great importance in the change management process. A change request is declarative, i.e. it states what needs to be accomplished, but leaves out how the change should be carried out. (Wikipedia)
