Start with the task

A useful website begins with the questions visitors arrive to answer. List the primary tasks, put them in order, and give each task a direct route from the first screen.

Structure before decoration

A short navigation with predictable labels usually works harder than an elaborate menu. Group related information and write headings that still make sense when read on their own.

Design for real devices

Layouts should remain usable at narrow widths, with readable type, comfortable tap targets and no horizontal scrolling. Test content, not only empty components.

Accessibility is routine

Use semantic headings, visible focus states, useful alternative text and sufficient contrast. Accessibility belongs in every review rather than at the end of a project.

Maintain the evidence

Record decisions, redirects, analytics definitions and release dates. A small maintenance log makes later changes safer and helps teams separate a design preference from an observed problem.

A practical page brief

Write one sentence for the audience, one for the task and one for the evidence the visitor needs. Add the action that should follow and the constraint that could stop it. This small brief keeps design, copy and development aligned without turning a project into a pile of preferences.

Content that survives redesigns

Store facts, dates, owners and source links separately from decorative wording. Use direct labels, short summaries and a clear hierarchy. When the visual layer changes, dependable content can move without being rewritten from memory.

Release and review

Check keyboard navigation, small screens, forms, redirects, metadata and structured data before release. After publication, compare observed behaviour with the original task list. Fix a measurable obstacle first and document every redirect or URL change.