Practical review example (hypothetical, not a real award decision)
What to know
Review a website as a working product: record the task, environment, observed behaviour, impact and limitations. Assess technical execution, performance, accessible interaction and creative development through reproducible evidence. The portfolio example is hypothetical and does not represent a real award decision or an official numerical scoring rubric.
A beautiful landing page can hide a brittle application. An ordinary-looking navigation system can reveal exceptional engineering. Neither becomes clear from a screenshot alone.
The question in a serious website review is not simply whether the design makes a strong first impression. It is whether the implementation holds together once somebody uses it: when a form fails, the connection slows, a keyboard replaces the mouse, the viewport narrows or a third-party service stops responding.
Web Dev Awards publishes four central areas of consideration: technical execution, performance, accessible interaction and creative development. This article demonstrates how a reviewer can investigate those areas in practice, distinguishing what can be observed from a live public website from what would require source access or internal evidence. The worked review below is illustrative, not a report of an actual judging decision or a new official points-based rubric.
A review needs a reproducible method
Begin with the submitted URL as a working product. Observe the initial page, then test the primary task it promises to support. For a portfolio, that may be discovering work and making an enquiry. For an online shop, it may be finding a product and completing a basket journey. For a publication, it may be reading an article, following related content and searching its archive.
Record the evidence rather than relying on first impressions:
- Environment: browser, device type, viewport, connection conditions and date of review.
- Task: the action a visitor was attempting, from start to finish.
- Observation: what happened, including any delay, failure or unexpected state.
- Reproducibility: whether the issue occurred again and under which conditions.
- Impact: how much the issue affected access, reliability or task completion.
- Limitations: what could not be verified from the public interface.
An impressive WebGL transition might warrant a second look under reduced-motion settings and on a lower-powered device. A clean checkout might warrant a deliberate form-validation test. Fair review means matching the test to what the site is trying to do.
1. Technical execution: judge the behaviour, not the technology label
Architecture matters, but the visible consequences matter more than the name of a framework. React, Vue, Svelte, WordPress, Tailwind CSS and page builders can all be used well or poorly. A large framework is not automatically wasteful; a hand-coded site is not automatically resilient.
For a live website, technical execution is most credibly evaluated through observable behaviour: links resolve correctly, navigation remains coherent, forms provide valid responses, components handle empty states, the page adapts to narrower screens and failures are understandable. When the site exposes technical details, DevTools can help explain why something behaves as it does. A reviewer should not claim to have inspected private repository code or backend logic without access.
What resilient behaviour looks like
Consider a contact form with a temporarily unavailable API. A weak implementation shows an indefinite spinner or clears the message after an unsuccessful attempt. A stronger implementation announces the failure, keeps the visitor's input, prevents duplicate submissions and provides a sensible way to try again. The same principle applies to images, embedded services, search results and payments.
Third-party resilience is important. A marketing pixel, external font or chat integration should not become an essential dependency for opening a menu, reading content or completing the primary task. This is not a promise that every optional service can fail without any visible effect; it is a design objective to avoid unnecessary single points of failure.
Security: respect the boundary of a public review
A reviewer can note visible security or privacy issues, such as an unexpected credential in publicly delivered code, unsafe user-facing output or insecure form handling. They should not claim to have proved a site immune to injection, cross-site scripting or account compromise through a superficial browser inspection. Nor should they perform intrusive penetration tests without explicit authorisation.
It is also inaccurate to ask whether every “sensitive payload is hashed.” Passwords generally require appropriate one-way password hashing at rest; other sensitive data may need encryption, access controls, minimisation and secure transport. Different data has different protection requirements. These are architecture and security-audit questions, not conclusions that a juror can infer from a screenshot.
2. Performance: separate field experience from lab diagnosis
Performance is wider than the time taken to display a hero image. It includes initial loading, responsiveness during use and visual stability. The three Core Web Vitals are useful reference points:
| Metric | What it assesses | Google's good threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | When the main visible content loads | 2.5 seconds or less |
| Interaction to Next Paint (INP) | Responsiveness to user interaction | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | Unexpected layout movement | 0.1 or less |
These thresholds are evaluated against field measurements at the 75th percentile, with mobile and desktop considered separately. Google explains how Core Web Vitals relate to Search. They are relevant indicators, not the sole definition of a well-developed website.
A reviewer should inspect both available real-user data and realistic lab behaviour. The Chrome User Experience Report (CrUX) may be unavailable for a low-traffic URL; it may also show origin-level data when URL-level data is insufficient. Do not describe origin-wide measurements as proof that a specific submitted page passed. Lighthouse can help expose loading and main-thread problems, but Total Blocking Time is not INP. An isolated lab score does not establish what the majority of users experience.
A useful performance test sequence
Open the site on a mobile viewport and observe whether the main content appears promptly. Scroll, open navigation, interact with filters or forms, and return to the page after the initial load. Check whether large images cause elements to jump or whether a fixed banner blocks controls. Use DevTools to investigate a problem rather than inventing causes based on visual style.
An LCP issue might involve an oversized image, render-blocking resources, slow server response or delayed rendering. Preloading can help when applied carefully to the genuine priority resource, but preloading every image adds competition and may worsen performance. CLS issues can involve unsized media, late-inserted banners or font swaps. Reserving space for images and dynamic modules is often sensible, but not every shift is solved by adding width and height attributes to a few elements.
3. Accessible interaction: can people operate the design?
Review the website using a keyboard before relying on an automated score. Can the visitor see where focus is? Reach the main content without repeatedly tabbing through navigation? Open and close dialogs? Complete forms and understand errors? Does a custom control announce its state appropriately? Does a client-side page transition establish where the visitor has landed?
A polished interface can still fail these tests. Common trouble spots include focus disappearing behind sticky headers, visually open dialogs that do not contain keyboard focus, unlabeled icon controls and status changes that are obvious on screen but silent to assistive technology.
Automated accessibility scans provide valuable evidence, but they do not replace task testing. Evaluate findings against applicable WCAG 2.2 requirements, and be precise about which requirement is involved. One red outline from an automated tool does not necessarily describe the full user impact, and passing a scan does not guarantee an accessible experience.
4. Creative development: invention should serve the visitor
Creative development is not a synonym for animation volume. It concerns the relationship between an idea and the engineering used to communicate it. A distinctive scroll narrative, interactive diagram, WebGL environment or unconventional navigation pattern may be technically accomplished and editorially memorable. But the implementation should remain understandable and operable.
Ask what the technique adds. Does motion clarify a transition or merely delay access to the content? Can a user pause or reduce it? Is the experience still coherent when a browser does not support a particular feature? Does the site provide a useful alternative when a demanding effect cannot run smoothly?
A restrained, carefully engineered website can also demonstrate creativity. The right technical decision is sometimes to avoid an effect because it would harm clarity, loading or accessibility.
Worked example: reviewing an experimental studio portfolio
Imagine a public-facing studio portfolio with an immersive opening scene, animated case-study cards and a slide-over enquiry form. It looks visually distinctive and works smoothly on a powerful desktop. These are hypothetical observations designed to demonstrate a review, not findings from an actual submitted website.
The reviewer follows a short journey: load the home page, discover a project, read its case study and open the enquiry form. Then they repeat the journey using only the keyboard and under more constrained mobile conditions.
| Area | Illustrative observation | Why it matters | Follow-up test |
|---|---|---|---|
| Technical execution | The enquiry panel loses entered text after a simulated network failure. | The primary business task becomes unnecessarily fragile. | Retry with a failed API response and check whether input is preserved. |
| Performance | The opening animation delays usable navigation on a mid-range phone. | A visually ambitious introduction may obstruct immediate interaction. | Profile main-thread and rendering activity during the interaction. |
| Accessibility | Focus remains on background content when the enquiry panel opens. | Keyboard users may not be able to locate or operate the panel. | Test initial focus, modal containment and return focus. |
| Creative development | The motion establishes a clear visual identity and communicates project transitions. | The engineering supports the studio's presentation rather than existing only as decoration. | Test reduced motion and fallback behaviour. |
The observations should be considered together, not mechanically added into an invented numerical score. The creative work may be distinctive; the problems may still materially affect access and completion of the main task. Conversely, a small, reproducible issue on a secondary page does not automatically outweigh everything a team has achieved.
Distinguishing severity from preference
Good review notes separate defects from taste. “I dislike horizontal navigation” is an aesthetic preference. “The only way to reach the final project is a drag gesture with no accessible alternative” is a testable interaction issue. “The page uses too many div elements” is not meaningful evidence by itself; “a deeply nested interface causes measurable rendering delays and obscures semantic relationships” points towards a demonstrable technical problem.
Classify practical impact without claiming an official hidden scoring system:
- Critical to the task: The main journey cannot be completed, or a fundamental interaction is unavailable to a meaningful group of users.
- Substantial: A recurring problem causes serious delay, confusion or loss of progress, but a workaround exists.
- Moderate: A localised issue affects part of the experience without defeating the primary journey.
- Minor: A limited inconsistency with comparatively low user impact.
The label should be supported by the evidence, not by the evaluator's personal preference for a framework or design style.
What code quality can and cannot reveal from outside
Development quality includes maintainability and good architecture, but those properties are not fully visible to a person reviewing a live URL. External inspection can reveal excessive download size, redundant resources, malformed semantic structure, failing requests, unexpected console errors and expensive DOM activity. It cannot reliably tell a reviewer whether source modules are well organised, tests are comprehensive or private APIs are correctly authorised.
A large DOM can cause work for the browser, but raw node count is not a universal quality score. Tailwind CSS is not a flaw; shipping a large amount of unused CSS that measurably harms a page may be. A minified bundle is not proof of thoughtful code, and a page builder is not proof of poor code. The proper question is whether an implementation choice has a measurable or observable cost in this context.
If a project team supplies source access, architecture diagrams, documented performance experiments or an accessibility testing report, those materials can deepen a review. Their presence should be identified clearly. Do not present claims drawn from inaccessible private systems as if they were independently tested.
A model review note
A useful evaluation might read:
The site demonstrates purposeful creative development through a distinctive animated presentation and coherent transitions between projects. Its live implementation is less consistent during the main enquiry journey. Keyboard focus is not reliably transferred into the enquiry panel, and a failed submission can discard entered content. Both findings are reproducible and affect a primary task. The first priorities are predictable dialog focus management and recoverable form submission; performance profiling of the opening animation should follow on representative mobile hardware.
That is more useful than calling a site “technically weak” or giving it a number without explanation. It recognises strengths, identifies specific limitations and provides an evidence-led route to improvement.
How to document a fair review
The published Web Dev Awards judging guidance describes a live-product evaluation that considers screen sizes, input methods and realistic conditions. In practice, an evidence-based record can be built around five questions:
- Purpose: What is the site designed to help a visitor achieve?
- Execution: Does its central functionality work reliably across the tested conditions?
- Experience: Is the journey responsive, stable and accessible?
- Invention: What does the implementation do that is distinctive and useful?
- Limitations: Which conclusions are supported by observation, and which remain unverified?
Avoid overstating the scope of a single review. Testing one mobile browser is not testing every mobile device. Inspecting a form is not conducting a security audit. Observing a Lighthouse result is not measuring all real-user sessions. These distinctions protect the credibility of both the reviewer and the project team.
The programme's submission rules also make the relationship between payment and recognition clear: an entry fee covers evaluation, not the purchase of an award. Editorial independence is easier to understand when criteria and methods are explained plainly.
The strongest work survives closer inspection
The purpose of technical review is not to punish complexity or reward simplicity for its own sake. It is to recognise decisions that make a website more effective, reliable and distinctive. An animation may be sophisticated enough to deserve recognition while still needing better fallback behaviour. An unassuming content site may demonstrate exceptional care through semantic HTML, rapid navigation, clear error handling and a dependable reading experience.
At its best, evaluation looks beyond what a website shows on first arrival and considers what happens when someone actually tries to use it. That is where good development becomes visible.
Frequently asked questions
Does a framework or CMS affect the result on its own?
No. A framework, utility-first CSS system or page builder should be evaluated through the quality and consequences of the implementation, not treated as an automatic positive or negative.
Is a high Lighthouse score enough to demonstrate technical excellence?
No. Lighthouse is a useful diagnostic tool, but it does not prove real-user performance, resilient interactions, accessibility across full journeys or creative quality.
Can a juror verify backend security from a public website?
Not comprehensively. A public review can note visible issues but should not claim the assurance of a formal security audit or perform unauthorised intrusive testing.
Is the worked example an actual Web Dev Awards decision?
No. It illustrates an evidence-based review method using hypothetical observations. Official programme information appears on the judging page and submission rules.
Further reading: Web Dev Awards judging · Submission rules · Google Core Web Vitals · WCAG 2.2