UX Superpowers Applied in Early Stage R&D Games
I’ve had the good fortune to work on teams — both inside and outside the games industry — that value the user experience craft throughout the development cycle. As UX designers, we’re empowered to make contributions at every stage of development and assist teams that are either iterating on released games, like League of Legends, or are exploring new IP and experiences for players in R&D.
The role of UX in game development is probably less defined, or understood, than it is in industries that have already incorporated established UX methodologies. Even defining UX within the games industry is fuzzy depending on how established it is within the company.
Many of you may work in organizations where your peers assume a UX designer fulfills a very production-centric role, in which you design the final UI assets for a product and focus on execution-centric responsibilities. While those are important, there are many ways a UX designer can influence a project’s direction before crafting the first wireframe or checking the first button asset in to Github.
With this article, I hope to share my experiences applying my UX background while working with an R&D game development team during its early stages. This phase is called anything from discovery, to ideation, to exploration, but I’ll use a term borrowed from information research: sense-making.
Sense-making focuses a team’s energy around understanding and definition. What opportunities exist? What are we trying to solve? Who is the audience? What are they motivated — or demotivated — by? How are competitors approaching the opportunity space? And so on…
Ultimately, the team is trying to identify “big bets” and develop a plan for how they “win” in the areas they’re betting on. Sense-making is a particularly chaotic and ambiguous phase of game development, but I know that UX designers have the ability to thrive during it by helping teams achieve clarity and focus. Let’s walk through some of my experiences on the team that highlight how I was able to make a positive impact.
Embracing Design Agility
Teams at Riot that are sense-making are typically smaller and structured in a way that allows them to move fast, fail fast, and course-correct quickly with minimum disruption or approval on a day-to-day basis. From an operational standpoint, keeping an R&D team small and self-contained for as long as possible staves off communication burdens that arise as teams grow.
Basically, R&D teams in earlier phases of development should value members who have diverse skillets or the potential to “stretch” and assume roles that land outside of their job title or core expertise. You want people that can wear multiple hats or pinch hit if needed so teams don’t grow too quickly. Hiring a super-talented specialist in the hopes they’ll fill a future need is an especially challenging situation. Unless that person is able to direct their energy towards another area or is able to fill an emergent need, they tend to leave a team no matter how cool the project is.
Relating this to my own experiences, my expected role initially didn’t align cleanly to the team’s stage of development. After a few months on the team, I realized I could be more useful — and more fulfilled in my day-to-day work — by embracing different roles and identifying opportunities that leveraged my experience and UX skills without explicitly trying to fulfill expectations of what the title of “Experience Design Lead” implied. Being flexible with my role and opportunistic when applying user-centered design methodologies embodies what I’ve termed as design agility.
I’ve assumed many roles since joining my team: product owner, design lead, UX manager, UI designer, and delivery lead. And, yes, at certain points I was actually building assets and checking them in to daily builds that powered our playtests. The team needed someone to fill a role, and I felt like there was an opportunity for me to contribute. Anything that helped the team feel more confident about the big bets we were making was fair game. Being flexible with my role went a long way towards feeling like I was helping the team make progress, even if I wasn’t managing a large UX team engaged in multiple projects.
Clarifying Our Audience
As part of a user-centric design process, UX designers need a good understanding of our target audience. Over time, we also find ourselves developing an instinct to leverage existing tools and frameworks to fit a particular situation or need. While my team initially had plenty of domain expertise and could instinctively identify player pain points in relevant games, much of it was based on personal experiences or biases.
Working closely with the team, I came up with a rapid method to develop and present quick sketches of our audience, or proto-personas, as we named them. Although these were not as heavily researched or validated as is typically done with traditional personas, we were in the enviable position of having a number of in-house domain experts in our particular genre of game. I was able to help translate their personal descriptions of the existing community into motivational archetypes — sharp articulations of our audience with respect to their desires and goals.
In addition to articulating player motivations, we provided real-world examples of community members who could fit that particular proto-persona, ideal outcomes (what good looks like), and outputs (“features” that would support an outcome) to further illustrate these archetypes. Together, these formed the structure of our proto-personas.
Developing and aligning the team around these proto-personas gave us a tool to clearly visualize our audience without being self-referential and removing personal bias. We also realized that we spent a lot of time brainstorming feature ideas (i.e. outputs) before understanding what good outcomes would look like for a particular persona, leading to unnecessary churn.
As a team, we moved away from using language like:
“I would find feature ‘Foo’ useful if it did a, b, and c.”
To:
“Feature ‘Foo’ enables this outcome which resonates with both Persona 1’s and Persona 2’s motivations.”
We ended up with a consistent way to speak about our potential audience and an objective way to evaluate emergent ideas during sense-making. Over the past year the proto-personas have remained durable and continue to be part of our vocabulary on the team.
Clarifying Key Relationships
Understanding social interactions between players is an important part of developing a healthy online community, and it is key that players understand the role they play. The proto-persona exercise revealed that the community at large was diverse, not only from a motivational perspective, but also from the kinds of interactions they expected to have with each other. We then wondered if there were specific aspects of these relationships that we could identify so as to support our player base.
I proposed identifying various relationships in the community and defining the motivations and attributes of each with the intent of creating relationship personas. They served the same purpose as proto-personas, but for defining groups of players as opposed to individuals — like a temporary alliance of players. Motivations and outcomes would then be articulated in terms of benefits to the group.
After several rounds of exploration, we whittled down the relationship personas to a handful, and identified outcomes that were shared across multiple relationship personas.
These were then used as a foundation for the team to brainstorm ideas. Using a page from Google Venture’s Design Sprint playbook, I ran several team workshops to develop 3-panel sketches of ideas that could support the relevant outcomes. That format allowed the team to better articulate an idea than say, a single idea scribbled on a sticky note.
In the end, we generated a large number of feature ideas aligned to outcomes that supported the key relationships we wanted to nurture in our community. A nice side effect of this exercise was the participation of the greater team and the feeling that everyone was able to champion an idea they felt strongly about, even if their day-to-day responsibilities fell outside of design activities.
Wrapping Up
Ultimately being flexible with my role — combined with Macgyver-ing various UX tools to work for a specific situation — allowed me to spot gaps and identify opportunities to add clarity where ambiguity previously existed.
Hopefully this gave you a bit of insight into the contributions UX designers make at Riot, specifically on early-stage R&D teams. Beyond the core skill sets of interaction design and storytelling abilities, there are design processes that can be applied and flexed to tackle different problems. Having a mindset that embraces design agility goes a long way towards finding success as a UX designer at this conceptual stage
I’m also secretly hoping that this article gets read by people who work alongside UX designers, like software engineers, product managers, or game designers — and that they walk away with a better sense of how we can help their teams in ways that may not be initially obvious. If this is you, don’t be afraid to reach out to your friendly neighborhood UX designer. Their superpowers are charged and ready to go!
