A polished home page introduces a website’s visual direction. The moments after a visitor acts often reveal more about its design. What happens when a search returns nothing, a form is incomplete or an action succeeds? These states show how the interface helps someone continue.
The goal is not to collect every possible screenshot. Choose one important task and the states that make its behaviour understandable. Use the actual website or identify a prototype clearly.
Start with the normal journey
Write the visitor’s task as a short sentence. For example, a hypothetical equipment website may help a buyer compare suitable models and send a question to the supplier. The presentation needs enough context to explain where the visitor starts, what they select and what happens after sending the request.
Show the screens at a readable size. If the submission has limited space, use a few annotated states rather than a miniature wall of screenshots. Each caption should explain a decision or a consequence of an action.
Include one meaningful failure state
A useful error example explains both the problem and the route forward. If a required field is missing, show whether the interface identifies the field, preserves the other information and helps the visitor correct the problem.
Do not manufacture a perfect error screen that the live site does not support. If the state exists only in a prototype, label it as proposed behaviour. If implementation differs from the original design, explain which version the submission represents.
Show what an empty result means
An empty search or filter result is different from a loading screen and different again from a technical failure. The presentation should make that distinction visible when it matters to the task.
In the equipment example, a filter combination might return no matching products. Show whether the visitor can understand which filters are active and how to broaden the search. Explain why the chosen response fits the content and audience, rather than treating an illustration or friendly message as sufficient evidence of usability.
Include the successful outcome
After a visitor submits a form or completes an action, the interface should communicate what happened. In the presentation, show the resulting state and describe the real next step. A confirmation screen does not prove that a business process completed successfully behind the scenes.
Use test content and avoid exposing personal details, order information or private client data. If a screenshot has been anonymised, preserve the structure needed to understand the interaction.
Show a mobile difference that matters
Choose a state where the smaller screen changes a decision. A comparison table may need a different viewing pattern; a long form may need clearer grouping; filters may move into a panel. Show how the person retains context when that change happens.
Do not use a device mockup as a substitute for evidence. A mobile frame around a desktop layout does not demonstrate responsive behaviour. Capture the implemented mobile state or label the design as a prototype.
Connect the states to checks
If the entry discusses keyboard use, show and describe the relevant focus behaviour. If it discusses form errors, identify what was checked and where limitations remain. An automated scan or a screenshot alone cannot establish that every visitor can complete the task.
For an initial accessibility review, the W3C Easy Checks describe practical checks and their limits. Report what your team actually checked, not what the reference document recommends in general.
Assemble a short sequence
A focused presentation might contain the starting state, an important selection, one recoverable error and the confirmation. The exact number should follow the project and the organiser’s current requirements. Add a recording only when movement or interaction communicates something the still images cannot.
Review the sequence without the live website open. Can a reader identify the task, the change after each action and the final outcome? Then check the live link separately, using access that a reviewer outside your organisation could use.
Continue with the web design submission guide for the full pack and the case-study framework for the narrative. This presentation method is not an official judging rubric or a guarantee of recognition.