The Problem
During customer testing sessions on N-central, the UX team consistently surfaced a stream of small, individually minor usability issues — affectionately nicknamed "Pebbles." On their own, none seemed to justify engineering time, but they'd accumulated to roughly 300 logged issues, cumulatively acting as a real drag on an otherwise strong product experience. Convincing the business to prioritize a backlog of "small" fixes over larger feature work was a genuine challenge.

My Role & Constraints
I was part of a four-person team — a senior designer, a senior researcher, an intermediate researcher, and myself — working to build the case for addressing the Pebbles. My specific contribution was running a number of the workshop sessions with users, including card-sorting exercises that let us rank which Pebbles mattered most, turning an undifferentiated list of 300 issues into a prioritized, user-validated backlog.

Process & Key Decision
Rather than presenting engineering with a flat list of everything logged, we used the card-sorting results to build a prioritization matrix weighing user impact against effort to resolve — letting us show leadership that many of the highest-impact Pebbles required relatively little engineering effort. We paired that with concrete examples from testing sessions to make the abstract "300 small issues" tangible, and framed both the long-term cost of leaving them unresolved (retention, support load) and the short-term case for quick wins.

Outcome
Leadership didn't allocate a dedicated team, but the case shifted engineering practice: Pebbles began being worked in two ways — folded into new-engineer onboarding as real, practical tasks that accelerated ramp-up, and used periodically as sprint fillers when engineers had spare capacity. I don't have an exact resolution count, but I recall seeing a Pebbles-tracking chart from one of the PMs later on, showing the backlog well below the ~300 originally logged — a good sign of sustained progress even without dedicated headcount. Work was still ongoing when I left.

Reflection
If I could revisit this, I'd have pushed for a lightweight, visible way to track Pebbles resolution over time from the start, rather than relying on impressions and half-remembered numbers years later. The bigger lesson was that when the ideal outcome — dedicated engineering time — isn't available, finding a genuinely useful alternative can still create lasting change. In this case, folding Pebbles into onboarding turned out to be a more sustainable route than a one-off dedicated sprint might have been.