Case study · Ultimate Sackboy
Redesigning the Wardrobe
Rebuilt the wardrobe to handle full costumes as well as single items, specified for Art, Code and QA.
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
- June 2021 – January 2022
- Skills
- Competitor Research
- Wireframing & Prototyping
- Visual Communication
- Collaboration
- Critical Thinking
- Documentation
- Tools
- Adobe XD
- Adobe Photoshop
- Unity
- Confluence
- In-house localisation software
The challenge
The wardrobe was built for single items. Then we added costumes, and the same hat had to work two ways: something you wear on its own, and one piece of a set you’re partway through collecting. The old screens had no way to show the second one. I redesigned it to handle both, and wrote it up for the four disciplines who had to build it.
The Wardrobe We Had
The wardrobe already worked for single items. Sackboy stood at the top of the screen in whatever you had on, with three outfit slots under him and a card for each of the eight categories. Tapping a category listed every item of that type, split into ‘Owned’ and ‘Locked’. There was nowhere in that to put a costume.
I looked at Clash Royale and Tennis Clash first, for the way their card screens group owned, upgradable and locked by rarity and unlock tier. Then Sackboy: A Big Adventure, the PlayStation game the IP came from, which already had costume slots and category tabs.
I settled on four category buttons, ‘Costumes’ plus three item categories, with a sub-category bar that changes depending on which one you pick. Costumes are grouped into ‘Complete’, ‘In Progress’ and ‘To Be Found’; items into ‘Owned’ and ‘To Be Found’. Tapping an owned item puts it on Sackboy next to the rest of what you’re wearing.
Working Out the Card States
A card has to show four things at once: whether the item’s equipped, whether you’ve got enough copies to upgrade it, whether it’s part of a costume, and whether you’ve unlocked a style variant for it. Those combine into a lot of states, so I drew all of them out, for costume cards, item cards in a category, and item cards inside a costume, in both their static and tapped versions.
The costume states had to work from both directions. In the Costumes category, a Complete costume gets ‘View Items’ and ‘Equip All’; an In Progress one only gets ‘View Items’, since there’s nothing whole to equip. Going the other way, an owned item that’s part of a costume gets ‘View Costume’, which takes you to that costume with the rest of its pieces listed.
‘To Be Found’ items don’t preview on Sackboy, since that would spoil an item you haven’t earned yet. Tapping one brings up a translucent popup telling you which bags it drops from, so the tap still does something.
What an Upgrade Gets You
Upgrading already existed, but nothing on screen said what it was for. Levelling an item raises your Power Level, and Power Level raises the value of the bubbles you collect on a run: a Common bubble goes from 100 to 101, a Legendary from 1,000 to 1,010. I rebuilt the upgrade popup around that and added an information icon that opens a screen listing all three benefits: bubble value, Power Level, and the style variants that unlock at certain levels. I also specified what happens when you’re short of coins and can make up the difference in gems.
The confirmation needed the same work. An upgrade can raise your Power Level on its own, or raise it and unlock a new style at the same time, and the second case needed its own ‘New Style Unlocked’ screen rather than being folded into the first. I storyboarded both at six steps each.
I also designed the call to action for new and upgradable items, on the cards and on the Wardrobe tab in the navigation bar.
Writing It Up for Four Disciplines
Once the screens were settled I mapped every path as a user flow: main menu through both categories, upgrade, equip, reward confirmation, plus the edge cases. Not enough duplicates, not enough coins, going into a costume from an item and back out. It turned up gaps I’d missed, and I went back and redrew a few screens.
Then I wrote the design document for Art, Design, Code and QA, with every flow and what each discipline needed from it. My Lead Designer reviewed it first, then the full stakeholder group, and that round changed both the flow and the document. I stayed with Art, UI and Code through implementation to keep the build matching the document, and tested it with QA as it came together.
I never got analytics on this one, but the reviews called the wardrobe easy to navigate. That was what I was aiming for, given how much it had just taken on.
Four facts on one small card is easy to get wrong. Drawing every state was the only way to see which combinations failed. That sheet outlived the design: it answered the user flow, the document, and most of the questions that came up during the build.