Case Study
Candy Crush
Redesigning the main navigation of a legendary mobile game. Improving usability for players and flexibility for the product.
Redesigning the main navigation of a legendary mobile game. Improving usability for players and flexibility for the product.
The project was about redesigning the main navigation of the game to allow it for future growth and to improve usability.
Below there's a before and after comparison that summarises it all. There are more than twelve changes. See how many you can spot :D
It might look trivial at first glance. What's so special about moving a few buttons? Well, for a product that has been around for a decade, that has a massive fanbase of passionate players, and it's the most profitable product of a multinational company, nothing was trivial.
If you'd like to know my ways of working and my role in the process, grab something to drink and keep scrolling.
The game interface lacked basic design conventions and good practices that make a product easy to use. Multiple usability tests showed us how much users struggled and hesitated to navigate the game.
The gameplay should be the challenge, not the navigation.
The product was growing fast and the company had big plans, but the lack of structure on the interface became the bottleneck for growth.
I always carry a sketchbook with me to collect fragments of ideas, hoping one day the dots might connect.
Since I first joined the organization, I've noticed something was off in the main page structure, so I kept exploring it by myself and casually talking to my peers about it.
The interface was not yet an issue at this point, but it's interesting to look back and see that early sketches were close to where the final solution landed.
Once in a blue moon the organization promotes in-house hackathons, giving employees two working days to pursue any(!) wild idea, as long as it's Candy Crush related. Pretty cool, right?
I've started using these occasions to further explore my designs and using the presentation time at the end of these events to show the opportunities and potential I've explored. That made people see for the first time the issues the current version had, always leading to great discussions afterward.
By the end of that year, we had an offsite with the opportunity for employees to submit topics for discussions. I suggested the idea of a design workshop to discuss the navigation. It was one of the most voted topics.
People from all crafts showed up excited to be "designers for a day" and I walked them through design exercises.
As a result, it made people realize how deep some of the problems were, and gave everyone the chance to explore solutions of their own.
In the following year, the product and the company grew even more. Then what once was just annoyances really became a problem preventing scale.
When leadership decided that something had to be done and started assembling a team, I had a lot of content that could help, so I asked to be part of it and jumped right in, head first.
One of the first steps was to dive deeper into the information architecture. Stripping away the visuals was like doing an x-ray, allowing us to see the broken bones.
How elements are grouped is very important. The top got reserved for things players need to know but don't interact often. At the bottom, closer to the thumb, are parts that players interact with daily.
This project was not about innovation or disruption. It was about building on top of existing mental models that players have from using mobile devices as part of their lives.
The vision was to take the interface out of the way, making it feel natural, so players can focus on what's actually important: having fun playing.
Together with UX designers and researchers, we planned many testing sessions with players, and through prototypes that I created, we validated that our new navigation proposals were exponentially easier to use.
We've also tested the labels and icons, so they could clearly represent the content.
Final icons in the center, surrounded by some of the hundreds of sketches that I drew for research.
In a project with so many moving parts, it's important to not ship it all at once. Changes (even for the better and backed up by research) can backfire by overwhelming users.
I joined forces with the Product Manager to slice the project into chunks that would make sense for development, bring us closer to our goals over each sprint, and deliver a better experience to our users without disruptions.
Every phase had to be A/B tested with rigor.
The work doesn't end when you ship it. We also had to align internally and communicate the vision and the reasoning to the wider group.
I wrote extensive design documentation covering all aspects of the new direction.
Every feature team wants more exposure for what they are working on, but not every feature can be an item in this bottom navigation. The documentation has a crucial role in explaining and guiding these decisions. It helped to spread design knowledge across teams.
The interface ultimately reflects the product strategy, and both leadership and product teams have to be aware of how to work in this shared space.
Whoa! You've made it all the way here. I hope you had a good time reading this case.
As you can imagine, this project was only possible because of an incredible team with a Product Manager, Agile Coach, Data Analysts, UX Designers, Researchers, Design Leaders, Art Directors, and a stellar group of Developers, from whom I learned SO MUCH!
Everything I wrote here is just what I did in this project, but each person involved would be able to tell you much more.
Thank you very much for your time. If you still have a little bit of time, I'd like to invite you to visit some other projects, or even my Playground section where you can mindlessly scroll through colorful pictures :D
