Riot Games · 2019 · Case study · 6 min
Riot's recruiting process was changing weekly and the documentation lived in Drive, email and people's heads. I was a recruiter who had been asking to do design work. This was the first product I designed: a hub that made asking around unnecessary.
Interviews
116 recruiters, 4 hiring managers, 1 coordinator, with card sorts
Journey
5 stagesmapped from opening a role to onboarding, with the pain named
Audiences
3recruiters, hiring managers, interviewers; the hub is organised by them
Outcome
Handed offdesigns and CMS structure delivered; I moved to London before launch
If you only read one section: the journey map the world what was broken how I found out who it was for what I built what happened
01 · The world
Riot makes League of Legends and is ambitious about everything around it: new games, TV, music, a campaign to get esports into the Olympics. In 2019 that ambition turned inward. The company was publicly reshaping its culture, and much of the attention landed on how it hired.
Change generates documentation. The IT Apps team had a proof of concept for a knowledge hub that could hold it, but no capacity to design the recruiting version for months. I was a recruiter who kept asking to do UI work. I volunteered.
The advantage of designing for your own team is that you already know where the bodies are buried. The risk is that they are your friends.
Both of those show up later.
02 · What was broken
With no CMS and the process changing constantly, asking someone was faster and more trustworthy than searching. So the most experienced people spent their days answering the same questions.
03 · How I found out
Four questions drove discovery: who is this for, what must be in it, what must stay out, and how should it be structured. The inventory answered the middle two; the interviews answered the rest.
Every recruiting document, email and deck I could find, logged against one schema. It gave me the volume, the hierarchy, and the list of things that couldn't move because they were confidential to a role.
Eleven Rioters across tenures and disciplines: engineering, creative, corporate.
04 · The journey
I sketched the recruiting process as five stages and used it to structure every interview. The map below is what came back: what worked, what hurt, how people felt, and what a hub could plausibly fix. Where the curve dips is where the hub earns its keep.
Two of the five stages were fine. That was useful: the hub didn't need to be everything, it needed to be the answer at stages one, three and four.
Rebuilt from the original journey map; wording lightly condensed.
05 · Who it was for
Recruiters, hiring managers and interviewers made up the bulk of the process, and they wanted different things from the same content. That difference became the primary navigation.
"I need up-to-date info so I can guide candidates and hiring managers."
So: a Latest Updates feed on the home page, and a comments thread on every article.
"I need comprehensive guides, news, and ways of discussing changes."
So: an audience page for HMs with the "why" alongside the "what".
"I need resources to conduct and document interviews effectively."
So: kits and team pages one click from the interviewer landing, plus a per-audience FAQ.
06 · What I built
The hub was information-rich, so the architecture came before any screen: how inventory items related to each other and to their audiences. Then wireframes, testing with each audience, and feedback from the intranet team, who told me what Confluence would refuse to do.
Confluence wouldn't allow it. The category grid on the home page and the audience pages had to do the wayfinding instead.
Results were standardised across the whole intranet, so the hub couldn't rely on search to rescue a weak structure. The structure had to be strong.
Nobody listed the constraints up front. I had to design something the system couldn't do to find out where the edges were, then design inside them.
Usability testing
Grey-box wireframes tested with each audience and reviewed with the intranet team. Two rounds of changes to the home and audience pages, mostly about what came first.
The card sort showed people grouped by "who am I" before "what is this". Four tiles at the top mirror that.
The process changed weekly; the hub had to show that it knew. A feed of changes is how a static hub earns trust over asking a person.
Both recruiters and HMs said they had no way to discuss a change except giant Slack groups. Discussion attached to the document is the fix.
The questions senior Rioters answered every day, written down once, where each audience lands.
07 · What happened
I worked with recruiting leaders on a structure for accumulating content in the CMS and got the designs ready for developers. A few months later I left Riot for London, so I never saw it implemented. I'd rather say that plainly than dress it up.
Status
Handed offDesigns, IA and a CMS content structure delivered to the IT Apps team and recruiting leadership. No launch metrics exist, because I wasn't there for the launch.
What did get done
with audience and confidentiality on every item, which the CMS structure inherited.
The journey map became the artefact recruiting leaders used to talk about the process, independent of the hub.
validated in two rounds of testing and accepted by the intranet team within Confluence's limits.
This is the project that moved me from recruiting into product design.
Interviewing people I was close to was a double-edged sword.
They were more candid about their frustrations, and more cautious about criticising my design. Now I separate the two conversations, and I get a stranger to run the second one.
Technical constraints weren't spelled out. I found them by breaking things.
Designing something the system couldn't do was the fastest way to learn where the edges were. I still do this, but I now ask for the list first.
08 · Differently
I'd have defined success before I left. Even a proxy, like "questions asked in the recruiting Slack channel per week," would have given whoever launched it a number to watch. The behaviour the hub was meant to change was asking a person, and that is countable.
I'd have shipped the Latest Updates feed alone, first, inside the existing intranet. It was the smallest thing that could make the hub more trustworthy than a colleague, and it didn't need the architecture to be finished.
And I'd have asked the intranet team for the constraints list on day one, instead of discovering the no-left-nav rule with a finished wireframe in my hand.
Sections 07 (the "what did get done" list) and 08 are drafts in Ruth's voice to confirm or rewrite. Journey map and personas are rebuilt as live HTML from the originals; screens are from the original case study.