Client handover
What an agency should include in a UX handover pack
UxerProof Editorial · · 3 min read
A client handover should let the next team understand what was delivered and what still needs attention. Screenshots of finished pages help explain the design, but they do not establish which tasks were tested or under what conditions.
A UX handover pack connects the delivered version to useful journey evidence. Keep it compact enough to review and specific enough to guide the next release.
Lead with the delivered scope
Name the product, environment and release version. Describe the tasks included in the handover and any explicit exclusions. If a feature is a prototype, a demo or dependent on unconfigured infrastructure, label it accordingly.
For an illustrative agency project, the handover might cover a public enquiry journey and an administrator's review of a test submission. That does not automatically include payment processing, production email reliability or every administrative role.
Include the evidence that changes a decision
| Component | What it should explain |
|---|---|
| Journey summary | The goal, role, starting state and completion criteria. |
| Execution record | The tested version and observed result. |
| Findings | The obstacle, supporting evidence and affected task. |
| Remaining work | The owner, dependency and required next check. |
| Operational handoff | Who can deploy, support and investigate the delivered system. |
Avoid padding the pack with repeated screenshots that do not support a finding. A small set of well-labeled references is easier to review than a large folder whose relationship to the release is unclear.
Make limitations easy to find
Separate completed tasks from blocked and unassessed ones. If production configuration was outside the agency's scope, state what was tested locally and what needs production verification.
Do not represent synthetic participant behavior as customer research. Do not add conversion, revenue or satisfaction claims without appropriate evidence. A client can value a reproducible usability finding without being told it proves a business outcome.
Plan for the next team
Include the instructions needed to rerun important checks using safe fixtures. Name the intended permission level and cleanup steps. Keep credentials out of the handover document and use the client's approved secret-management process instead.
When a finding is accepted temporarily, record the person responsible for revisiting it and the condition that triggers review. This avoids a known limitation becoming an undocumented permanent feature.
Finish with a decision, not a guarantee
The handover should allow a responsible owner to decide what can proceed and what remains conditional. It is project evidence, not a legal warranty, accessibility certification or comprehensive security audit.
Give the client a clear route to the remaining actions and a way to verify repairs. That makes the evidence useful after the handover meeting, when someone else needs to maintain the product.
Next step: Use UxerProof's fictional sample report as an example of organizing findings around observed journey steps.
Put the evidence structure to work
Inspect UxerProof's fictional sample report, or use the free readiness check to prepare your next journey. External Circuit execution is not yet activated; see current launch status for availability.