A website is experienced over time. Visitors arrive with a purpose, choose where to go and respond to what happens after each action. A design award presentation needs to make that experience understandable even when someone first encounters the project through a few images and a short description.
Show a journey, not just a homepage
01 Find
Show how a visitor discovers the right item.
02 Compare
Keep the important differences easy to scan.
03 Complete
Show the outcome after the action.
Start with one important visitor task. Use it to connect the brief, visual system and interaction decisions. This article offers a presentation method, not an official judging rubric. Always check the competition’s current categories and entry requirements.
Explain what the website is meant to accomplish
Identify its audience and purpose. A portfolio, an online shop and a public information service have different priorities. The entry should make those priorities clear before discussing animation or typography.
For example, a hypothetical specialist equipment website might need to help buyers compare technical options before contacting a supplier. Explaining that task makes a comparison interface easier to assess. Saying that the project delivers an engaging brand experience provides much less context.
Describe the scope of your team’s work. Did it include research, brand identity, content, design, development or only some of those areas? Mention inherited systems and other constraints where they explain a decision.
Show a journey, not a disconnected set of screens
Choose a short sequence that demonstrates the main task. For a shop, that might be finding a product, understanding its options and adding it to the basket. For a portfolio, it could be finding relevant work, understanding the team’s role and making contact.
Show what changes after an action. A selected state, a validation message or a useful empty state can reveal care that a home-page screenshot misses. If space is limited, annotate a small number of screens instead of shrinking an entire site map onto one image.
Use a screen recording when motion or interaction is central to the work. Keep the recording focused and make essential information available without sound. Check that reviewers can open it without your team’s account credentials.
Explain the visual system through its use
Typography, colour, spacing and imagery work together to help people understand content. Show that relationship in real pages.
If type scale creates a hierarchy for complex editorial content, include a page where that hierarchy matters. If colour communicates status, explain the additional cues that support it. If animation guides attention, show the moment it clarifies rather than presenting motion as an achievement on its own.
A small system overview can be useful, but it should support the finished experience. A large collection of components does not automatically demonstrate that a website is understandable or consistent.
Include mobile and less-than-ideal states
Present at least one important mobile journey when the project supports mobile use. Explain decisions that changed between screen sizes, such as navigation, comparison layouts or content order.
Consider states beyond the ideal first load: long titles, form errors, missing content and a visitor returning midway through a task. You do not need to show every state, but the examples you choose should reveal how the design handles real use.
Use the actual supported behaviour. Do not create presentation screens that imply functionality the live site does not have. Label prototypes and work in progress clearly.
Describe accessibility and performance checks accurately
If you mention accessibility, name what was checked and how. Keyboard navigation, visible focus, meaningful labels and understandable error messages are concrete topics. An automated scan alone does not establish complete accessibility. The W3C preliminary accessibility checks provide a practical starting point and explain the limits of an initial review.
Performance claims need context too. Distinguish a laboratory test from data collected from real visitors. Record the page, device conditions and date when sharing a test result. Avoid presenting the best result from one run as a guarantee of every visitor’s experience.
These details should help explain the work, not turn the entry into an unrelated technical report. Include the findings that influenced a design decision or substantiate a claim. For measurement terminology, see Google’s overview of Core Web Vitals.
Pair each claim with something visible
Scroll sideways to see all columns →
| If the entry discusses… | Show… | Explain… |
|---|---|---|
| Responsive design | The same task on desktop and mobile. | What changes, and why. |
| Interaction | Before, action and resulting state. | How the visitor knows what happened. |
| Accessibility | Specific checks and relevant interface states. | Methods, findings and remaining limitations. |
| Performance | Dated results for identified pages and conditions. | Whether the data is laboratory or real-user data. |
Be precise about outcomes and your contribution
If you report a change in conversion or task completion, explain the comparison period and what else changed. A redesign launched alongside a marketing campaign may not be solely responsible for the result.
When reliable quantitative results are unavailable, describe qualitative observations and their limitations. An honest account of prototype testing is more useful than an unsupported claim of business impact.
Credit collaborators and distinguish your decisions from inherited work. Make sure the client has approved any commercial data, screenshots or research material included in the entry.
Finish with a clear submission pack
Prepare a concise project summary, a focused journey, desktop and mobile examples, credits and accessible supporting links. Confirm the live website or prototype is stable enough to review and that its state matches the presentation.
Explore the Web Design Award Winners collection as a record of recognised work, then build a presentation around your own project’s purpose and evidence. Use the case-study writing framework to organise the narrative. Check the current award brief before planning an entry; this guide does not imply that registration is open.
Entry requirements vary by programme and edition. Check the Design Skill Awards brief or the International Excellence Awards brief for the current status, categories, fees and deadlines. These preparation guides do not replace the official rules.