Taking on Team Builder — Part 3
Designing for Real-Time Social Interaction and Sportsmanship
In Part 1 of this series, I talked about the problems we were trying to solve with Team Builder, the goals of the feature, the UX design process, what we learned from early explorations, and our initial design principles.
In Part 2, we looked at how we put the design principles for Team Builder into action with specific design tactics.
In Part 3, I’d like to finish the series with a few embarrassing moments plus a design technique that I developed from working on this project to help solve complicated interaction problems.
Solving complex scenarios with multi-perspective prototypes (or “How to irk developers with parallel wire-flows”)
To ensure that every player always had what they needed in Team Builder, our team had to know what every player would be experiencing at any given moment. This was a real UX challenge.
I initially tried using parallel wire-flows, which showed the experience of three players on a timeline, similar to storyboards:
A word of advice: DO NOT USE PARALLEL WIRE-FLOWS!
Engineers on the team seemed to hate them and I definitely hated creating them. We needed a better way.
So I developed a simple technique that I call multi-perspective prototyping (or MPP, for short).
This particular MPP shows what the experience of a captain quitting could look like for three different players:
Each “screen” represents the view of an individual player. Actions and reactions on one screen are reflected on the others. Lightweight, fast, and easy to iterate on.
My first design pass at Team Builder
I’d like to preface this by reiterating that my preferred design approach is to try everything. I sometimes get a little crazy.
This is a little crazy:
This design is crazy because it’s a crazy mess with no clear priority or flow. Makes me angry just looking at it, and anger is obviously not the emotion we were going for. It also conflicts with a few of our design principles:
- Five maps are distracting and redundant (design for repeated use, be succinct).
- Annoying on first use, not to mention repeatedly (design for repeated use).
- No obvious path and no clear first action (give players an obvious path).
- Requires a lot of instruction to make useable (keep instruction to a minimum).
Testing fun
We tested the hell out of Team Builder. We tested with Rioters, players, and gamers who’d never played League or a game like it. We even surveyed our own team.
Naturally, we took our share of bruises along the way, especially in the lab. These are a few of my personal favorites:
No one can pick a champion
You can’t play League without picking a champion, but on our first day of testing none of the testers could tell that they were supposed to pick a champ or even how. We knew you had to push the big, beveled button, but apparently this wasn’t obvious to new users.
We solved this by adding a redundant button that said something to the effect of “Select Your Champion.” After this, players seem to figure out that the icon was also a button.
Takeaways: The most obvious action may not be obvious to all. Redundancy can be a good thing.
A popup message nearly kills the test
Team Builder had a technical constraint that required a player’s settings to be locked once they began searching for solo players. We were concerned that locked settings wouldn’t be obvious.
One solution we tried was a popup message that indicated the settings would be locked after a countdown timer ran out. Some players never noticed the pop-up. One player who did notice it freaked out so badly that he nearly closed every program on the computer to find out where the message went. He got as far as the test recording software before we stopped him.
What solved the problem was more embarrassing: Nothing. Absolutely nothing. We removed all messaging and allowed players to take the action without any indication of what would happen. Testers understood immediately that their settings had been locked and why.
Takeaways: Don’t solve problems that you don’t have. Clever solutions can be dangerous.
Results of a new UI survey
This one wasn’t embarrassing; quite the opposite. While the user interface of Champ Select had been rated a 1.5 out of 5 by players, the UI of Team Builder was rated a 4.2. I really couldn’t have hoped for a greater outcome. In my opinion, this was a testament to the relentless iteration I was so fortunate to have been given space for.
Conclusion
After many months of diligent design and development, Team Builder entered the world looking like this:
Team Builder was generally well-received and this meant the world to us. I literally cried into my beer as the feature went live around the world. I still tear up whenever I see the promotional video (I just watched it and, yes, I just did again).
Though Team Builder is gone (a topic beyond the scope of this series) and I’ve long since left the Player Behavior team, my hope is that the feature can live on through the lessons that it taught us.
I humbly dedicate this to all the players who enjoyed Team Builder and to the Rioters who helped bring it to life.
Your champ. Your role. Your team.
And my honor.
