Let’s talk about process

I show a lot of finished work in my portfolio, but what about the process that leads to the creation of those projects? I work to make each game unique, but each one has a lot in common when it comes to the thinking behind it. Using examples from several different projects, I’d like to talk about how I approach UX/UI in general.

Definition

The first step in finding a solution is to define the problem. This involves asking a lot of questions and taking a lot of notes. Before starting work on a game, questions I might ask include:

• Who is going to play this? What is their age, location, culture, gender, economic background, job? What are their interests and hobbies?
• What should they get out of the experience?
• How and when will they play the game? How does it fit into their life?
• What level is their games literacy?
• What platform will they play it on? What screen sizes and aspect ratios, what input methods?
• What resources do we have to make it? What’s the timeline of the project?

It’s important to collect this information and share it with the team. In client work, it’s often illuminating for the clients themselves, who might have been unsure of what they were after in the first place. Having the problem agreed upon in writing can be helpful in the end as well when the client and team can look back and say, yes, we absolutely achieved what we set out to do.

Research

Once the problem is defined, it’s time to research it thoroughly. This involves learning about the target audience and interviewing them if possible.

It’s also important to gather information on the market and competition to find out where the project fits and how it will distinguish itself.

Analysis

Having collected all this information, it’s time to try and make sense of it. Creating personas and user stories can help make the audience feel less abstract and help elevate the goals of the project from base needs of vague ideas of people to well defined human beings with motivations and aspirations.

Deep into development, it can feel like we are just working through a backlog of features and tasks, but it’s important to keep in mind who we are building things for and why when it comes to making decisions and prioritizing work.

Accessibility

I’m a believer in designing for disability. I’ve found that designing for someone at the extreme makes the game better for everyone else along the gradient of human experience. I try to educate myself on visual, motor, hearing, speaking, and cognitive disabilities, and at every stage work to include as many people as possible from the start.

I could talk for ages about this, but in the interest of brevity here, I will simply say it’s important!

Design

Design is a broad field, but in every stage there is a loop that involves three steps:

• Ideate
• Prototype
• Test

In every part of design that I outline here, I am always getting another pair of eyes on my work to check my blind spots, challenge my assumptions, and strengthen the work until it is ready.

It’s important to test designs on players, after all they’re who you are building the game for, but it takes experience and care to ask the right questions, sort the relevant data, and interpret the findings in a way that is actionable.

User Flows

When starting a project, typically a game designer will have written a game design document that is primarily concerned with what the player can do in a game, and at this point we’ve determined why the player is doing it. Now the question I need to answer is, how does the player do it? To answer this, I start with user flows.

I intentionally try not to be precious about the aesthetics of these early design steps. Everything generated at this stage is treated as disposable. User flows should be fast and easy to create and iterate on so that if something is not working, or the underlying game design is changed, there is no hesitation or friction in throwing out anything that’s been made irrelevant. These are methods for communication, not works of art.

I’ve adapted a user flow process from 37signals that’s simple enough I can work through a problem with a game designer on a napkin over lunch.

Every screen has a title and possibly a description of what the player is seeing, followed by a list of actions the player can take. Using arrows flowing from left to right, we can trace what the user sees depending what they do.

At its simplest, this can help work through a particular player reaching a single goal. At its most complex, it can serve as a tool to map and discover the scope of what screens will need to be designed, what the player can see and do on each one, and the consequences of their decisions.

User flow for Annenberg Classroom’s That’s Your Right

If a user flow requires more complexity, I will occasionally create something closer to a flowchart, but I find too many abstractions make communication among teammates and clients less clear. In my experience, the simplicity of the method I use hits a sweet spot that most people find easy to parse quickly.

Wireframes

Wireframes are the next step in answering how the player moves through the game. Like user flows, these are low fidelity on purpose. It’s important to keep the focus on the organization of UI elements and the player’s interactions with them. You don’t want clients, collaborators, or test users being distracted because they’re worried you’re going to use font or color they don’t like in the final product.

I keep wireframes gray and low fidelity, using color occasionally to denote interactable or highlighted elements, and to draw attention to the current interaction.

Interactions in games are often difficult to describe in a single image, so wireframes often grow into a storyboard-like presentation to make sure every step is clear. For particularly unique interactions, sometimes animations or interactive wireframes are helpful to the team.

On the other extreme, sometimes all that’s needed is one bite-sized graphic to communicate a simple interaction.

Mockups

Once the dust has settled and the wireframes are solid, it’s time to move onto high-fidelity mockups. These seek to answer the question: What does the game look like?

This process includes a lot of research, creation of moodboards, sketches, conceptualization, iteration, feedback, art direction, and finally mockups.

Once I’ve hit the final aesthetic, the UI from the mockups can be fleshed out into a complete UI system and used to export assets for inclusion in the actual game. It can be helpful to create a style guide to assist other artists and future designers on the team in matching the aesthetic.

In some cases, a game already has an established style and the challenge is to create UI that matches or complements the existing work.

In the case of a project like Annenberg Classroom’s That’s Your Right, I was working to match a style defined by a team of two extremely talented artists. Even now, it’s hard for me to pick apart where their work ends and mine begins, which I count as a success.

Implementation

Of course, the work doesn’t end with handing off a folder of assets. Great UX means fluid layouts across different aspect ratios and screen sizes, snappy animations, and all the small adjustments that make for a game that just feels fun. Plus, a familiarity with the engine and access to the project means the details of the design don’t need to be compromised.

It’s also hugely rewarding to be able to get your hands dirty and add small touches of joy where no one expected them.

All of the little transitions and flourishes built in-engine are a key component to the character of the UI and communicating to the player what is happening and what effect their actions are having.

Ship It!

There are a thousand other considerations depending on how many hats a team needs you to put on. Sometimes I’m directing the creation of music and sound effects, or making marketing materials! But hopefully what I’ve shown here has provided a peek into my thought process while working on games.

-Dave