Web Design Handbook

The role of web design in web engineering

Web design is not a layer of decoration added at the end of a project. It is the visible expression of analysis, architecture and content decisions. Good design determines how clearly a site communicates, how easily users navigate and how efficiently they complete tasks.

In the Dianthos approach, design work began only after clarifying:

• What the site should achieve for the organisation.
• Who the primary audiences are and what they need to do.
• Which content types and functions are actually required.
• How the site will be maintained and extended over time.

Only then did we move into page structures, visual systems and templates.

Purpose, audience and content-first design

Every significant page must have a clear job. A homepage that tries to do everything rarely does anything well. Product pages, service descriptions, case studies, articles and support content serve different purposes and should be designed accordingly.

Questions we asked before layout

• What should a successful visit to this page look like?
• Which questions must be answered for the visitor to move forward?
• What is the primary action on this page, and what are acceptable secondary actions?
• What content is mandatory, and what is optional or distracting?

From this, we prepared content outlines and sometimes low-fidelity wireframes. Design decisions followed content and behaviour, rather than the reverse.

Information architecture & navigation

Information architecture (IA) is how content is grouped, named and connected. A clear IA makes the site predictable: visitors understand where they are, where they came from and how to reach other relevant areas.

Key principles

• Few main sections, many internal paths. Top-level navigation should be simple; deeper links and cross-links provide detail.
• Consistent labelling. Menu items, headings and breadcrumb labels must use the same terminology.
• Visible structure. Breadcrumbs, section headers and side navigation help users understand context.
• Search and filters where needed. For larger catalogues or archives, good filters and search are part of design, not an add-on.

Sitemaps and navigation diagrams were part of every substantial project, even when the final site looked visually simple.

Layouts, typography & visual hierarchy

A web page must be readable in a few seconds. Users scan before they read. Layout and typography create a hierarchy that guides this scanning: what is primary, what is secondary, what can be safely ignored.

Layout guidelines

• Use predictable grids so elements line up cleanly across the site.
• Limit the number of distinct content widths on a page.
• Keep comfortable line lengths for text (usually 55–80 characters).
• Use whitespace intentionally to separate sections and emphasise key elements.

Typography & colour

• Define a small, reusable type scale (for example, H1–H4, body, small).
• Ensure sufficient contrast for body text and critical UI elements.
• Reserve accent colours for interactive elements and important highlights.
• Use consistent styles for links, buttons and informational messages.

The objective is calm clarity: the content should feel organised and approachable, not noisy.

Responsive behaviour & devices

Responsive design is more than shrinking content to fit a smaller screen. On phones and tablets, navigation, spacing and interaction patterns may need to adapt.

Practices we followed

• Mobile-first layout decisions. Start from the smallest viewport and progressively enhance for larger screens.
• Navigation that works with thumbs. Menus, buttons and tap targets sized for comfortable mobile use.
• Reflow, not random stacking. Columns and sidebars re-organised into sequences that still make sense when stacked.
• Testing on real devices where possible. Emulators are useful, but physical devices reveal performance and touch issues.

Performance was considered part of design: heavy images, unnecessary sliders and scripts were questioned early in the process.

Assets, content & collaboration with development

Web design is implemented in code. To keep sites maintainable, design decisions had to respect how CMS templates and components would be built and how content editors would work.

Working with developers

• Designing around realistic CMS structures, not around static mockups only.
• Using repeatable patterns (modules, blocks, components) instead of unique layouts everywhere.
• Agreeing on naming conventions and reusable classes where appropriate.
• Documenting how certain page types should be used and combined.

Preparing assets & content

• Providing image sizes and ratios that matched templates and performance goals.
• Ensuring copy length matched layout constraints (headings, teasers, summaries).
• Specifying fallback behaviours for missing or optional content elements.

The aim was to avoid fragile designs that looked correct only in a single, idealised scenario.

Practical checklists before launch

Before considering a design “finished”, we used simple checklists that combined visual and functional criteria.

Example checklist

• Is the main purpose of each key page obvious within a few seconds?
• Does navigation remain clear and usable from mobile to desktop?
• Are headings, buttons and links consistent in style and behaviour?
• Is text comfortably readable (size, line length, contrast, spacing)?
• Do important elements remain visible without scrolling on small screens?
• Are forms simple, labelled clearly and error messages understandable?
• Do pages degrade gracefully when images or scripts fail to load?

These checklists were not theoretical; they emerged from real support and maintenance work, where weaknesses in design became visible over time.