Prepare a design handoff with states and behaviour
Hand over a specification the team can verify. A worked example of project search shows text, states and checks.
A design handoff should tell development which interface to build and how it behaves in the agreed workflow. Choose a concrete task for this. The following template describes a project search in a fictional customer portal; it is a plan, rather than an interface already implemented.
Record the task and design version
In the example, the person enters “Portal” and starts the search. The portal loads matching projects covered by their existing permissions. The design does not change those permissions. Record which source file and approved design version apply. Identify components by version; an older image export should not silently become the implementation template.
Connect states with text and interaction
State in the example specification | Intended feedback | Agreed behaviour |
|---|---|---|
Search can be started | “Search projects” field, “Search” action | The entered term remains visible; the action starts loading. |
Search is running | “Loading projects.” | The ongoing search is apparent; old results are not presented as new matches. |
Search completed with matches | “2 projects found.” with project links “Portal redesign” and “Portal help” | The matching projects can be reached; the search term is retained. |
Search completed without matches | “No projects found for this search.” | The term is retained and can be changed. This is not a connection error. |
Fetch failed | “The project list could not be loaded. Try again.” | The term is retained; another search is possible. The error is not presented as an empty results list. |
The two project names are assumed example matches. Also establish what happens when a new search starts while an earlier response is still pending. Only results belonging to the current term may appear as the current state.
Hand over technical naming and feedback
W3C recommends suitable visible labels and checked accessible names. Clearly connect the field, action and intended name in the design. Status messages can provide information to assistive technology without taking focus themselves. The results list itself is distinct from its short status message.
Agree where focus remains after searching and how the results list can be reached using the keyboard. Clearly identify unresolved questions in the handoff; a missing design is not approval for arbitrary behaviour.
Accept the implementation using the same task
In the implemented version, check searching, empty results and failed fetching with suitable test data. Check longer translations, keyboard navigation and feedback with the intended assistive technology. Compare the result with the agreed design version. Feed corrected rules back into the shared documentation so later changes build on the same baseline.
Sources
Read more
All articles
Your project with ASES
Describe your project to us. We will get back to you with an initial assessment.