Fastest way to get a project over the finish line: test usability before you code

If usability is tested only once coding is already underway (as is commonly done), the feedback comes too late. Work has already started, solutions have been locked in, and fixes turn into expensive changes within an already agreed budget. In that situation, findings easily end up in the backlog with a sticky note saying “we’ll do it sometime later.” And that “sometime” usually never arrives, because attention shifts to the next features.

Why does early testing save time and money?

In the design phase, a fix is essentially: edit the prototype. In the implementation phase, the same fix becomes: change the code, test again, update approvals, and push the change through the sprint. The same finding is therefore many times more expensive later — and often slower to implement, because it competes with ongoing delivery and the schedule.

A facilitated group walkthrough is a highly effective method here: 4–6 users go through the most important use cases together in a moderated session. In a single 60–90 minute session, the following usually surfaces quickly:

• where users hesitate or get lost
• what they don’t understand (terminology, structure)
• which parts slow work down or cause errors

And most importantly: decisions can be made immediately, while the change is still “redraw it,” not “refactor it.”

Usability debt always gets paid — only the line item changes

If findings are left in the backlog, they don’t disappear. They become costs elsewhere.

It’s a frustratingly familiar situation: shortcomings identified in testing are known, but they aren’t implemented. Then what happens is that after release, customer support gets swamped because users are lost in an unclear UI. Support ends up guiding usage and answering the same questions day after day. If the findings had been fixed at the prototype stage, this load would never have been created.

In the public sector, poor usability often shows up specifically as customer service load, because the customer doesn’t have an alternative way to do their business. In the private sector, it shows up as declining conversion and engagement, because there are always alternatives.

When usability is validated before implementation, sprints are spent less on fixing and more on value-producing development. And above all: the project moves faster, because it doesn’t have to revisit the same decisions later.

Why does usability testing work in a development sprint?

Usability testing works well in a sprint because:

• Everyone sees the same problem immediately. When the development team watches users live, a shared understanding forms without long reports.
• Solutions are found faster. Developers can immediately assess what’s easy to fix now and what’s too big a change for this sprint.
• Decision-making speeds up. In one session, the user experience, technical feasibility, and business priorities come together — and the next steps can be agreed on right away.