Systems of governments and big companies: GOV.UK, Carbon, Atlassian

GOV.UK Design System is the UK government’s system and a model of clear forms. IBM’s Carbon teaches order in data, and Atlassian’s teaches how to name tokens.

Three systems worth learning from

The systems of Material, Apple and Microsoft set the look of platforms. These three are of another kind: they explain best how to solve particular tasks. GOV.UK teaches how to make clear forms, Carbon shows order and data, and Atlassian gave a model of telling tokens.

GOV.UK Design SystemCarbon (IBM)Atlassian Design System

The UK Government Digital Service (GDS)

Idea

So that anyone can make a government service on the internet clear and accessible: components and patterns tested through research.

Tokens

Styles: layout, color, typography and spacing; the values are gathered in the GOV.UK Frontend package.

Components

Components (buttons, fields, tables) and, separately, patterns (how to ask for a name, an address, how to gather a form’s errors).

Accessibility

Components are stated to be accessible; the pages explain when a component fits and when it does not, and rest on research.

Openness

The content is published under the Open Government License v3.0 (except where stated otherwise); the code is open.

What to take

Forms: the label above the field, a hint, a summary list of errors, one question at a time. Plain language and a bold, visible focus.

When not to take it

As a ready look for a commercial project: its own guidance says that a service outside GOV.UK should replace its images and use another font. Take the rules, not the styling.

Open the system’s documentation (opens the system’s own site)

GOV.UK: when anyone must be able to use a site

GOV.UK is the single site of UK government services, and its Design System is maintained by the Government Digital Service (GDS). The reason everyone reads it’s that it grew out of a task: to make sure any citizen can complete a service on their own: an older person on a phone, a person with a vision impairment, someone who finds reading hard. So everything in it is tested by research, not by taste.

The system rests on open government design principles: start with user needs, do less, do the hard work to make it simple, make things open. The pages of the components explain when a component fits and when it does not, and refer to research.

It’s worth taking its rules for forms. Here are the most important, and each is confirmed on the system’s own pages.

• The label is always above the field and always visible. A placeholder doesn’t replace it: it disappears when the person starts typing, and not all screen readers read it out.
• A hint is a separate short sentence, with no links, tied to the field by the attribute aria-describedby.
• The attribute autocomplete tells the browser what data is being asked for (name, email, tel), and the browser will fill it in. It’s also a requirement of WCAG 2.2 (criterion 1.3.5).
• An error summary. If there’s an error, a summary is shown at the top of the main block, keyboard focus moves to it, and its links lead to the fields. The summary’s title is “There is a problem”.
• The message beside a field says what to do: “Enter your email address”, not “Invalid value”. In GOV.UK’s markup the word “Error:” sits before the message as a prefix hidden from the eye, for screen readers; in our exercise it’s visible, so that the meaning doesn’t rest on color.

Press “Send” in the form below, first in one mode and then in the other.

A summary and messages (as in GOV.UK) A red border only

Your name

A first name is enough

Email address

Send Clear

Press “Send” with the fields empty.

Check yourself: why doesn’t a placeholder replace a label?

It disappears when the person types, not all screen readers read it out, and its default color is usually too pale.

A word about the license. GOV.UK’s content is open under the Open Government Licence v3.0 (except what is stated separately), but its guidance for services outside GOV.UK is to replace the branded images and to use another font in place of its own typeface. Take the rules and the code, and make the styling your own. This is general information, not legal advice: read the license itself before you reuse anything.

Carbon: order and data

Carbon is IBM’s design system, and it’s made for business applications: tables, dashboards, forms of dozens of fields. Its foundations are the 2x Grid (a grid built on an 8-pixel mini unit), accessibility, color, content, icons, motion, spacing, themes and typography.

What is interesting in it for a beginner:

• Two type sets. “Productive” for dense working screens and “expressive” for pages that people read and look at. You can keep two modes too: a dense one for tables and a free one for storytelling.
• Themes. Four color themes: White, Gray 10, Gray 90 and Gray 100, from light to dark. The system shows how to build a dark theme without inversion.
• Data. Detailed pages on data tables and on how to draw charts: a good guide for when your site shows numbers.
• Openness. Carbon is open, and it has a guide to contributing.

Carbon is strict and businesslike. For the general public it will seem cold, but as a school of order in data it’s better than most.

Atlassian: tokens with names

Atlassian’s design system holds a single language for products such as Jira and Confluence. We need it for one thing: a model of how to name tokens. Its names are telling: color.text.accent.red, elevation.surface.hovered. They read left to right: property, role, state. From the name you see where the value is applied, and the color itself can be changed without rewriting the rules.

Atlassian’s spacing is a multiple of 8 pixels: space.100 is 8, space.050 is 4, space.200 is 16, space.300 is 24 pixels. The number in the name is a percent of the base step. You did the same thing in the lesson on hierarchy, only with a single number: now you can see what it looks like in a big system.

Check yourself: what does space.200 mean at Atlassian?

16 pixels: the number is a percent of the base step of 8 pixels (200%).

What to take, what to leave

System	Take	Don’t take
GOV.UK	forms, plain language, an error summary, a visible focus	the branding and its typeface
Carbon	the grid, two type sets, the rules for data	business density for a site “for everyone”
Atlassian	the way tokens are named, the 8-pixel step	the look of Atlassian’s products

Practice

Almost every project has a contact form on its site, and the main action often depends on it. Build it by the rules of GOV.UK: visible labels, a hint, autocomplete, a model of the error state with a summary. The error models are marked data-scaffold: they are there so you can see the right markup, and on the finished site errors will be shown only by a script (which you’ll write in the part on JavaScript).

What was wrong with 2014

In 2014 forms were painted in colors and the hint was put inside the field: that looked neat. Research on accessibility and usability showed the price: the label vanishes as you type, and the form doesn’t say what is wrong. Today the rules of GOV.UK have become common practice, and accessibility requirements lean on them.