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:
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
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%
We follow a set of writing, look, feel and coding rules to maintain consistency and create a coherent experience for customers.
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.
- 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.
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.
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.
We use these colours in 5% increments of opaqueness.
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.
We embrace the browser’s default of Flow Layout. We then responsibly enhance with layout modules like Grid, Flex and Multicol.
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 CSS with Stylelint
We use Stylelint to enforce most of our Design System rules.
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:
There are over one hundred elements in HTML.
We section content using the article, aside, footer, heading, header, nav, main, section, address and br elements.
Address line 2
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.
- List item 1
- List item 2
- List item 3
- List item 1
- List item 2
- List item 3
- Description list title 1
- Description list details 1
- Description list title 2
- Description list details 2
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.
This is a link.
This is underlined .
This text has a strikethrough.
This is emphasised.
And this is strong.
This is in italics.
And this is in bold.
The mark element indicates a highlight.
The app said: Eat your veggies.
Small is for legal.
The chemical formula of water: H2O.
This text is superscripted.
A simple equation: x = y + 2.
Type the following in the Run dialog: cmd.
This is code:
var i = 0;.
Image and Multimedia
We add images and multimedia using the audio, img, track and video elements.
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
We add dynamic content using scripting and the canvas, noscript and script elements.
We demarcate edits using the del and ins elements.
This text has been deleted, here is the rest of the paragraph.
Normal text and
We construct tables using the table, caption, col, colgroup, tbody, td, tfoot, th, thead, and tr elements.
|Table head 1||Table head 2|
|Table body table data 1||Table body table data 2|
|Table foot table data 1||Table foot table data 2|
We build forms using the form, button, datalist, option, fieldset, input, label, legend, meter, select, optgroup, output, progress, and textarea elements.
- 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
- 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
We add further interactivity using the details, summary and dialog 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.
We avoid using a back link element as this functionality is available in the browser.
We use this element so that keyboard customers can tab to the main content.
We use this element so that customers can move down into the main pages of the site.
We use this element so that customers can move back through pages and orientate themselves.
We use this element so that customers can move side-ways through pages.
We use this element so that customers can move forward through content.
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.
We use this element to call out content to customers.
We use this element to provide input hints to customers.
We use this element to inform customers of a per-field error.
We use this element to summarise a collection errors for customers.
There is a problem
- Enter your full name
- Select your preference
We use this element for secondary actions.