usability testing.

Where usability testing fits on a long engagement.

The finding is almost never the one expected. Teams know their product too well to see the assumptions built into it, and five sessions with people who do not will surface problems that months of internal review did not. The cost is low and the main obstacle is scheduling rather than money.

Task design decides whether it is worth anything. A leading task confirms what you hoped, a vague one produces confusion about the instructions rather than the product. Running it continuously rather than before a launch is what turns it from an event into a habit.

What an assigned team does with usability testing.

Teams know their own product too well to see its assumptions, and that blindness returns within weeks of any research round. Testing once tells you about one release; testing on a cadence changes how the team makes decisions.

The findings are worth little unless someone is assigned to act on them, which is why research and design capacity sit together under an outsourced design team rather than being separately procured.

What we use usability testing for.

• Testing before committing to a build Finding the problem at prototype stage, when changing it costs a day rather than a sprint.
• A regular cadence rather than a launch ritual Sessions running continuously, so findings arrive while decisions are still open.
• Settling an internal disagreement Evidence from users replacing an argument between two people who both know the product too well.

How usability testing capacity is assigned.

Research capacity is assigned under outsource UX design, on the same agreement as the design work it informs. An Azendo service delivery manager answers for what that capacity delivers.