Role: Game Design • UI • UX
Platform: PC • PS5 • XBOX • Nintendo Switch 2
ZERO PARADES: For Dead Spies is a narrative driven role playing game from ZA/UM studios, where you play a burnt out spy reconnecting with their old network to attempt an impossible assignment.
As Senior UX Designer at ZA/UM, I was tasked with leading a small multidisciplinary team developing the menus and gameplay of Zero Parades, for PC and console. In this role, I took designs from concept, through wireframing and UX development, to UI illustration, creating assets and documentation for implementation in Unity.
UX Feature Team
Coming into the project, I was appointed as lead in the UX feature team. I prioritized and costed menus and gameplay elements based on urgency and scale, ensuring that the specifications were in scope, and making sure everyone had what they needed for production. Each discipline had different requirements to cater to.
Together, we developed menus and gameplay in verifiable stages from the start to the end of the pipeline. Each stage would be validated by stakeholders. Each feature within the UX feature team would be a part of this production flow. A features goals were broken down into milestones, and executed within sprints.
Feature design
In designing a feature, I would begin from first principles and build out potential solutions axiomatically. This process ensures that the end product is always a informed by all design requirements. It also ensures that stakeholders are aware of the process and understand when and how they can have input.
- Define Axioms - In interviewing the stakeholders, directors and writers, I was able to deeply understand the intended experience for the player. In interviewing tech and engineers, I would learn what the functional limits of our systems are. These would be the axioms; statements that are true about the game, regardless of what it becomes.
- Produce questions - The axioms would be redefined in terms of what questions the design needs to answer. These are phrased as “how might we..” questions, allowing open ended design solutions.
- Propose mechanics - I would ideate possible solutions we could use to answer the systems’ questions. Designers, writers and artists could all have input.
- Review - The solutions were then narrowed down by how efficiently they solve the design problem. Stakeholders would be given the opportunity here to weigh in on preference.
- Produce wireframes - Preferred mechanics would be synthesized in a way that creates a system that maximizes utility by addressing many questions at the same time. The wireframes would be in a format that the wider team can test; more often a user journey flow or playable prototype.
After reviewing with stakeholders, they become documented in the GDD, and would move on to become a feature for development.
Here is an example portion of the process, as it was used in Zero Parades for the Pressures feature:
Menu Development
In working with the art team, I translated initial concept art into functional UI, ascribing patterns to visual elements in order to create a formal design language for the game. Together, we iterated upon the design until we had something that was both reflective of the aesthetic intent, and functionally optimised. We maintained a dialogue with the art team throughout production to ensure this aesthetic consistent throughout.
Accessibility
A key goal for me was to was to ensure that the game had a wide range of accessibility features. We ended up including settings for control remapping, colour-blindness, motion sickness, motor control assistance, high contrast visuals, audio cues, and extreme content censoring. The game could be played with either mouse or keyboard, or even one handed on controller.
Onboarding & Tutorialization
In order to teach the player the extent of their autonomy, I identified the games' Utility Map; a graph of how the systems group and influence each other. This is used to ensure that when systems and concepts are introduced to the player, they build upon game knowledge they already have. For example, the player will learn what Pressures (our stand-in for health) are before gaining Consumables (items which are used "heal").
Becoming onboarded into a system is a 4 step learning process: Awareness, Testing, Action, Feedback. For example, for Consumables:
- Awareness - The player finds the item. A notification directs them towards the inventory. Inside, the item has a *new* marker.
- Testing - Selecting the item will tell the player it's effects and show a preview of how it would change the current Pressures when used.
- Action - The button below the item is labelled "hold to consume". On console, it also has a button prompt. The button fills as it's being pressed.
- Feedback - A screen effect plays, and the Pressure levels animate.
