All week, we've been going through some alternatives for backlogs. Because backlogs suck and I hate them. And for each alternative, I've been saying that it's not my favourite method. So what do I prefer?
Here's my favourite.
User journeys.
You pick one end-to-end user journey in your product and you make it fully accessible before you touch anything else. That might be your checkout, your user onboarding, the account creation, whatever matters most to your users. Your focus is to fix an experience, not components.
This is the one I keep coming back to and here's why.
Every other approach on my list so far deals with issues in isolation.
Fix-on-touch fixes components when a developer happens to be nearby. You might fix a button today and a form field three months from now, but the user trying to complete that journey in between is still stuck. It's reactive by design.
The Top 3 rule and the Fix/Schedule rule have the same blind spot. They're great at creating focus and forcing decisions, but three priorities or a scheduled fix can easily be three unrelated things spread across the product. There's no guarantee they add up to anything a user would feel.
Severity buckets are the worst offender here. A critical, a major and a minor can sit in the same broken flow and get handled weeks apart by different people. The experience stays broken even as the tickets get closed.
Disability sprints come closest. You're hearing from real users about real friction, which often points to journeys rather than components. But the output is still a list of issues to prioritise and there's no commitment to following a single thread all the way through.
User journeys is the only approach that starts with the experience and works backwards. You're fixing what a real person moves through, start to finish.
That also makes the work easier to communicate. "We've made checkout fully accessible" sounds much better than "we closed 14 tickets this sprint." One means something to your organisation while the other is just noise.
There's a discipline to it too. Picking one journey means ignoring everything else for a while. That's hard, especially when new issues come at you and people want you to react. But it's the same lesson as the Fix/Schedule rule. Focus is a decision and decisions are what move things forward.
Once one journey is done, you pick the next one. Over time, you build a product that works, not a list of components that passed an audit.
That's the goal, isn't it?