Taking on Team Builder — Part 1
Designing for Real-Time Social Interaction and Sportsmanship
This is the first part of a three part series we’re doing to peek behind the curtain on how we design and implement systems at Riot Games. Below, we do a deep dive on the release of our 2014 Team Builder feature. Next Thursday (6/15) and the Thursday after that we’ll be dropping Part 2 and 3.
My name is Weszt Hart and I’m a UX designer at Riot Games. One of the things I love most about working in video games is the opportunity to solve really complicated, sometimes intimidating UX design problems. The scarier the better.
At Riot many of the scariest UX problems I’ve worked on involved social systems, toxic behavior, or multi-player interactions that happen in real-time.
Team Builder, a mode introduced to League of Legends in 2014, had all three.
Incredibly scary and hugely rewarding, Team Builder taught me a lot about designing for sportsmanship and real-time social interaction.
In this series, I’d like to share what I learned.
Problems and goals
League of Legends was not originally designed with explicit team roles and positions in mind, and that had become a big problem for many players. These roles and positions became defined as League evolved, but now players didn’t have a way to specify their preferences when setting up a new game.
To get the position they wanted, some players were resorting to confrontational methods which led to angry teammates playing angry games — aka the “mid or feed” effect. Angry games led to reports of toxic behavior which led to player suspensions or players churning out of the game entirely.
Complicating matters was the interface of the Champ Select screen, where players chose how they wanted to play and was the place where the rage often began:
Players rated this UI a 1.5 out of 5. Abysmal. The interface was too cramped and unintuitive to simply stick in a couple of role/position selectors. We needed to do something completely from scratch and it had to be much better.
Ultimately our team decided to create an entirely new game mode with a fresh interface. This mode would be developed with two clear goals in mind:
- Empower our players with more control over their experiences
- Promote team chemistry and satisfying team compositions
Design process
My design process had roughly three phases: exploration, rapid iteration, and crafting.
This process fit nicely with Agile, the preferred development method of the Player Behavior team. I worked hard to keep UX design as far ahead of development as possible, usually by at least a couple sprints. Anything I designed was reviewed individually and then collectively by team members who were quick to provide feedback. Morning standups provided a reliable time to discuss new design work.
I designed mostly in prototypes, which made it possible for the team to test as we went along. Many ideas went through hundreds of small cycles as we refined them.
The prototypes became increasingly more detailed and soon outpaced any efforts to capture the details in annotated wireframes. In the end, the Team Builder prototypes served as a much better reference for the team than any traditional forms of specification we tried.
Exploration phase
My preferred design approach is to try everything and let the ideas fight it out. On Team Builder, I took this approach to the limit by exploring every idea our team had.
One of the earliest ideas was an interactive map. A big version of the mini-map could be fun, right?
Well, it wasn’t. Annoying actually. You’d constantly have to open and close things that cover up other things, and everything might move around. Learning to use it would be a pain.
Then we tried a phased process:
Nope, this didn’t work either. Step-by-step processes like this put the system in control, not the user, which didn’t feel very empowering. Imagine having to set up a bank account every game, every day. Who wants to do that?
When the team saw this next design, however, we knew we were getting closer:
This was more intuitive, familiar, and clean. You can already see a vague resemblance to the final design:
Early findings
Our early explorations and research taught us a lot:
- Players should dictate the pace, not the system
- Team Builder might be used frequently so it would have to feel good over and over again
- UI had to be much more intuitive than current Champ Select
Between these learnings and our goals, we developed some initial design principles:
- Let the player control the flow
- Design for repeated use
- Give players an obvious path
- Keep instruction to a minimum
- Be succinct
- Avoid interruptions and distractions
Other principles would be added later, but we had enough understanding and vision to move out of the exploration phase and into higher-fidelity design and rapid iteration.
