How to Build a Case for a Product Redesign

The story of redesigning Fabric Crashlytics in Firebase

I recently had the opportunity to redesign Crashlytics, a crash reporting tool that helps mobile app developers understand why their apps are crashing. (Have you ever had an app crash on you? Crashlytics helps developers fix that.)

My team joined Firebase at Google in January 2017 as part of the Fabric acquisition. One of the goals of the acquisition was to bring Crashlytics to Firebase. This meant redesigning and rebuilding our product into Firebase, which uses Material Design and has a very different visual design system.

Since we needed to do a visual design update of Crashlytics, I decided it was a great opportunity to rethink the entire user experience, rather than just port over the features as is. Crashlytics is a well-beloved product but had accrued a lot of design debt since its creation in 2011. We heard from many users that they had difficulty using features or couldn’t find a feature we already had. It was also getting difficult for our team to know where to put new features because the product didn’t have a clear information hierarchy — for ourselves and our users. It was time for a redesign.

But first, I needed to build my case.

One does not simply start redesigning a product. It takes time to understand users, how they use your product, and the problems they have. It’s critical to get all these insights before embarking on the redesign itself to ensure that the team is solving the right problems and aligned on the project goals.

Step 1: Understand your users

I started by gathering information. I talked to Crashlytics teammates who’d worked on the product for many years, our developer relations team, user researchers, and of course, our users. I needed to understand why and how people use Crashlytics before I could figure out how to improve their user experience.

Luckily Jason St. Pierre, my product manager, had worked on Crashlytics for over 5 years and talked to users often, so he had a deep understanding of how a range of people use Crashlytics. He identified the 4 most critical Crashlytics user journeys:

1. Monitoring the stability of a newly released app version
2. Checking on app stability
3. Prioritizing which crashes to fix
4. Debugging a customer problem

I mapped out each of those user journeys into flows using personas, which revealed a consistent micro-journey between all 4 journeys: the “investigate and fix” flow. I shared these journeys with the team and revised the flows as needed. These flows aligned the Crashlytics team on a shared, foundational understanding of how users use our product.

Step 2: Understand their pain points

Once we were aligned on how people use our product, we needed to understand their pain points with the existing UX. The Crashlytics team is extremely collaborative and all of us are invested in building a great experience for our users. I wanted a way to involve them in the redesign process that was more collaborative than me sharing concepts and getting their feedback. The team also had a lot of valuable context on the product that would be useful to leverage for the redesign, as many of them have been working on the product for years.

Many people on the Crashlytics team mentioned various aspects of the dashboard needed improvements. To leverage their knowledge, I decided to conduct a series of internal user studies. My goal was to understand what the biggest pain points in the user experience were—based on what we’d heard from customers over the years.

I printed and cut out the Crashlytics dashboard and set up individual sessions with teammates where I asked them to rearrange the pieces and redesign the dashboard, talking out loud to explain their thinking.

This was tremendously useful. Not only was it fun (how often do digital designers get to play with real paper nowadays?), I was able to see what each person identified as pain points without them being biased by anyone else. This made it easier for me to identify recurring themes. For example, every single person focused on improving filters and improving the information hierarchy. I also learned from the developer relations team which features were difficult to use and find.

I shared these learnings back to the team in an ongoing deck that catalogued the redesign effort. I also set up weekly design check-ins with the team to share design updates and bring them along the redesign journey.

Step 3: Define the user problems

After understanding our users’ goals and pain points, the user problems became a lot clearer. I took all my learnings from the paper cutout sessions and conversations with users and the team, then narrowed in on our primary user problems:

Problem 1: Users found it difficult to get to the information they really cared about

The first thing most users did on our dashboard was scroll down. The information they were looking for was further down the page or required multiple clicks to get to. It was buried behind less important features.

Problem 2: Users didn’t know features existed

I once had a user ask me about adding in a feature to log what happened in the app leading up to a crash. This feature already existed in our dashboard — it was just buried in the UI. Our support team heard many similar cases from users as well. This problem was also reflective of the problem our own team faced: difficulty knowing where to put features.

The overarching theme that emerged was that our product’s information hierarchy was unclear, which I pitched to stakeholders as the primary problem we should solve. Since they had been part of the design process the entire time, it was easy to align and get buy-in.

How it all worked out

The team officially bought-in to the need for a redesign. They understood the problems users had and agreed on which parts of the user experience needed improvements. Success! The next steps were to actually redesign the dashboard, which happened over the next few months through lots of brainstorming, collaborating, check-ins, and user testing.

Building a case for a redesign involves a ton of context setting. It may be clear to you as a designer that a product needs a redesign, but one cannot go far alone. A product redesign is a team effort, and it’s important for the team to align on why a redesign is necessary. It’s also impossible to redesign something if you don’t understand how it’s currently used.

By deeply understanding Crashlytics users, their pain points, and their problems, I was much better equipped to redesign the product. And by bringing others along through that process, the entire team was able to better understand our users and meet their needs. After months of hard work and talking to users, we successfully launched a redesign of Crashlytics in Firebaseearlier this year, featuring an improved information hierarchy and a visual refresh, in addition to some new features!

To conclude, here’s my favorite part of the Crashlytics redesign:

Thanks for the article Maple Designer @Google