Skip to content
Jessica Fleur

Case study · Ultimate Sackboy

Onboarding First-Time Players

Planned the onboarding runs, then tracked 617,021 players through them to find the friction.

The game

Ultimate Sackboy is an endless runner built by Exient around Sackboy, PlayStation’s knitted hero, on iOS and Android.

Role
UX Designer
Date
March 2022 – March 2023
Skills
  • Competitor Research
  • Wireframing & Prototyping
  • Visual Communication
  • Analytics
  • Collaboration
  • Critical Thinking
  • Documentation
Tools
  • Adobe XD
  • Figma
  • FigJam
  • Adobe Photoshop
  • Unity
  • Confluence
  • In-house localisation software

The challenge

The running teaches itself. Swipe, jump, slide, and about ten seconds in you’ve got it. Everything else didn’t: a wardrobe, upgrades, bubbles and multipliers, missions, a marathon, a season pass, a trophy ladder and a daily duel against another player. All of it had to reach a new player before they decided the game was only running.

01

What Other Runners Teach You First

I pulled apart the onboarding in six games: Talking Tom Gold Run, Talking Tom Hero, Blades of Brim, Bowling Crew, Clash Royale and Tennis Clash, recording what each one taught, when, and how. Every one of them had a way to stop a new player failing a lesson, by pausing until the right input arrived, slowing time until it did, or letting the crash happen and rewinding it.

Navigation, obstacles, reward and pacing, compared game by game
One runner’s swipe tutorial, slowing the game down until the player makes the move

Spacing was the one I took most from. Clash Royale teaches across five practice matches, adding one thing at a time and never moving on until the last one’s been used. Tennis Clash does the same with upgrades and serving. That’s the rule I designed to.

02

One Thing at a Time, Across Eight Runs

I started with a grid of every feature the game would eventually ask a player to understand: when to teach it, how, and a priority from 0 to 3, where 0 was critical and 3 meant it was fine if the player never worked it out. I wrote the why in the player’s own voice, as “I need to collect bubbles to fill my multiplier”, so every lesson had to justify itself as something the player wanted. A narrative wrapper column turned the list back into a story about Sackboy trying to become the best runner of the lot.

Every feature, with the reason to learn it written in the player’s voice
Rewards, equipping and fruit, each with its teaching method

Then I sequenced it in FigJam across eight runs, through rounds of feedback with the Lead Designer, before another UX designer and I built it into the full user journey flow. Runs 1 and 2 are the forced tutorial, and after that the forcing tapers: by Run 4 the player can equip an item, check missions, buy the season pass, open a lootbag, or just run again.

Forced, not forced, and the gaps in between marked as free play

The coach’s tapping finger only appears two seconds after the screen it sits on, and the navigation arrows only appear if the player hasn’t already read the obstacle themselves. Crashing during the tutorial doesn’t end the run: Sackboy comes back through a portal at the same spot, and free continues carry on until the Marathon unlocks.

The full journey, run by run, down to how many taps each sequence costs
03

From Wireframe to Build

I wireframed every sequence in Adobe XD and wrote each one up as a step-by-step spec covering what appears, after how long, what’s forced, and where the player lands next. That went to Art, Design, Code and QA, and came back with changes every round.

Introducing Missions and the Marathon, upsell included
The progression map, specified down to which checkpoint the bar fills to

We built it into a clickable prototype so people could walk the sequence instead of reading it, since a tutorial is mostly timing. Art produced the UI assets and their own supporting document, down to the states of the username field, where DONE stays greyed out until the name is between three and twelve characters. I stayed with Art and Code through implementation until what was on screen matched what I’d specified.

Art’s UI supporting document: the username popup, state by state
The prototype, built to test the timing
And the same sequence in the shipped game
04

What 617,021 Players Did With It

I defined the analytics events alongside the analysts and tagged them by priority, then we watched the funnel through soft launch and past hard launch. Between February and July 2023, 617,021 players went through it.

99% started, 91% pressed the run button, 82% finished their first run and won it. 74% started Run 2, 65% reached the missions and marathon sequence, 60% started entering a name, 54% finished Run 3. By Run 5 it was 41%, by Run 6 36%. The decline was steady the whole way down, with no single step that players fell out of.

Every event I defined, across 617,021 players, from first boot to the Daily Duel
The high-priority events alone: 99% at the first step, 25% by the Daily Duel

We also split the same events by first hour, first day and third day. The day-three line sits about three points above the first-hour line early on and eight or nine by the end: 15% of players had won a Daily Duel within an hour, 22% within three days. Most of those missing from the first-hour funnel came back and finished later.

First hour, first day, third day: the day-three line runs highest all the way down

The platform split surprised me. Android brought 455,300 players to iOS’s 161,721, nearly three to one, but iOS completed more of the funnel at almost every step and finished on 31% against Android’s 22%.

iOS brought a third of the players and stayed a few points ahead at almost every step

One step did drop sharply. 34% of players saw the coach unlock the Daily Duel and 25% started one, a nine-point fall where the steps either side cost one or two. It’s the last thing the onboarding forces, and the first that asks a player to compete against a stranger. If I did it again I’d let the sequence fire once the player had gone into the Daily Duel on their own.