Shared Design Understanding: #TheUnlock at Riot Games

How did we build a resilient shared understanding of desired player outcomes across platforms, games, AND companies?

Have you ever struggled with getting a group of cross-disciplinary folks to agree on a shared vision? We feel you. In 2022, our team had to find a way to get over 300 people across multiple disciplines, game teams, countries, and even companies to work towards a single vision — quickly.

In Part 1 of this behind-the-scenes series about the user experience (UX) design work that went into our Riot Games + Xbox Game Pass partnership, we explored how user experience design techniques and principles helped us during the business development stage of this project: asking tough questions quickly to help us get to a true “minimum lovable” product definition, as opposed to the minimum functional product.

But don’t worry if you didn’t read Part 1! It’s time to grab your beverage of choice as we explore how our user experience design techniques helped us communicate and iterate on a shared vision at scale that kept our players at the center of the action — and learn some techniques you can apply in your own work. (If you’d like to start with some background about user experience as a career and discipline, check out Behind UX Design Roles at Riot Games.)

What problem were we solving?

On June 13, 2022, Microsoft and Riot Games announced a groundbreaking new partnership — Riot would be bringing our free-to-play games to Xbox Game Pass members. Not as a perk, but as a membership benefit providing extensive content access across all of our titles. Just six months later — on December 12, 2022 — we officially launched #TheUnlock, allowing Xbox Game Pass members to link their Xbox profiles to Riot Accounts and, if their Game Pass memberships were up to date, receive access to hundreds of champions, Little Legends, arenas, and more across all of our games. We effectively had one month for pre-production and 5 months of production time prior to launch.

Once the deal was signed, there were a few slow weeks of pre-production cross-company introductions, Teams invites, contract review, and leadership planning before things began in earnest after our midyear break (yes, we take a week off mid-year. Hard work deserves dedicated rest!) A parent Slack channel was created where the majority of Xbox conversations would take place. At its peak, this channel boasted well over 300 members.

The Xbox Game Pass project Slack channel header as seen a few months after its peak in late 2022 — at 303 channel members, it represented a non-trivial percentage of Riot Games employees, even with post-project channel departures. The “Game Pass Design” Slides document seen in the Pinned list here will be a focus of this post.

In the old days, we’d have spent weeks and weeks trying to define every detail about the product before moving forward, but we are squarely in Agile development at this point in Riot’s history. We would be moving forward with an incomplete picture at best — and if one team has an incomplete picture, that problem is likely magnified across all teams. How could we prevent uncertainty from becoming a sea of inconsistent experiences — without resorting to traditional, top-down waterfall design methods?

In this post, I’ll share how I took signals from the questions our partners were asking to inspire a shared understanding document that we distributed worldwide across Riot, and what kinds of collaboration were enabled by the existence of that document. We’ll cover:

• Questions as a call to adventure
• Building shared understanding at scale
• Using player-focused storytelling to build shared vision
• Meeting teams where they are with guidance targeted to their point of view
• Wrangling brand concepts to dispel myths and misconceptions
• How YOU can apply these learnings to build your own shared understanding at scale!

The announcement of the Riot Games and Microsoft Game Pass partnership occurred on June 12, 2022, and this image made the rounds quickly. It represents the promises made to players about what we’d be building out for release later that same year.

Questions as a call to adventure

As our teams roared to life after Riot’s 2022 summer break, I noticed that many questions coming in from new group members were technically questions that could be answered by the Miro boards I generated during business development.

Some of the most common questions were things like:

• Are we asking game teams to do any work? (Yes: notifications, catalog badges, item notes, etc.)
• Are there any changes to our social sign in flows? (Yes, new conditional behaviors.)
• When are players notified about their membership status and benefit unlock? (At the time of profile linking IF a member — but if Game Pass membership is started after the the Riot Account and Xbox profile are linked, players would learn about their benefits the next time they logged into a game.)

Rather than view these as an annoyance — “hey, we already answered this!” I viewed this as an opportunity.

The fact that we were still getting these questions meant that the document format — the original business development flows in Miro — didn’t match the mental model of the new folks we were onboarding.

During business development, it was largely engineering leaders and product leaders who are used to taking a zoomed-out approach and coping with complexity. As we broadened our scale, there was an opportunity to meet more folks where they were by presenting that information in different ways.

I was also inspired by the memory of working as the first designer on the Echo Look, an Alexa-enabled fashion camera and service that was available for 3 years at Amazon. During that first-of-its-kind project, we relied heavily on shared understanding via my storyboards and scenarios to onboard new team members and ensure project development was always headed in the same direction.

It was time to assemble the rapid stream of questions, look for patterns, and use that information to level up our design communications.

Building shared understanding at scale

In general, questions are often an indicator that there is a gap in the “shared understanding” of a working group. Gaps in understanding are normal and natural. But for every person who asks a question on a large project, there are likely others who don’t know to ask it, or haven’t gotten there yet. Rather than answering questions and walking away, funneling the answers to those questions into some sort of common shared understanding heads off the kind of drift and assumption-based decision making that hurts so many projects down the line.

As a result, I took a couple of weeks to adapt the information from the flows into a more easily consumable format, in this case a Google Slides “presentation” — and during that time, noted any common questions so that I could incorporate those into the deck.

The success criteria I had in mind for this new deliverable:

• Make it easy to onboard new project members across Riot
• Ensure we were all working towards the same vision of player success
• Provide actionable player scenarios to aid in discussions, JIRA, and QA planning
• Communicate core brand standards and concepts broadly
• Clearly delineate the difference between the in-game experience and the platform experience

After noodling for a few days on what information people were seeking and how I might present that to folks in a way that would serve all teams, I landed on the following structure for the first version of the deck:

• Project Overview
• Scenario Breakdowns
• Surface Inventory

This seems pretty basic, but that’s the point. This was a project running at the speed of light, and being precious about my shared understanding deliverables while I searched for the perfect set of content could actively cause harm or just miss critical opportunities to help teams. Instead, I optimized for getting to first release, trusting in the fact that feedback would come in quickly that would help me to expand in the right directions. Let’s look at how the deck content first materialized.

At early stages in product development, it’s more constructive to focus on starting the right conversations, rather than trying to have all of the answers.

Project Overview

Deal Context, team, and desired overall outcomes

Some of the questions coming in were basic “what does success look like?” or “How does Microsoft intend for us to integrate?” While it wasn’t necessarily UX’s job to answer these questions, they were necessary context to understand and solve player-facing problems.

There was some level setting up front — key design contacts, and a really, really rough design schedule.

An incredibly optimistic and simplistic early draft of our schedule. Oh, how optimistic we were. But it was useful in communicating some key work chunks, and the fact that game team work would be in parallel to the Player Platform work.

Within 2 weeks, that draft schedule — as driven by our Player Platform Game Pass UX team lead Melody Seng and Visual Design lead Tiffany Le — turned into something much more substantial which reflected “late breaking” information about designs that were basically due Yesterday™ due to new technical information.

A second, more refined version of our programwide design schedule shared publicly through the companywide Game Pass Design deck.

But many people coming to this deck weren’t even working directly with Player Platform designers. The other critical part of the Project Overview section was the deal overview. This section included two major conceptual beats to help teams understand what success criteria looked like from an overall deal perspective:

“What’s Required for Game Pass?”

• For Xbox players: Connect their Xbox profile to a Riot Account, download Riot apps via a link in the Game Pass app store, and gain access to exclusive in-game content unlocks when their linked Xbox profile has an active Game Pass membership
• For Riot players: Learn about the availability of account linking and Game Pass benefits through in-game client/app calls to action on desktop and quickly get to the account linking feature from the in-game client/app call to action.

“What else should players have?”

• “Game Pass members should have..”: An easy way to learn what content unlocked for them in each game; a clear sense of which content in their game is unlocked because of Game Pass; and timely awareness about how and when a change in their subscription status impacted their access to game content.
• Riot players with an Xbox profile should have: Clear communication about the data sharing agreement with Microsoft and a way to disconnect their Xbox accounts if they no longer want their data shared with Microsoft.

Scenario Breakdowns

Detailed look at each key end-to-end player scenario, including surfaces, player profiles, and success criteria

This was the bread and butter of the deck: how do we share the desired player impact, independent of UI, in a way that empowers each game team or app to explore the right solution to the problems identified based on their constraints and needs?

In its first iteration, the scenario breakdowns section merely re-packaged the content from the flows presented in Part 1 of this series. Each scenario included a complexity assessment, a list of affected surfaces, a player profile summary, and success criteria. These were initially framed with screenshots of the flows, but we intended to replace the flows with higher level story maps at a later date.

Example scenarios:

• Acquire Riot Game through Game Pass app (PC/Mobile)
• Connect Xbox profile via CTA in Riot Desktop Products

One of the initial scenario breakdowns from the first draft of the Xbox Game Pass Design deck. It’s functional, but it’s a little technical and doesn’t really bring the player journey over time to life. To see what a revised take on this scenario looked like later in the project, keep reading.

The accompanying flow for Scenario 1 as seen in the first version of the shared understanding Game Pass Design deck. Again, it’s functional and thorough — but with so many partners, people were having trouble pulling out the quick insights they needed. (This will look familiar to those who read Part 1!)

Surface Inventory

Reference for common naming and ownership

There were many “key” screens or states that multiple scenarios relied upon — having a central inventory of them reduced the risk that we accidentally duplicated that work. This was drawn from the surface inventory seen in the boards from Part 1. For developers working on front end implementation, this kind of thinking can be helpful, as it helps us avoid rebuilding similar things that should actually be identical. And for folks building business logic in the back end, it makes it easier to track down the many ways a player can get to that state across scenarios.

Player-focused storytelling as a shared vision

Life comes at you fast when you only have 5 months to ship an entirely new global gaming authentication and entitlement service. After the first release of this “Game Pass Design 2022” document, I had a game team lead quoting it back to me within 24 hours, which just goes to show how frequent our frequently asked questions truly were.

But as the initial circulation increased, something just didn’t feel right. I realized that the “scenarios” weren’t player focused enough. Sure, they mentioned players, and they even included hypothetical player quotes. But it wasn’t easy to scan the doc and get a sense of WHO our player segments were or what they needed, or how their journey evolved over time.

Why does this matter? Why isn’t it enough to just assume folks will figure it out, if the information was already there in some form?

Riot’s mission states we aspire to be the most player-focused game company in the world. One of the most effective ways to build shared agreement and alignment is to make sure players are truly front and center in any communication you’re building out. My initial drafts just didn’t meet that bar. This was going to be especially important because everyone on Game Pass was already working at high cognitive load and needed all the help they could get.

The back and forth around the document helped me and the team drive to a new form of clarity, by shining a light on the types of players we were serving and who we could address in the design document. Those segments:

1. Game Pass member without a Riot Account
2. Existing Riot Player with no linked Xbox profile
3. Riot + Xbox player without a Game Pass membership
4. Riot + Xbox player with a Game Pass membership

I added these four player segmentations to the deck and used them to overhaul the way I was presenting the key scenarios.

Player segmentations / roles for the Xbox Game Pass project from a Riot perspective. Each of these 4 categories yields a different experience of the program and its benefits.

On that note, as mentioned earlier, those complex flows we’d done in business development just weren’t cutting it in conveying what we wanted players to experience. So how to transcend that obstacle? I took the key beats from those flows and turned them into abstract timelines tied to key player or system objectives. These got color-coded with team ownership for good measure, just to show where the transitions would be taking place. It’s MUCH easier to scan this than the complex, “how the sausage is made” flows from the business development phase shown in Part 1. This improved storytelling format also really helped us bring the WHY of some of the scenarios to life.

A view of the overhauled Scenario 1 slide, which is now entirely from the player perspective as opposed to what was shown in the initial form of the deck. We capture what the player needs, key notes about functional adaptations, the player’s journey through time, and even manage to call out which teams own which stages of the experience.

Leading with Why

One particular struggle I faced early on: the minimum lovable product we’d proposed in business development was just that. A proposal. No game teams had agreed to implement features like in-game notifications.

When it came time to discuss the proposal with our very busy game teams who already had their roadmaps planned out, the initial response in most cases was a “no”. Why? We hadn’t really managed to tell the story of WHY we felt these features were “minimum lovable.”

After launching the player segments, I reworked all of the scenario cards to be player and time-focused, showing how each particular scenario touched different channel categories (like Platform vs Game) over time.

The revisions to the shared understanding deck allowed us to strip communications down to the key elements, and draw attention to key points. In the case of notifications, one of the biggest reasons I fought for in-game benefit gain and loss notifications was that membership state changed OUTSIDE of game. Players might not know or remember their membership lapsed — and then Riot is their first place where they encounter the diminished experience. Without proactive communication, at best it’s a frustrating experience where they have to remember to go to Microsoft to renew — and at worst, they believe it’s a Riot bug and waste time filing tickets we can’t fix for them.

Expressing the “why” of your asks really matters, especially when you’re working with resource-constrained partners. With the revisions to the way we expressed player need and opportunity, we were not only able to bring our game team partners onboard to implement the recommended notifications work, but several game teams ended up going above and beyond!

The “Benefit Loss” scenario depicted here was a key negotiation point between me on behalf of the central program design team and our game teams, who were very resource constrained. We really owed it to them to make it clear WHY we felt notifications about changes to the player’s detected membership state were necessary *in game* in order to get alignment on notification features. Pointing out that credit cards/memberships could expire out of our control leaving players confused was a big part of this journey.

As an aside, you’ll see that I’m using some Riot iconography in the deck. One of the lovely benefits of working at a game company with such strong artists and branding is that we have a ready made library of emotes and icons to use in our storytelling. I am a big proponent of using these visuals within a deck as visual anchors to help people differentiate items in a list, to help set the tone, or to make blocks of text more memorable. Even if you use the same icon in multiple unrelated decks (Heimerdinger here is a favorite of mine), it’s what they mean in the deck that matters. You can do this with any icon set — you don’t need to be a AAA game company to use a little bit of visual storytelling.

Meeting teams where they are

Design communication is often best treated as yet another UX engagement. Who are you trying to communicate with? What don’t they know yet? What are their needs and how are they motivated? So much communication out there fails because we just plop the information out without considering the audience and how the information will land.

Woven through this writeup, you’ll notice discussion of “channels” or the concept of “Game” vs “Platform”. This project was a rare breed, as it was a huge platform project that REQUIRED collaboration from every game team in a very short time frame. Normally, Player Platform’s game team collaborations are either driven by the game teams, or are tied to game team calendars. We didn’t have a lot of precedent for communicating outwardly how and what to build on such a tight turnaround.

The second wave of changes to the shared understanding deck that added player-focused storytelling and some FAQs really moved the needle on our player connection and understanding, and got many teams seeing the same success criteria. But it was harder to parse out exactly what was required of each team in each scenario.

Every game team was incredibly tight on resources, looking for clarity in order to ensure they were only spending resources on the issues most impactful to players. They didn’t have time to sort through thick documentation to figure out “what does this mean to US?”

Instead, I took the documentation to them, by adding a pair of sections tuned to the specific needs of Player Platform product teams and game product teams. An additional pair of sections added to the deck addressed this issue by covering the implementation needs for each scenario from the perspective of either the Player Platform team or the game teams. This tied technical discussion back to stated player goals, but allowed us to get specific about capabilities needed.

It was a game-changer to take the time to build thoughtful communications for game teams that communicated:

• The WHAT — Our shared vision from a player perspective, in the form of end-to-end scenarios
• The WHO — what player segment needed each scenario
• The WHY — the context that made each scenario relevant
• The PLAN — Who would be accountable for each part of each scenario (platform, game teams, or Microsoft)

This level of transparency completely changed the tone of our conversations with the game teams, who were just as resource-constrained as we were.

What shared success looks like

Once we’d successfully built that shared vision across Platform and game teams about the desired player experience, the game teams ended up going above and beyond for our players. In a remarkable turn of events, designers from multiple teams — League, TFT, and VALORANT — approached me as Xbox Game Pass Design Lead with an idea for an aggregated display of Game Pass benefits in game. I brought all of our game team design contacts together to talk about this new class of idea.

In one of the most productive 30-minute design meetings of my career, this fantastic group of designers landed on the Rewards Programs indicator and flyout pattern. I started out by providing some extra context about goals we should consider for a future-proof pattern — brand agnosticism to make sure our decisions worked if we ever moved to ship on consoles, for example. We talked through what circumstances would make this pattern most valuable, and what we’d need to make it consistent across games.

We divided the work across our teams:

• I took on working with Publishing on getting a name for the concept (we had a few ideas before we landed on Rewards Programs)
• Our Player Platform designers took on designing an icon for the concept of Rewards Programs to make available to all games. this was important in particular because if we ever ship on console, we can’t always display other console manufacturer logos cross-console), and also to platform and marketing surfaces.
• Game team designers on games that had multiple programs active (League of Legends, Teamfight Tactics, Valorant) coordinated to develop a consistent pattern for the actual UI.
• Games that did not support PC cafe programs (Wild Rift, Legends of Runeterra) adopted just the Rewards Program icons when indicating content unlocked by Xbox Game Pass membership.

The final design for the Rewards Program tray indicator is an icon that displays when a player has one or more Rewards Programs active. Interacting with the icon reveals a flyout that shows the sum total of unlocked benefits available to the player in the current game, while also providing context for the icon that is seen on unlocked content in the player’s inventory or catalog. The Rewards Program indicator stands for me as a great example of the best of Riot — designers, product, and engineering coming together to go above and beyond for players.

Major props to our game-side Game Pass UX designers Jordan Checkman (League), Scott Snyder (VALORANT), Anya Li (Teamfight Tactics), Morgan Romero (Wild Rift), and Dani Kruse (Legends of Runeterra) who drove the Game Pass UX for their games, coordinating with me and the central Player Platform team, and to our visual design partners Robert Ignasiak and Junho Kim who drove the creation of that first-of-its-kind cross-game iconography. Design collaboration at this scale across multiple teams in just a few weeks seemed impossible, but thanks to a great team turned out to exceed all expectations.

The final design for the Rewards Program tray indicator as shipped to players in League of Legends and Teamfight Tactics on PC. Interacting with the icon in the header yields a flyout that shows a list of currently active programs and the resulting total of rewards provided.

Wrangling Brand Concepts

When you think of brand standards, you probably think of colors, fonts, logos, and wording for key phrases. And that’s true, those are all important parts of brand standards — things that we definitely referenced in the design deck for the folks who needed it. When working with brands, there are the really obvious parts — like how you use a logo — and then there are often the less obvious brand standards and concepts, like how accounts or subscriptions are portrayed. Those bigger concepts were a big hurdle in our cross-team alignment. Luckily, the muscle memory built up by hundreds of team members coming to this deck for design reference also meant we could use this document to communicate brand standards.

In 2022, Riot Games hadn’t shipped any games on console, so partner brand compliance as expected by console platform owners like Microsoft was still new to many of our processes. I’ve learned the hard way from my time shipping console games that failure to adhere to publisher brand standards and concepts (down to the capitalization of words) can be a blocking issue when you’re trying to ship a game or service. This is one of the things that can be surprising later in your career — not all big companies have the same level of experience in all places, and you may be bringing specific experience and insight that is helpful to your new company’s growth trajectory.

Making sense of account linking

Xbox profiles are linked to a Microsoft account, but the Xbox profile is not created by default. You can’t have an Xbox profile without a Microsoft account, and you can’t have Game Pass without an Xbox profile. The terminology is very specific — there is no such thing as an “Xbox account.” And it was the Xbox profile that we were linking to players’ Riot Account, not the Microsoft account, so there were cases where we’d run into an error state if an Xbox profile didn’t yet exist for a player.

A slide from the shared understanding deck that covers standard terminology around our account linking and player membership status, with a simple visual depicting the relationship between corporate account entities.

This relationship was pretty subtle, and was stumping a lot of folks across the company, from product through engineering. There were also some evolving urban myths, like a belief that you’d need to log in with your Xbox profile to get the benefits (false — just linking the accounts was sufficient.) And to make matters more complex, the necessary language to describe these relationships to players accurately was extremely precise, down to capitalization of “Account” and “profile”.

The existence of this shared understanding deck meant I could create visual aids to help folks see this relationship and dispel a lot of potentially dangerous misunderstandings that could lead to bugs or incorrect player communications.

A “Frequently Asked Question” from the Game Pass Design deck — “Do Players HAVE to log in with an Xbox profile each time to get their Game Pass benefits?” The answer: No. But the slide covers the structure of a Riot Account in more detail to help folks understand that an Xbox profile is just one of many possible sign in methods available to players in a Riot Account.

Getting the word out on our offer terms

Our partnership was a first-of its kind project for Xbox Game Pass. Riot’s games (with the exclusion of Riot Forge titles) are free to play, so the traditional Game Pass model wouldn’t work. But what we were offering was also not the same thing as a Game Pass Perk — usually a permanent content grant to players. We were offering, essentially, rental of in-game content to Game Pass members while their membership was active. We were also providing this benefit to ALL Game Pass members, which caused a lot of internal confusion because Game Pass has separate Ultimate, PC, and Console tiers. We were able to use this deck to clear up myths about our benefits being limited to PC Game Pass, which helped prevent inaccurate outbound communications and engineering decisions.

How YOU can build shared understanding at scale

With the wisdom of time, we can now look back and assess the ways in which this approach helped us function during this high-speed, high-stakes, high-complexity project. We saw a few key benefits:

On smaller teams, shared understanding can be built with more traditional, collaborative approaches like Trello boards or hands-on workshops. If you’re looking to start building shared understanding in large group situations, however, it becomes an outbound communications challenge. Questions to build shared understanding at scale:

Who is your audience?

Understand who your documents are for.

• What disciplines?
• What levels of leadership?
• What regions? What business units?
• Internal, external, or both?
• How do they prefer to learn and communicate?

There’s no One Right Way to communicate, and often those needs change over time. If you read Part 1 of this series, you know that the flows I created in the business development part of the process were useful — until they weren’t. A large part of that was due to the expanded range of levels and disciplines coming to the project and reviewing the work.

A key decision you’ll have to make is the format and tool that you will use to drive shared understanding. Beware of choosing a tool that’s easy for you but hard for your audience. If you intend for a document to be a living document, a source of reference, you can’t afford for there to be extra friction.

Meet people where they are, and use common denominator tools for shared understanding at scale. Yes, this means Figma is generally a poor choice for cross-disciplinary communication at scale beyond visual designs. Even if some of your non-design partners use Figma, they’re potentially not using it regularly, or comfortably.

What goals are your audience members bringing to the table?

Don’t think about your goals when structuring the document. Ask yourself how the information you’re sharing will help your partners and audience achieve THEIR goals — and make this clear in your communications.

Partner goals might be tied to their career goals — a need to make sure we minimize legal risks, for example. They might be tied to team needs — a need to minimize new work due to understaffing. Or partners might be approaching you wondering if you can help them solve a specific problem. Rather than leading your deck with your org chart and feature list, why not meet that partner where they are and start with the problems THEY care about?

Who are your customers, guests, or players — and what are THEIR needs? Do your partners share this understanding?

Do you clearly understand who your customers are? Your partners may not have that understanding, especially in certain disciplines. Use some of your communications to make sure everyone understands who we’re designing for and what their needs are. Everyone on your project should be in clear agreement about the ultimate “why” of your work: the customer problems you’re solving, why you’re solving them, and what the intended change to the customer experience will be, even in the abstract.

What questions are you getting?

Questions can be an invaluable tool to identifying a path to shared understanding. When people ask you questions, they’re often telling you implicitly or explicitly about the mental model they’re using to process your work and your documents. Use those questions to guide your structural choices and answer your partner questions up front.

Tips to remember

• Don’t be too precious. Waiting a long time to launch with perfect information can do more harm than good. It’s OK to start with the basics and grow based on the questions and discussions that follow.
• Many people process information visually. If you can sprinkle some images and iconography in to break up the content and draw attention to repeating concepts, you’ll really increase comprehension.
• Make sure your document(s) are accessible. Pin them to Slack channels, link them in meeting notes, and when answering questions that are covered in the docs, also link people back to the docs so they know they can refer back there later.
• Use good document hygiene. Keep editor permissions locked if necessary, and use commenting to drive discussion to avoid accidental drift in the document.
• Monitor your documents and communications for drift. When misinformation starts spreading — check to see if your documents are stale. The downside to a living document is that stale information can make its way broadly across the org. For example, some of the illustrative screenshots in the deck started making their way into marketing materials. (You may also want to clearly label information that is for illustration only and is not intended for external use or reference.)

Closing Thoughts

Why was the “Xbox Game Pass Design 2022” document so critical to our shared success? While this journey talks about a shared understanding document, the act of creating and maintaining the shared understanding document was in itself a design exercise that forced discussions, revealed misalignment, and drove clarity. It was never just a document — it was an ongoing process.

From our retrospective in January, some illustrative feedback about the impact of this process:

• “Xbox Game Pass Design deck immensely helpful to cross-team (including game) and discipline alignment on brand, experience, and PoCs”
• “Design providing a descriptive deck to provide teams and partners was immensely helpful to create acceptance criteria and use cases”

If you were trained in design, you might have come to the conclusion at some point that your whole career was going to involve Figma deliverables and hands-on visuals. The fact is that there are many more ways that UX designers provide value, and it’s not always the traditional path to pixels. As professionals trained in gathering information from disparate sources, creating clarity through chaos, understanding the customer perspective, and communicating to stakeholders across disciplines, you may find that you can leverage your strengths to bring entire workgroups together in alignment. When I create a deck for communicating with others, that’s a design exercise too — what information am I sharing? What am I choosing not to share? How am I sharing it, from what perspective, and in what order? Those decisions really do make a big difference.

Creating clarity from ambiguity is a huge part of our design training, from active listening and affinity diagramming to information architecture and storytelling. We can also bring these skills to the table beyond screens for our teams at key moments when everyone is operating at max cognitive load. As you progress in your career, ask yourself how you can break beyond the boundaries of the screen and your Figma files to help clarify and communicate the “why” and “how” for your teams and partners. That rising tide will lift all ships.

But this kind of clarity isn’t limited to folks trained in design — anyone can learn from these techniques and use them. It’s just that this happens to evolve naturally from the training many designers receive during their career.

In Part 1 of #TheUnlock UX series, we discussed how design can show up during the business development phase of the product process, and here in Part 2 we covered the transition from pre-production to production by building shared understanding. In a future Part 3, we will explore how our UX and Visual Design teams learned to adapt our process in real time to cope with the timelines, scope, and risks inherent to this massive project. Until then — thanks for reading, and happy gaming!