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

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