designing-beautiful-websites

Clear, distinctive web interfaces

Make the purpose and next action legible, with a visual language that fits the product and audience. Build from real content and behaviour, then use typography, spacing, colour, imagery, and motion deliberately. Beauty is not one universal palette, a grid of rounded cards, or an obligation to remove all decoration.

Establish the actual design task

Read the request, existing implementation, design system, assets, and relevant content. Identify the user, page purpose, important journey, brand signals, target platforms, and constraints. Use supplied answers; infer ordinary defaults and state consequential assumptions without repeating a questionnaire.

For a local polish request, stay local unless a structural problem prevents the requested result. For a new site, choose a coherent direction and implement the requested deliverable rather than only returning a planning packet. For an audit, show the material issues, their locations and impact, and specific fixes. Do not claim to have interacted with a page when only a screenshot was available.

Structure before ornament

Trace the user's key task from entry through completion and recovery. Make labels, content order, navigation, and feedback understandable without internal terminology. Retain the context needed to make a decision; fewer words or clicks are not always better. Distinguish required steps from accidental friction, including permissions, confirmation, cancellation, and access to help.

Start layout from the content and priorities rather than a generic app shell. Use meaningful grouping, alignment, and whitespace. Define how real long text, translations, missing images, tables, errors, loading, empty results, and success states fit. Design information order and controls for narrow screens, zoom, and keyboard use, not merely a scaled-down desktop screenshot.

Give the interface a visual point of view

Use the project's established visual system first. For a new direction, choose a small set of intentional characteristics: for example, editorial typography and asymmetric composition for a publication, precise compact controls for a technical tool, or generous photography and warm materials for a hospitality site. These are possible directions, not templates to apply regardless of the brief.

Create hierarchy through type size, weight, line length, spacing, contrast, and position before adding more decoration. Use a consistent spacing/type scale as a starting discipline, then allow a justified optical or content-specific adjustment. Use borders, shadows, backgrounds, and illustration according to the composition; a blanket preference for shadows over borders is not a quality rule.

Make dominant content and actions visible, with quieter supporting information. Use intentional imagery and crop/focal choices rather than arbitrary stock assets. Only use assets with suitable rights; do not invent client logos, reviews, awards, statistics, or product capabilities to fill a layout. Mark synthetic content as a placeholder. Avoid fake scarcity, hidden refusal, or misleading price presentation.

Use restrained, purposeful motion where it helps orientation or feedback, with reduced-motion and usable static states. Do not add a heavy library, animation system, or client boundary for an effect already served by simple CSS.

Implement complete states and semantics

Keep buttons as actions and links as navigation. Use the existing component system and framework conventions; preserve refs, focus, form submission, validation, and loading/error semantics when restyling. A disabled-looking control must have the correct interaction behaviour. Define what happens after network failure, duplicate activation, cancellation, or stale data; visual feedback is not proof a write succeeded.

For forms, preserve entered data and make errors specific and recoverable. For menus/dialogs/tabs, use the appropriate semantic pattern and keyboard/focus behaviour, not just a styled container with role attributes. Do not hide important content until a fragile JavaScript reveal succeeds. Keep layout stable as fonts/media load.

Read accessibility for targeted checks. A contrast ratio or automated scan is one piece of evidence, not an accessibility certificate.

Inspect, test, and iterate

A quick first-impression or heuristic walkthrough is useful expert inspection; it is not a measured user test and cannot establish conversion or task-success rates. Where testing is requested, use actual participants or observed interaction and record scope, conditions, and results. Do not invent a successful glance test.

For implementation, run the relevant project typecheck/build/tests as authorised, then inspect rendered output at meaningful widths, zoom/text sizes, interaction states, and input methods. Check focus, accessible names, scrolling, clipping, content wrapping, and browser/console failures. Record what was actually tested. A static screenshot cannot establish keyboard or screen-reader behaviour; a test plan is not a completed test. Avoid unsupported performance or conversion claims.

For handoff, give the actual patch or requested design artefact, changed tokens and component/state rules where useful, and unresolved verification. A small edit does not need a new sitemap, complete design system, or seven-section report. Stop when the work serves the task; don't keep redesigning coherent choices for novelty.

Load only the relevant reference

• Visual design: typography, hierarchy, composition.
• Information architecture: navigation and structure.
• Interaction: states, controls, and forms.
• Content: useful labels and microcopy.
• Responsive design: content-led layouts and edge cases.
• Accessibility: semantic and input checks.
• Design audit: finding/impact/fix format.
• Page patterns, usability, workflow, and checklists: optional deeper methods, not a mandatory output format.

Reference/script paths belong to the installed skill directory, not the target project. Older numeric design ranges are heuristics to adapt, not universal standards. No usability, accessibility, conversion, or performance improvement is claimed without evidence from the actual interface.

Authoring baseline reviewed 2026-09-13: https://agentskills.io/specification. Current accessibility sources are listed in the accessibility reference.