Design System

Introduction

The Kindly Design System is our instruction manual for building websites. It doubles as a test bed where we can see in one place the impact of changes we make. We use the system to make our websites:

• fast
• accessible
• eco-friendly
• long-lived
• on-brand

Only one deliverable matters: the product itself, everything else gets thrown away when we ship. A moodboard and a vision are useful design artefacts, but we mainly design in the browser.

We respect that:

• the browser has sensible rendering defaults
• HTML elements are semantic
• semantics can be enriched by ARIA and Schema
• HTML and CSS are intertwined, e.g. stacking and grid containers
• the cascade is powerful when embraced
• resting, hover, focus and active states need designing
• elements are sized relative to other elements
• vertical bi-directional margins collapse

We design for the fewest capabilities first, e.g. the:

• smallest viewport (or even no viewport, e.g. a screen reader)
• coarest input method, e.g. touch or voice
• slowest connection speed, e.g. Wi-Fi on a train
• slowest device speed, e.g. a budget mobile phone
• fewest available Web APIs, e.g. a old browser

We then responsibly enhance the website as capabilities improve, e.g. as the viewport grows larger. To enhance responsibly we take into account the impact on:

• the planet
• code complexity
• accessibility
• speed

We also respect customer's preferences, e.g. for reduced motion or particular colour schemes.

We practise inclusive design and meet needs that are permanent, temporary or situational.

We put our work in front of customers early and often by:

• starting with customer needs
• testing regularly with customers
• iterating based on evidence
• releasing early

While keeping in mind the limitations of user-centered design.

For a healthy website and one that ranks highly with search engines, we adhere to Page Experience signals, including the Web Core Vitals.

We check that we achieve all this by using Lighthouse, and:

• running through the accessibility "additional items to manually check"
• making page titles unique and descriptive
• avoiding relying on colour or icons to convey important information
• enabling the viewport to be zoomed to at least 200%

Rules

We follow a set of writing, look, feel and coding rules to maintain consistency and create a coherent experience for customers.

Writing

To ensure everyone understands what we’re talking about, we:

• write in plain English
• write in an active voice
• write short, clear sentences
• have the most important information first
• define acronyms and abbreviations the first time they’re used
• explain technical and professional terms

We aim for a reading age of about 9. For technical and professional content, we aim for 12. We check the reading age of content using Hemingway.

When formatting our writing, we:

• use sentence case
• avoid use of bold
• use italics for general emphasis
• use bulleted lists when paragraphs have more than four points
• use words for single-figure numbers
• use double quotation marks for quoted speech
• only use the ampersand when space is tight
• write dates as 9 January 2018
• use the 12-hour clock, e.g. 10am and 2.30pm

Look and feel

We layer the look and feel on to the default styles of the browser.

Typography

We use:

• a Minor Third scale (with a base of 1em) for text size
• line heights relative to the font size, in ratios of 1, 1.2 and 1.5

To ensure readable type, we:

• limit line lengths to 60 characters
• increase the size of text and space on a shared scale as the viewport grows

We only set the font size on childless nodes to avoid compounding.

Colours

We generate our colours on a perceptually uniform scale using the Lab colour space.

We then represent these colours using HSL notation as this is the most human readable format currently available in browsers.

Colour assignments

We assign our colours to abstractions which we use in our elements.

To be accessible, we follow the standard convention that:

• unvisited links are blue
• visited links are purple
• focused elements are yellow
• errors are red

For consistency across dark and light themes, we use lighter colours for elevation.

• sunken
• background
• elevated
• input
• input-icon
• separator
• meta
• inset
• drop
• accent
• icon
• link
• visited
• active
• focus
• error

We use these colours in 5% increments of opaqueness.

Space

We size vertical space around text using the Minor Third scale, relative to the font size. Other space, we size (roughly) in powers of two, e.g. 2, 4, 8, 16 and so on.

Layout

We embrace the browser’s default of Flow Layout. We then responsibly enhance with layout modules like Grid, Flex and Multicol.

Code quality

We ship good quality code by:

• using GitHub Flow, i.e. always make a pull request
• using GitHub Actions for continuous integration and delivery
• formating our code with Prettier using the default settings
• linting our JavaScript with ESLint
• linting our CSS with Stylelint

We use Stylelint to enforce most of our Design System rules.

Elements

Elements are the building block of our websites.

Elements have a look, feel and behaviour that people expect, e.g. links are underlined and can be opened in a new tab, unlike buttons.

We use two types of elements:

• HTML
• Custom

HTML elements

There are over one hundred elements in HTML.

Content sectioning

We section content using the article, aside, footer, heading, header, nav, main, section, address and br elements.

Text content

We organise text content into blocks using the dl, ol, ul, li, dt, dd, p, div, hr, figure, figcaption, blockquote, q, cite and pre elements.

preformatted

Inline text semantics

We add semantics to inline text using the a, abbr, b, strong, code, data, dfn, em, i, kbd, mark, s, samp, small, span, sub, sup, time, u, var and wbr elements.

Image and Multimedia

We add images and multimedia using the audio, img, track and video elements.

Embedded Content

We embed other content using the embed, iframe, object, picture and source elements.

By combining the picture and source elements, we can offer:

• art direction
• alternative image formats, e.g. AVIF and WEBP

Scripting

We add dynamic content using scripting and the canvas, noscript and script elements.

Demarcating Edits

We demarcate edits using the del and ins elements.

Table Content

We construct tables using the table, caption, col, colgroup, tbody, td, tfoot, th, thead, and tr elements.

Forms

We build forms using the form, button, datalist, option, fieldset, input, label, legend, meter, select, optgroup, output, progress, and textarea elements.

We:

• only ask for information which is absolutely needed
• put required information first
• set the width to fit the information being requested
• add "(optional)" after labels of inputs that aren't required
• limit the number of fields on each page

We avoid:

• unnecessary words in labels like "Please" or "Enter"
• using button-like types on the input element: button, reset and submit
• using disabled states

When using a button, we:

• limit to one on each page
• use a verb, for example "Order"
• only use the accent colour

Interactive Elements

We add further interactivity using the details, summary and dialog elements.

Custom elements

There is a standard set of custom elements for interacting with websites that are understood by customers.

We build on top of these standards and conventions.

Navigation

We avoid using a back link element as this functionality is available in the browser.

Skip

We use this element so that keyboard customers can tab to the main content.

Menu

We use this element so that customers can move down into the main pages of the site.

Breadcrumbs

We use this element so that customers can move back through pages and orientate themselves.

Pagination

We use this element so that customers can move side-ways through pages.

Signpost

We use this element so that customers can move forward through content.

Promo

We also use this element so that customers can move forward through content, but it's promoted in more detail than with the signpost element.

Content

Call out

We use this element to call out content to customers.

Forms

Hint

We use this element to provide input hints to customers.

Error

We use this element to inform customers of a per-field error.

Error summary

We use this element to summarise a collection errors for customers.

Command

We use this element for secondary actions.