I’ve noticed, in my 20.000 odd years as a developer, that some designers have a harder time figuring out how to describe a feature in a way that makes sense to a programmer or a tech designer or just in general.

I figured, since this happens to be one of my strong skills – or so I have been led to believe – that I’d take you through my working methods, step by step, to give you an overview of how I work. There are a few discrete steps in figuring out a feature:

1. Vision
2. Requirements
3. Technical Requirements
4. Design Work
5. Prototype
6. Implementation

This is very close to the idea of design thinking. The phases are similar but not exactly the same. Usually the discovery process is handled by the designer doing the feature design, and I take over when it’s time to deal with requirements and tech requirements. Those two may seem very similar, but sometimes we need to change designs because the engine can’t handle a certain thing, or performance costs are too high. Or we power through and build a new feature in the engine to make sure we can handle the vision. This is obviously more costly than creating a feature that doesn’t have those requirements. Hence tech requirements as a discrete step.

Design Thinking usually start with an understanding of the feature or idea. In that phase you develop a clear idea of what the players or users want from the feature, and by doing that you define the problem space you’re working in. This is basically what the designers do when they develop the vision of the game and it also has an impact on the individual features.

The next phase in design thinking is exploration, which consists of ideation and prototyping. Those steps are covered by the design work and the prototype work. Lastly, in design thinking there’s materialisation which is the implementation and testing phase.

In an ideal world that’s what comes next in game development as well, but as we shall see, things are not always that straightforward.

Actually, as a game dev that has been working on process and structure in previous roles, I would argue that nothing is straightforward about game development. There will always be curve balls and disruption, it’s just a question of how many curve balls and how much disruption.

Let’s say we’re making a health bar for a player character or an enemy (thank you for the suggestion Lina). I would argue that even though those two are related they’re two different features. They need to convey slightly different information, but let’s pretend things are simple for now.

What I always try to do as a UX designer when confronted with a new widget or feature is to try to understand the underlying system and the intent of the feature. My first stop is the design document, or if that doesn’t exist (and you’d be surprised how often that is the case), I dig into questioning the designer. I use the following questions.

• Who is this feature made for?¹
• What is the purpose of the feature? What’s the intent with the feature?
• When does the feature come into play? When do I as a player need to see it?²
• Where is it used?³
• How does the player use it?⁴
• Why do I need this feature?⁵

Speaking from experience, designers have a tendency to not think a system all the way trough. Asking the right questions helps create a shared understanding of what the feature is, and how to present it to the player. Most designers go by feel, or that is my understanding. This means that they have to see it and feel it in game to be able to judge if the design works or not. I don’t work that way at all. I am a systemic designer, meaning I can “see” the feature in my head, start to finish. An iterative designer usually can’t, but what they lose on iterations, they usually gain in speed. I am slow, but I can tell you if a design works or not before putting it in game. That may seem arrogant, but usually I’m right at least 70% of the time.

Because I am a UX designer, I can use these powers for good by asking questions. Because I am a UX designer, I also poke holes in features and find edge cases, which is also why I’m not a very popular person.

Breaking down a feature usually require knowing how features are normally structured in games. Returning to the health bar, I would ask questions like:

• How much health does the enemy have?
• Will there be one shot kills?
• If there are one shot kills, do we need health bars for those enemies?
• When do we show the health bar?
• Is it visible only when a player looks at an enemy?
• Is it visible when the enemy engages with the player?
• When the player engages with the enemy? (Two different situations!)
• When the player draws aggro from an enemy?
• Are there enemies that are blocking areas?
• Do we inform the plater if an area is too difficult with regard to how far the player has progressed?
• Are there additional features we need to show in the health bar?
• Armor? Barriers? Status Effects? Damage vulnerabilities? Damage immunities?
• Are there aspects of health we can show in other ways?
• Does it have to be a health bar?
• If we use status effects, can it be a VFX or a texture?
• Etc, etc, etc.

Obviously the list goes on and on and on. Some questions are easy to answer. Some will give rise to new questions.

One of the most important things to consider – as a UX designer – is “can we show this without using a UI widget?” Many games use UIs as a band aid to prop up systems that are difficult to explain to players. A health bar may seem simple to implement, but add to that a damage system displaying vulnerabilities and immunities, shields, barriers and buffs and all of a sudden you have a lot of information that needs to go into a limited area.

In addition to that, as a player, you need to be able to decode whatever messages are hidden in the health bar very quickly unless you’re playing a game that is turn based or has slower action. Even then, information overload is a very real problem. There are multiple ways to provide feedback that are not reliant on a mechanical UI but they are usually more subtle and can be a lot harder to read if they’re not super obvious. A feature like the health bar is probably not the only thing you need to keep track of on a screen during combat. You’ll have a bunch of enemies coming at you, the environment you fight in may draw attention to itself by being very busy, making enemies hard to see etc. As a UX designer, you need to take ALL of that into account when designing. Testing widgets against different backgrounds is usually a good idea. If the widget is hard to see in one of them, you’re in trouble.

A poison status effect can have a VFX or texture signalling that this enemy is poisoned. Add damage floaties to pop out of the poisoned enemy and you have a clear visual feedback. Audio cues with “oof” and “argh” to indicate damage, or as in the case of poison or acid, a sickly fizzing to demonstrate that the poison or acid is active.

An enemy on fire can start flailing to put the fire out. A damaged enemy can start limping and moving slower. In some cases you may want to use variations of all of this feedback, but to find out, I usually gather requirements. For me, a list of requirements is a list of statements that can be answered “yes” or “no”.

In some high level instances, I’ll also use User Stories. User Stories are useful when it comes to understanding the feature at large and when it comes to communicating with the design directors or leads. A user story is usually structured by starting with the person intended to use the feature – which means this can be a player, a developer or another recipient. “As a player”, “as a programmer”, “as a designer”, etc. The next step is to define what comes out of the user story. “I can open up a map and see my position”, “I can identify error messages easily”, “I can enter parameters to determine weapon damage”. Finally, we define why we need it. “So that I can always see where I am in the world.”, “so that I don’t have to dig through logs to find the issue”, “so that I can easily change the damage and test it without programmer input.” For the health bar, I probably would write something like this:

“As a player, I am able to determine when I’m damaging an enemy, so that I’m kept informed of enemy damage status.”

The intent with User Stories is to give the developer an understanding of what they need to do, and why they need to do it, but not how to do it. How is (or should be) up to the developer. For me, I also break down user stories into yes/no statements.

• I can see a health bar when I look at an enemy.
• I can determine if my attack does damage.
• I can determine how much damage my attack does.
• I can see if the enemy is easy, medium or hard to kill.
• I can see if the enemy has armor.

Etc etc.

For me it is a lot easier to create a design when I have a good idea of what the requirements are and how they play into the underlying systems and features. A damage system with different types of damage, vulnerabilities and immunities puts a whole other spin on the requirement “I can determine if my attacks do damage” than one that is limited to one type of damage.

This also gives QA/ QV a very good idea of what to test for. Can I see a health bar when I look at an enemy? If no, then the feature obviously doesn’t work.

Working with iterative designers often require me to make room for what ifs. I’ve found that many might build on widgets that can be difficult to expand or modify unless I’ve already taken those modifications and additions into account. I think it may be equally frustrating for iterative designers to answer questions at the start of feature development as it is for me to have to redo a chain of designs every time a new change comes in.

Working as a senior/ lead UX designer, I usually try to play to the strengths of the team. Not everyone is suited to do everything. My strengths lie in deep systems design, analysis, and balance. I can certainly do iterative design – and I have – but the best results always occur when working methods between design departments gel. This does not mean that you as a designer should work exactly the way someone else wants you to. It means you find a way to work together.

Some unasked for advice. One of the first things you should do as a designer is to figure out your strengths. Don’t ignore your weaknesses, you do need to address them as well, but play to your strengths, and you’ll get the best results.

Why am I saying this? Probably because I know that the way I work doesn’t suit everyone and the method above is not going to work for every designer ever. But it’s a tool. See if you can use it.

1. It can be aimed at a casual gamer or it can be aimed at an expert gamer. Sometimes both of those exist as an audience for the same game. The experts usually have different requirements than a casual gamer, and since the casual gamer is more likely to be the main audience, the expert can be made to dig a bit more. Being an expert, though, allows for that.
2. A feature that can be used in a calm environment without many distractions can be more complex than a feature that is used in a busy environment with a lot of additional information being conveyed to the player. This is context. You should always know the context of the feature.
3. Similar to the when question, but if a feature is used on HUD only, that’s different to a feature that needs to be available both in HUD and in a menu or only in a menu.
4. Some widgets are passive and only require the player to look at them. Some are active and require player input. Player input always changes how you design a widget or feature.
5. This is one of the most hated questions ever, but you SHOULD ask it. Why do I need this thing? What does it bring. What’s the purpose. Why is it here. If a designer can’t answer that question, ask yourself why you should put time on designing it.