Build a small design system that keeps the company website cohesive
A practical design system makes it easier to keep structure, navigation, typography, accessibility and conversion consistent over time.

Category: Web Design and UX
A company website rarely becomes confusing in a single day. The disorder builds gradually: A new button gets a different colour, a campaign page uses its own headings, and the contact form handles spacing in a third way. Each change may seem reasonable on its own, but together they create a website that is harder to understand, maintain and use.
A small design system can help prevent this. It does not need to be an extensive library or a major technology project. For many Norwegian companies, a clear set of rules for page types, navigation, typography, colours, components and actions is enough. The goal is not for every page to look identical. The goal is for users to recognise how the website works.

What a small design system should solve
A design system is a shared source of truth for how the website should be built and developed. It connects visual identity with practical user needs. When an editor needs to create a new service page, they should not have to reinvent the structure, button style and spacing.
For a small or medium-sized company, the system should primarily answer these questions:
- Which page types do we need, and what is the purpose of each page type?
- How do users move between the main areas?
- What do headings, body text, links and buttons look like?
- Which colours can be used for information, actions and status messages?
- Which components can editors choose from?
- How do we ensure accessibility and clear conversion?
If the system does not answer these questions, it is probably more of a visual identity than a tool for web design.
Start by mapping what you already have
Before creating new rules, you should identify the variations that exist on the website. Choose a representative selection of pages: the home page, a service page, an article, a contact page, a landing page and, if possible, a form or product page.
Record the variations you find in headings, buttons, cards, form fields, background colours, icon use and spacing. Also include navigation elements such as the main menu, mobile menu, breadcrumbs and links in the footer.

It is common to discover several almost identical solutions. Perhaps the website has four shades of blue, three types of buttons and several ways of presenting a service. Do not choose a winner based on taste alone. Consider which variant is clearest, works best on small screens and is easiest to use with a keyboard and assistive technologies.
Define page types before individual components
Many people start with buttons and colours. It is more useful to start with page types. A page type describes the purpose of the page and the content elements it usually needs.
A simple model might consist of:
- Service page that explains the need, solution, approach and next step.
- Article page that provides professional guidance and directs users to a relevant service.
- Landing page focused on one target audience, campaign or enquiry.
- Contact page that makes it easy to choose the right way to get in touch.
- About us page that documents expertise, people and approach.
For each page type, you should describe mandatory and optional sections. A service page could, for example, always include a clear introduction, an explanation of the deliverable and a relevant next step. Customer stories or frequently asked questions could be optional.
This structure gives editors freedom within predictable boundaries. At the same time, it reduces the risk of new pages becoming long collections of random content blocks.

Make navigation part of the system
Navigation is not just about what appears in the main menu. A good system also describes how users find their way back, move forward and understand where content belongs.
Limit the main menu to the most important areas. Menu items should use words customers understand, not internal department names. If an item requires an explanation from an employee, it is probably not clear enough.
Also establish fixed rules for local menus, breadcrumbs and related links. An article could, for example, always end with one relevant service and a small selection of further reading. A service page could point to contact information, the work process or a relevant customer story.
Mobile navigation must be considered as a separate situation. Check that the menu button is easy to find, that submenus are understandable and that contact information is not pushed down behind too many choices. Do not assume that a compressed desktop menu will automatically work on a phone.
Create a typographic hierarchy that can handle real content
Typography should help users scan, understand and read. Define a limited number of text levels: page title, main heading, subheading, body text, standfirst, caption and, if necessary, small helper text.
Each level should have rules for size, line height, weight and spacing. Test with realistic text, including long Norwegian compound words. A heading that looks good with two short words can fall apart when it encounters an actual service name.
Body text must have good contrast and sufficient size. Lines should not be so long that readers lose their place. Use bold text sparingly, and avoid long passages in all caps. Links must be identifiable without users having to rely on colour alone.
Preferably choose only a few typefaces and styles. Many variations rarely improve communication, but they make the design harder to control and can affect load times.
Translate visual identity into functional rules
A brand colour is not automatically a good button colour. Logos, colours and graphic elements must be adapted to digital surfaces and specific functions.
Give colours clear roles. One colour can be used for primary actions, while others support backgrounds, information, notifications and errors. This prevents the same red from meaning both “submit” and “something went wrong”.
Also describe how images, illustrations and icons should be used. If authentic images of employees and working situations are an important part of the identity, the system should say something about cropping, lighting, subject matter and where the images should be used. This creates greater coherence than a random selection of images with the same colour tone.
A visual identity should also work when content is enlarged, when the page is used without images, and when higher contrast is needed. A recognizable brand cannot depend on weak colors or decorative details alone.
Standardize the components that affect conversion
Buttons, forms, contact cards, and calls to action affect whether users move forward. They should therefore be among the most carefully considered parts of the system.
Define one primary and one secondary button style. The primary is used for the page’s most important next step, such as requesting a quote or booking a call. The secondary is used for less committal choices, such as reading about the process. If everything has the same visual weight, it becomes difficult to choose.
Button labels should describe the action clearly. “Send inquiry” is clearer than “Click here.” Also ensure that links that look like buttons behave predictably.
For forms, the system should specify labels, help text, error messages, required fields, and confirmation after submission. Errors must be explained in text and associated with the correct field. Do not use only a red border as a signal.
Conversion is not necessarily about more buttons. Often, it is about reducing uncertainty: What happens after submission? How long does it take to receive a response? What information does the company need? Answers to such questions should be part of the component surrounding the action.
Build accessibility into the rules
Accessibility should not be treated as a final check. Build the requirements into every component. A button needs a visible focus indicator. A form field needs a persistent label. A menu must be usable with a keyboard. Text over an image must have sufficient contrast in all relevant crops.
Describe more states than the default situation. Components can be focused, active, disabled, open, closed, or display an error. If these states are not designed, they are often improvised during development.
Also test the solution with text enlargement and on narrow screens. Content should be able to reflow without buttons overlapping, text being cut off, or the order becoming illogical. This often improves the experience for everyone, not just users with permanent disabilities.
Document just enough for the system to be used
A design system has little value if it is understood only by the designer who created it. The documentation should be concise, visual, and tied to real publishing tasks.
For each component, it is often enough to show:
- What the component should be used for.
- When it should not be used.
- Which content fields it contains.
- A good example and a bad example.
- Requirements for mobile display and accessibility.
Appoint someone who can approve new variants. New components should only be created when an actual need cannot be met with what already exists. Otherwise, the system quickly grows back into the patchwork it was meant to replace.
Start small and prioritize what users encounter most often
You do not need to overhaul the entire website at once. Start with the main menu, typography, buttons, form fields, and the two or three most important page types. These are recurring elements, so making them consistent has a significant impact.
Then use the system every time a page is updated or rebuilt. Over time, a larger part of the website will follow the same rules without requiring a full redesign.
A good design system does not eliminate the need for judgment. It makes decisions easier and more consistent. Editors get clear guidelines, developers have fewer special cases, and users encounter a website that behaves as they expect.



