🌊Give me a Flow! - Application of UX Flows in Game UX Design

Building a game is expensive. Making Art, Motion, FX, and Sound and implementing all of those takes time, even more when you need to iterate over multiple elements to make sure the game feels “fun”, engaging, and usable. That’s why, we, designers reduce games at their simplest thing to allow fast and costless iterations. One great example for us UX Designers are Flows!

❓Why do we use UX Flows?

Games are sequential. Screens appear one at a time, information and interactions appear depending on the context (inputs, game states, level design progression, etc.)
It can be tough to keep track of the patterns and dependencies of different elements at each given moment using prototypes only. In short keeping track of the navigation, information, and interaction architecture.

In the UX process for making UI, it’s very common to create Prototypes to show and test how those architectures work in action and how much usable they are. Still, building prototypes takes time, even with the latest prototyping software and those prototypes do not represent the whole architecture at first glance, which means we can still be prone to making big usability architecture issues.
We can simplify the design even more with diagrams to ensure our architecture matches players’ needs at each given moment.

⚠️Before you dive deeper into the article!

Before diving into the categories of UX Flows you may need the legend of my flow library to better understand my examples.

🔷Types of UX Flows (categorization by me)

Here is how I personally (Disclaimer) categorize UX Flows based on needs and usage.

🧭 Navigation Flow: Representation of the different screens and the navigation (access and exit) between each one

As an example, here is a flow I did for a mobile project, representing the navigation of the game between each screen or overlay.

Navigation Flow of a Mobile Project I worked on

📁 Information Architecture Flow: Representation of the different information composing those screens at each given moment (bonus: and how they are displayed)

For example, here is a flow I did for personal training based on my school redesign project of the inventory feature from Immortal Fenyx Rising. (Sub screen of the flow not included)

Information Architecture of Immortal Fenyx Rising Inventory Screen I made (sub screens not included)

📲 Interaction Flow: Representation of the player’s actions and the states of the game system

For example, here is a flow I did for a personal case study to analyze what are the player’s actions and states needed to change weapons while aiming in A Plague Tale Requiem.

Flow I made as a personal case study on A Plague Tale Requiem

📰 Wire Flow: Turn wireframes into a diagram to make the navigation and information architecture more readable at first glance to people (helps when you don’t have the time to make a prototype)

For example, here is a wire flow I did for the purpose of this article using previous front-end menu wireframes (HUB, Shop Overlay, Quest Log & Collection)

⚠️Those terms vary from designer to designer, some might call a Navigation Flow “a Screen Flow”, and others might call an Interaction Flow “a User Flow”, what’s important is how they are beneficial not how we call them.

Depending on the needs we can mix them. Maybe you need to map how a player might navigate a specific feature but also what information are present at each given screen and also what are the interactions to access and exit. All that, to make sure you don’t miss a thing before making a prototype, but also to identify possible friction zones.

Here is a flow I did for a mobile project, representing the navigation, interactions, and information architecture of the skin collection feature.

Mix of Navigation, Information, and Interaction Flow I made for the collection feature. From a Mobile Project I worked on

🔬Scope of Flows

Depending on the needs, you might want to select a scope for your flow. If you want to map the architecture of your equipment inventory, including the quest logs might not always be relevant. (might!)

Usually, the game industry works from a High-Level to Low-Level (or Macro to Micro, the principle remains the same)

High Level represents the game experience from an abstract and wide point of view, what are the goals? the guidelines? how much the game experience is consistent?
Mid Level goes more into detail and represents a system (a bunch of related features), how much the system parts are consistent with one another?
Low Level is the most detailed. How does a feature work exactly, and how it’ll be created?

You can apply these scopes to your flows:

High-Level Scope: Representation of the architecture of the whole game

Mid-Level Scope: Representation of the architecture of a complete system

Low-Level Scope: Representation of the architecture of a feature

For instance, you might want to map a High-Level Navigation Flow to allow the team to keep track of the main screen to produce.

Here is a part of High-Level UX Flow from Mario Kart Tour I made a few months ago to train & improve my UX Flow methodology (still it is too detailed for a High-Level Flow)

A part of High-Level UX Flow from Mario Kart Tour I made few month ago as a personal exercise to improve

📌Tips when making flows

The biggest advice I receive is to treat your design doc just like the game, so UX your documentation! Make it usable, easy to read, to learn. Even for flows! The more your guidelines for flows make it usable for you and your team, the easier it’ll be to make your game architecture more usable.

Some usability guidelines I have been taught and that I now use:

1. Never cross similar flow lines

2. Never make repetition (ex: display 2 settings screen on the flow, but in fact, it’s the same one)

3. Join the flow lines as much as possible

4. Flow lines must be the more direct possible

5. Keep things spaced and with consistent spacing

6. Use different shapes, colors, and visual weights (but not too many colors)

These guidelines suit me well and I can tell that from regular usage these past months that it does make them more usable! (Still, sometimes you can break these guidelines when there is a contradiction)

Thinking of your flow lines like roads, metro lines, or a map does help, you don’t want it to be all tangled. You want it to be the quickest and the easiest.

📈Beyond a UX/UI Tool

With imagination, you can turn a UX Flow into a tool that can help you and/or your team in other topics than just the architecture of UI.

From what I’ve been taught, you can use a flow to track the current state of the production. This helps to prioritize which features need to be developed first.
Recently, from what’ve I tried you can also use a flow to map where critical signs&feedback are needed.

As an example, I turned this High-Level UX Flow into a tool that allows to track the production state (Next Sprint, In Engine Proto, Skinned, Polished, QA..)
I also turned it into a tool to map types of critical signs&feedbacks per screen (decided with the artists and designers)

Screen of the High-Level UX Flow of my mobile project during mid production

Make it a tool that adapts to your current needs!

✅Conclusion

Making flows before any wireframes, prototypes or art assets will help you have a wide view of what you are designing. It will help you spot frictions, and ensure a good architecture. You’ll see that after mapping a UX Flow, making a prototype will be a blast!

Quick Reminder of the benefits:

• Costless iterations of the Architecture
• Keeping things documented to facilitate rework and content growth
• Source of the truth of the design and targeted scope
• Production tracking with feature dependencies

That’s it for me. Have a great day! 😁