i'm emma

In the metrics section, users were tracking KPIs but struggling to quickly read performance at a glance. We introduced color coding to the data cells: the closer a value was to its goal, the greener it appeared — the further away, the redder. This let users instantly spot trends across weeks without reading every number. It was a quick win — and we knew it was working because our in-app feedback modal lit up with positive responses. We rolled it out to a small user group first to catch any flaws, then scaled once we were confident. The feedback loop made that staged launch possible.

Instead of writing "add a meeting button to the nav," we'd reframe it as: "As a team leader, I need to schedule a recurring meeting so that my team stays aligned every week." That shift changes everything — suddenly the question isn't where the button goes, but whether scheduling should even live in the nav at all. Jobs-to-be-done kept us focused on the outcome, not the solution.

We had a metrics chart with an arrow the developer assumed meant "expand to see all data" — so as more data came in, the chart shrank to fit it all. But the intended behavior was for the view to shift quarter by quarter, not compress. Nobody caught it until QA because the ticket had no success criteria. There was no definition of what "correct" looked like. After that, every chart story included an explicit expected behavior: what the user sees, when, and what changes on interaction.

Users weren't adding meetings — and data showed why. The "+" button in the nav was being misread as a dropdown toggle, not an action. Interviews confirmed it: people kept clicking expecting a menu to open. We also realized most users don't create meetings often — leadership sets them up once at the start of a quarter. The "+" was creating visual noise for something that barely happened. My proposed fix: move it behind the meetings panel, so adding a meeting happens in context rather than polluting the nav.

During grooming, we embedded a short clip of a user struggling to scroll through the meeting agenda — visibly frustrated, losing their place mid-session. We attached it directly to the ticket. The moment it played, the energy in the room shifted. Developers who had been skeptical about prioritizing it suddenly got it. Even the PM, who had been hesitant, felt it. No amount of data points would have done what thirty seconds of real user frustration did. It's a reminder that working closely with developers isn't just about writing better tickets — it's about building the kind of shared empathy that makes good decisions feel obvious.