The tradeoff in this project was between shipping something feasible within the current scope and timeline, versus addressing the most critical user need. The original direction was to highlight new and popular settings, which was easier to implement and aligned with the product plan. But when I dug into the research, I realized that settings conflicts were actually a more urgent issue for admins. So the tension became: do we stay with the safer, simpler direction, or do we push toward something more valuable for users, even if it introduces more complexity?

The signal that made me think it was worth the risk came from research. I reviewed the UX research report and noticed that settings conflicts kept coming up as a major pain point. To validate that further, I talked with the UX researcher and customer engineers who work closely with admins. They confirmed that settings conflicts were a frequent and important issue, and the researcher also shared data showing that around 60% of users were looking for this kind of support. That gave me confidence that this was not just an interesting idea, but a real user need.

The bet I made was that the overview page should do more than just summarize information. I believed it could proactively guide admins toward actions that mattered, especially around settings conflicts. Instead of only surfacing new or popular settings, I proposed that we explore ways to make more actionable settings insights visible on the overview page.

From there, the design decision was figuring out what format could best balance user value and technical feasibility. I explored multiple directions, including separate cards, action-oriented lists, and different ways of organizing the information. I also hosted a workshop with the PM and engineers, where I shared the research insights, walked through the pros and cons of each direction, and mapped out end-to-end user flows so we could discuss feasibility more concretely. In the end, we aligned that settings conflicts were an important need, but it was too complex to build in that project phase. So for the current scope, we landed on a dynamic and actionable settings card that still improved discoverability and configuration, while the settings conflicts opportunity was prioritized as a separate workstream for another designer later on.

What I’m proud of in this project is not just the final design, but the fact that I helped the team uncover a more important user need and turn it into a future priority. It taught me that good design is not only about solving the problem in front of you, but also about recognizing when there’s a better problem worth advocating for.