# RADA: briefs and method

This is an original design demonstration prepared on 17 October 2026 for the article **Why do so many AI websites look the same?** Both website versions were created with AI assistance. RADA is a fictional bicycle workshop, not a client business.

## Open the working examples

- [First draft](first-draft.html)
- [Revision with explicit design direction](with-design-direction.html)

Each page is a standalone HTML file with its CSS, SVG illustration and JavaScript embedded. Open it in a browser. It does not require a build step, external fonts or a network service. Appointment forms only validate a demonstration request on the page. They do not send data or book an appointment.

## The first brief

The content and design instructions given for the first generation were:

> Build a modern, clean, responsive website for a fictional bicycle repair workshop called RADA in Tallinn. Services: annual bicycle service, brake adjustment and puncture repair. Visitors should be able to view services and request an appointment. Use English. You may use inline SVG illustrations you create yourself and CSS, but no external images/libraries/fonts. Provide a functional mobile menu if needed and a locally validated demo appointment form that clearly says it does not send a booking. No invented reviews, customer counts, prices or availability claims. This is an illustrative fictional business. Make the design polished according to your own judgment; no instruction to make it generic or bad.

The task also specified a single self-contained HTML deliverable. File-output and agent-ownership instructions are omitted here because they did not direct the design.

The resulting first generation used a sage palette, a two-column hero, an original bicycle illustration, three service cards, a workshop section and an appointment form. Its visual design was accepted as the starting point. It was not deliberately degraded to create the comparison.

### A small functional correction

Review found a missing opening `<option>` tag for the annual service in the first generation. This prevented that service link from selecting its option correctly. The working first-draft example adds that one opening tag. The visual design and the opening screenshot are unchanged by this repair.

The original generated source is preserved as [plain text](source-first-generation.txt), before that correction. Both working examples were then checked with all three service links.

## Direction for the revision

The revised implementation was developed after inspecting the first draft. These decisions guided it:

| Area | Direction applied |
| --- | --- |
| Audience | An everyday rider who may not know technical part names. |
| Main task | Find a relevant repair, describe the problem and request a time. |
| Content | Lead service choices with familiar symptoms, while retaining the actual service names. |
| Priority | Show the repair choices near the start of the page. On mobile, place them before the illustration. |
| Visual reference | A practical workshop service sheet: paper tones, dark rules, bold type and yellow. |
| Assets | Reuse the original bicycle geometry. Retain self-contained assets and system fonts. |
| Interactions | Keep standard navigation links, labelled fields and service preselection. |
| Business facts | Preserve the same fictional name, city, three services and appointment goal. Add no prices, reviews, address or availability claims. |

This was an intentional design and editing pass, not a blind second sample. The article's reusable prompt expresses this direction in a form readers can adapt; it is not presented as an exact transcript of a one-shot second generation.

The bicycle's wheels and frame come from the same original SVG drawing. The revision removes the scenery and changes its colour treatment and composition. No external artwork or photographs were added.

## How the images were produced

The figures use real screenshots of the included HTML pages. The screenshots were arranged in a graphic layout; interface text and page elements were not repainted or changed in the images.

- Desktop comparison: both pages at **1280 × 1000 CSS pixels**, device scale factor 1, page top, 100% zoom.
- Mobile implementation figure: two views of the revised page at **390 × 844 CSS pixels**, device scale factor 1. The left view shows the page top; the right view shows the appointment form area further down the same page.
- Detail comparison: matching crops from both versions at **390 × 844 CSS pixels**, device scale factor 1. The headline crop is **x=0, y=134, width=390, height=132**. The lower opening-view crop is **x=0, y=388, width=390, height=456**, ending at the bottom of the viewport. Both designs use the same rectangles and a uniform **1.2×** display scale on a **1080 × 1300** figure. This enlarges the exact headline wording and the content that follows the introduction. The first draft's service cards are further down the page, outside this initial capture.
- Browser: **Chrome Headless Shell 133.0.6943.126**, controlled locally with Playwright. Reduced-motion preference enabled for reproducible captures.
- Figure labels and captions are provided in English and Estonian. The example website stays in English in both articles so the underlying comparison is identical.

## Verification performed

These are checks of the included examples, not performance benchmarks:

- No JavaScript page errors were observed during the browser checks.
- Internal section links resolved.
- Each of the three service links selected its matching form option in both working pages.
- Empty required fields and an invalid email prevented the demo success state.
- A valid demonstration request displayed a message explicitly stating that nothing had been sent or booked.
- No horizontal page overflow was observed at viewport widths **320, 390, 768 and 1280 pixels**.
- The first draft's mobile menu opened and closed, including with Escape.
- Keyboard navigation reached the visible skip link in both pages.
- Desktop and mobile screenshots were visually inspected.

No full accessibility audit, screen-reader study, customer usability study or conversion experiment was performed. The visual comparison cannot establish real booking performance, model superiority or how frequently websites generated with AI look similar. Preference for one visual direction remains a design judgment.

## Supporting sources

The article's general guidance draws on these primary sources. They support the relevant design principles; they do not validate RADA's commercial performance.

- [Anthropic — Improving frontend design through Skills](https://claude.com/resources/articles/improving-frontend-design-through-skills)
- [Nielsen Norman Group — 5 Principles of Visual Design in UX](https://www.nngroup.com/articles/principles-visual-design/)
- [Nielsen Norman Group — Maintain Consistency and Adhere to Standards](https://www.nngroup.com/articles/consistency-and-standards/)
- [W3C WAI — Designing for Web Accessibility](https://www.w3.org/WAI/tips/designing/)

## Eesti keeles

RADA on selle artikli jaoks loodud väljamõeldud jalgrattatöökoda. Mõlemad veebilehe versioonid valmisid AI abiga. Esimese kavandi visuaalne lahendus sündis lühikese lähteülesande põhjal; seda ei muudetud tahtlikult kehvemaks. Täpsema disainisuunaga versiooni koostamisel määrati sihtrühm, teenuste esitamise järjekord ja töökoja visuaalne iseloom.

Esimese kavandi töötavas näites parandati üks puuduv vormivaliku avamärgend. See ei muutnud võrdluspildil nähtavat kujundust. Pildid pärinevad tegelikest HTML-lehtedest. Mõlema töölauavaate mõõtmed on samad. Detailivõrdluses on mõlema versiooni telefonivaatest võetud samad piirkonnad ja neid on suurendatud samas mõõtkavas. Eraldi mobiilipilt näitab täpsema disainisuunaga versiooni avavaadet ja ajasoovi vormi.

Näidisvormid kontrollivad sisestatut ainult lehel ega saada andmeid ega loo broneeringut. Võrdlus näitab disainiotsuste tulemust; see ei ole mudelite võrdlustest, kasutajauuring ega tõend suurema broneeringute arvu kohta.