This style guide documents the core visual and UI patterns used across the site and other digital applications of the brand. It exists to keep design and front-end implementation consistent as the project grows, and to provide a shared reference for layout, typography, components and interaction patterns.

This is a living document. It will evolve over time as the site develops, with patterns refined, added or retired in response to real-world use and ongoing iteration.

Typography values are documented using rem units, relative to the project’s root font size. The samples below describe the intended type scale and hierarchy. Responsive adjustments may apply where required, but proportions remain consistent.

The core brand palette — used most prominently across identity, layout and key brand moments.

Supporting tones used for contrast, depth and subtle backgrounds without overpowering the primary palette.

Context colours used for consistent UI feedback (success, error, warning, info). Aligned with Bootstrap states and WooCommerce notices.

These guidelines outline how colour should be applied across the interface to ensure clarity, consistency and accessibility. They complement the palette definitions above and apply to all UI components and content.

Buttons provide consistent calls to action across the site. Variants signal hierarchy, sizes support different layout densities, and icon patterns improve recognition of common actions.

Core button styles used for primary actions, supporting actions, and low-emphasis link-style actions. Micro buttons are included here for lightweight UI controls.

Size helpers adjust padding and type scale to match the context while maintaining consistent styling.

Icons reinforce meaning and improve scanning for common actions. Where clarity is required, icons should be paired with visible labels.

Context colours are used for system actions and feedback. They should remain purposeful and not replace the primary hierarchy.

Hover and focus states provide interaction feedback. Focus styles should remain visible for keyboard users and must not be removed.

Forms are presented in two visual styles — standard (light) and inverted (dark) — with an optional validation layer for forms that require structured input. The examples below show the same field set in each style so layouts and spacing remain consistent across the site.

Use validated forms for submissions that must be complete and correctly formatted (e.g. contact forms, applications, account actions). Standard forms may be used for simple filters or non-critical inputs.

Validated forms use a lightweight, bespoke validation system. Validation rules are declared on a .form-parent wrapper using data-* attributes. Errors appear beneath the field, and a summary can optionally be displayed at the top of the form when submission is attempted.

• Required — data-required="true"
• Type checks — data-type="email", url, digits
• Minimum characters — data-minlength="6"
• Maximum words — data-maxwords="20"
• Confirm matching fields — data-password-confirm="field_name"
• File validation — data-file-types="jpg,jpeg,png", data-max-size="2097152"

Validation runs as users type or change fields, and again on submit. Visual feedback is applied to the .form-parent wrapper, keeping individual inputs clean and consistent.

In addition to full form layouts, the system includes a set of compact and minimal control styles designed for lightweight interactions. These are typically used where an input supports an interface action rather than representing a complete form.

Images automatically adapt to the device they are viewed on. Smaller image files are served to smaller screens, and larger files only where needed, helping pages load quickly without sacrificing visual quality. On upload, images are processed into a range of sizes and modern formats (including WebP) so browsers can choose the most efficient version available.

Video follows the same layout logic as images, using fixed or fluid ratios to maintain visual rhythm across layouts. Posters are used to ensure a clean, intentional appearance before playback.

Media is optimised automatically for performance. Images are resized on upload and delivered in the most appropriate size and format for each device, reducing page weight and improving load times without any manual intervention.

The preferred pattern is .src containing an <img>. The container controls the aspect ratio and cropping; the image fills the container using object-fit: cover. This is the default for most components and CMS output.

Ratio classes define consistent cropping across the site. Choose a ratio based on layout intent: hero/wide (16:9), editorial landscape (4:3), portrait (3:4), square (1:1), or specialised banners (27:10).

Captions can sit beneath media (recommended) or, where space is tight, as an overlay banner inside the container (.imagebanner.bottom). Use banners sparingly to avoid obscuring imagery.

Images can optionally open in a lightbox overlay or use a subtle zoom affordance on hover. These behaviours are applied explicitly and should be used intentionally depending on context.

Lightbox and zoom are independent: lightbox controls interaction, while zoom is purely visual. They may be combined where appropriate.

Video follows the same layout rules as images, maintaining consistent ratios and cropping across layouts. Videos are wrapped in .video-control and can use the same ratio helpers.

There are two common uses:ambient video (decorative, silent, looping) and content video (user-driven playback). Choose whether controls are shown based on intent — if the video conveys meaning, it should be controllable.

Cards and tiles are both flexible content containers used to present images, text and actions in grids, carousels and layouts. The distinction is primarily conventional: cards are typically used for repeatable content previews (projects, posts, people), while tiles are often used for layout-led or promotional content.

In practice they are interchangeable. The choice is driven by context, visual intent and consistency within a layout. This section documents common card types first, then the shared anatomy that keeps grids scannable and stable.

In most builds, card styling is grouped by content type (e.g. .card-project, .card-news, .card-person). This keeps browsing patterns consistent and avoids one generic card drifting into lots of inconsistent layouts. Even when types differ, the underlying structure remains stable so grids still align.

Most cards follow the same structure: media at the top, a title block, optional meta, a short summary, and an optional footer row. Keeping the anatomy consistent makes grids easier to scan and keeps layouts stable.

Variants adjust layout behaviour (not to reinvent the pattern). Where possible, keep the same anatomy and only vary what’s required: ratio, meta placement, and hover treatment.

Cards are rarely used in isolation. They typically appear in structured collections that influence how they behave, how much content they can hold, and how predictable they need to be.

Tiles are layout-led content containers used for promotions, navigation, and feature panels. They are typically more “graphic” than cards: fewer metadata fields, stronger visual emphasis, and more deliberate text placement over media.

Tiles can be image-led or use ambient video as a background. Where text sits directly on media, use overlays or fades to protect readability.

A tile is usually a single clickable container with media underneath and one or more overlay content blocks. You can place multiple .tile-content elements (e.g. headline top-left, CTA bottom-left).

Tiles are layout-led containers rather than rigid components. Unlike cards, they are not tied to a single anatomy or content type. A tile may act as a hero, a promotional panel, a navigation entry, or a visual divider between sections.

Text, imagery, and interaction are intentionally flexible. A tile may contain a single headline, multiple blocks of copy, a call-to-action, or no text at all. Typography, colour, and hierarchy are chosen based on the image or video behind it, not by a fixed template.

Placement is controlled by positioning patterns rather than predefined layouts. Content can be aligned to any edge or centred, layered over imagery, or split into multiple regions within the same tile. Large tiles may span the full viewport width, while smaller tiles may sit alongside others in a grid.

Tiles can use ambient video as a background (silent, looping). Treat this like “moving imagery” — overlays and fades are often required for text contrast.

Mini image carousels are used for compact image clusters (landing sections, side-by-side content blocks). They are typically image-led and lightweight.

This is the default browsing pattern for projects/news/products: a full-width carousel containing cards. Cards should keep predictable ratios and summary lengths so the carousel feels stable as content changes.

Tile carousels are more layout-led and promotional. Use them for highlights, campaigns, or editorial moments. Keep copy brief and ensure readability with overlays/fades where needed.

Modifiers change how a carousel feels (arrow size, placement, dots, hover behaviour) without changing the content inside it. The examples below are intentionally plain so it’s easy to compare treatments.

Slick has a lot of options — we intentionally keep to a small set of modifiers so carousels remain consistent across the site, and different carousel modules can sit on the same page without feeling like separate UI systems.

When you have spare horizontal space (especially in grids), arrows can sit outside the carousel so they don’t cover content. This is one of the most common treatments for card/thumbnail carousels.

Layout is based on Bootstrap’s 12-column grid. Most pages are built from containers, rows and columns. This section is visual: it shows how common container types behave and how columns map to the 12-column grid.

We keep this overview focused on horizontal layout (columns and gutters). Height/flex alignment is handled case-by-case in component sections (cards, tiles, forms).

Containers control page width and side padding. In our builds we typically use: .container (standard), .container-fluid (full-width with gutters), and .container-full (full-bleed, no side padding).

Columns are defined in 12ths. Responsive classes (e.g. col-12 col-md-6 col-lg-4) let layouts reflow as the viewport changes. The demo below simulates that behaviour.

This guide documents the core components and interface patterns currently used across the site. It focuses on established, repeatable elements that support layout, content and interaction.

Not every possible pattern is included. Components are documented once they are stable, well understood, and in regular use. Other interface elements may exist elsewhere in the site or evolve over time, but are intentionally omitted here until they are considered part of the core system.

Planned additions

This section will evolve over time as patterns mature and are promoted into the main body of the guide.