Principles / design principles

Design principles

These five principles explain how DS by Berit is designed and built. Each one says what it means for designers, what it means in the code, and where you can see it in this system.

1. Principle 01 · Accessibility

   Everyone can use it

   This is accessibility (a11y). Every part of the system has to work for people with different needs, including people who use a keyboard or a screen reader and people who find small or pale text hard to read. Accessibility is built into each component from the start and is not a check added at the end.

   In design

   Text must have enough colour contrast against its background (at least 4.5:1), and colour must never be the only way to show that something is selected, wrong or unavailable. Buttons and links need a large enough touch target (44px) so that they are easy to hit with a finger or a pointer.

   In code

   Use the HTML element that matches the job (semantic HTML), so that browsers and screen readers understand it without extra work. Everything that can be clicked must also work with a keyboard, in a logical order, and must show a visible focus state while it is selected.

   In this system

   An error must be accompanied by an icon and text that explains the issue and how to fix it, rather than a generic warning or colour alone. The focus outline is yellow with a dark edge, ensuring high contrast on any background.

2. Principle 02 · Design-code consistency

   Design and code match

   A colour, size or space has the same name in Figma and in the code (design tokens), so designers and developers always talk about the same thing. The system keeps one source of truth, and the design and the code are both read from it instead of each holding its own version.

   In design

   Use the variables in the Figma file (design tokens) for every colour, space and corner instead of typing values by hand. Changes are made in Figma first, so the file is always the most up-to-date description of how the system should look.

   In code

   Use the same names in the code as in Figma, and update the code whenever the Figma file changes (design-to-code sync). When a value changes, it is changed in every place that holds it, and the documentation shows both the design name and the code name.

   In this system

   The text colour is named color/content/primary in Figma and --color-content-primary in the code, and both point to exactly the same value. The Colors page lists the raw values and the named roles side by side, so nobody has to guess which is which.

3. Principle 03 · Lean system

   Keep it small

   A small set of well-explained parts is easier to use than a large set of similar ones. Each new colour, token or component has to be really needed before it is added, because every addition has to be learned, documented and maintained (governance: reuse before you create).

   In design

   Before adding something new, check whether an existing part already does the job, and if it almost does, improve that part. Every part should have usage guidelines that say what it is for and when it should not be used, so that people can choose the right one without asking.

   In code

   Build with the tokens and components that already exist. When something is missing, add it to the system in a way that others can reuse, with its documentation, instead of solving it once inside a single screen.

   In this system

   The palette was reduced to two oranges and three dark greys, and the gradients to four, after it became unclear which shade to use where. Every remaining colour now has a note that explains what it is for.

4. Principle 04 · Semantic tokens

   Colours are named by their job

   A colour is chosen by what it is used for, such as text, page background or primary button (semantic naming), and not by how it looks. This keeps the meaning of a colour stable even when its value changes, for example in dark mode or in a future rebrand.

   In design

   Choose the colour for the job at hand, such as the text colour or the button colour, rather than a named shade like orange. The raw palette exists so that each colour value is defined once, and designers normally never need to use it directly.

   In code

   Reference a semantic token such as --color-content-primary and never a raw value such as a hex code. A value that already has a name must not be repeated anywhere else in the code, so that one change updates everything that uses it.

   In this system

   Dark mode works by pointing the same named roles at different values, so no component carries its own dark colours. This is why a component looks right in both themes without any extra styling.

5. Principle 05 · Plain language

   Say it simply

   Labels, messages and documentation are written in short, clear sentences that any reader can follow (content design, UX writing). When a technical term is needed, it is explained at the point where it appears, and the professional term is given next to the plain one so experts can scan quickly.

   In design

   Write text that tells people what is happening and what to do next, and avoid jargon unless the audience needs it. Where an expert term is the standard name for something, include it next to the plain description rather than replacing it.

   In code

   Give components, props and variables names that describe what they are, and place a plain explanation next to any value that is hard to read at a glance. Documentation should be understandable without already knowing the system.

   In this system

   A type value such as clamp(22px, 2.4vw, 32px) / 1.1 / 800 is followed by a sentence that explains the size range, the line height and the weight. The same rule applies to shadow values and to every grid and width value.