Usability testing when you have no research budget
Five participants and an afternoon will tell you more about your product than a quarter of internal debate.
Handoff fails when it is a moment rather than a collaboration. The fix is mostly about when engineers are involved.
The most common handoff failure is designs arriving complete, with technical constraints discovered afterwards. By then, changing them costs rework and goodwill.
Bringing an engineer into design review early surfaces feasibility, performance and data-shape constraints while they are cheap to accommodate.
Undesigned states get improvised inconsistently. Specifying them is the single highest-return handoff activity.
Handing over pages invites bespoke implementation. Handing over components with defined properties and states produces reusable code and consistent results.
Where a design system exists, the handoff is mostly which components to use and what is new — a much smaller conversation.
Design QA against the implementation catches spacing, state and interaction differences while they are quick to fix. Doing it together rather than as a defect list is faster and less adversarial.
It also feeds back into the system: differences that recur usually indicate a missing component or an ambiguous specification.
Static designs communicate appearance well and behaviour poorly, and behaviour is where most implementation questions arise.
Specify what happens on interaction: does the button disable while submitting, does the list reorder immediately or after confirmation, what happens if the action fails halfway. These decisions get made by whoever implements them if they are not specified.
A short written note beside each interactive component is usually enough. It is faster than a prototype and answers the questions that actually get asked.
Most modern design tools provide inspection and specifications. The tool matters far less than whether designers and engineers talk during the work.
Detailed on behaviour, states and edge cases; less so on measurements if a token system covers spacing and type.
The designer checks intent, the engineer checks implementation, and both look together. Making it solely one side's job produces either nitpicking or drift.
Keep reading
Five participants and an afternoon will tell you more about your product than a quarter of internal debate.
Software people use all day has different requirements from software people use occasionally. Optimising for the wrong one makes experts slower.
Tokens turn visual decisions into named values shared by design and code. Naming them well is the whole trick.