Design System: Infrastructure for Scalable Product Development

A design system is the operational infrastructure that lets an organization scale product development, meet accessibility regulations, and reduce technical debt over time. The component collection is only the visible part of it.

Moving from static style guides to living, code-based design systems changes how software gets built. For Norwegian enterprises, whether government agencies or fast-growing technology companies, a design system has become a prerequisite for delivering cohesive user experiences efficiently.

At PXL, we treat a design system as a technical product. Alongside the visual language, we build the production pipeline, governance model, and architecture that let the system survive contact with reality.

A design system is a collection of reusable components, guidelines, and tools that, when combined, enable building complex digital products with consistency and speed.

It differs from a style guide (which is static documentation) and a component library (which is only code) by binding these together with processes for governance and maintenance. A complete ecosystem typically consists of:

Design Tokens: The smallest atomic values: colors, spacing, typography, shadows, and animations.

Components: Pre-built code blocks such as buttons, form elements, modals, and navigation.

Patterns: Documented solutions to common tasks like authentication, error handling, and table displays.

Governance: Rules for how the system is developed, maintained, and distributed.

In Norway, NAV's Aksel and the Norwegian Tax Administration's design system have set the standard for how the public sector manages its digital commons.

Design Tokens are the foundation of a modern design system: a way of abstracting design decisions away from specific platforms.

Instead of hardcoding hexadecimal color codes (#0056b3) directly in an iOS app or a React component, we store the value in a platform-agnostic format (JSON), as defined by the W3C Design Tokens Community Group.

Our Automation Flow (DesignOps)

We implement an automated pipeline that eliminates manual work:

1. Definition: Designers update a color or font in Figma using Tokens Studio.
2. Versioning: The change is pushed to GitHub as a JSON file.
3. Transformation: A CI/CD process (often based on Style Dictionary) translates the JSON file into the formats developers need:
   • CSS Custom Properties for web
   • XML for Android
   • Swift for iOS
4. Distribution: The new values are automatically published as an updated NPM package.

This keeps design and code in sync. When the brand color changes, you update the token and the change rolls out to every application, with no search through thousands of lines of code.

For flexibility and accessibility, we often build on Headless UI principles. Rather than write keyboard navigation and screen reader logic from scratch, we use primitive libraries like Radix UI or React Aria.

These libraries deliver the functionality (the head) without the styling (the body).

Benefit: We get WCAG-compliant interaction "for free": arrow key navigation in dropdown menus, correct focus management, and screen reader support.

Freedom: We apply our own CSS (via Tailwind or CSS Modules) to match the brand 100%, without having to "fight" against pre-built styles from a framework like Bootstrap.

The EU's Accessibility Directive (EAA) tightens the requirements and hits the Norwegian private sector with full force from 2025/2026. Your design system is the most important tool for meeting them.

We work according to the principle of Compliance Inheritance.

It's inefficient for each product team to spend time testing whether a button's contrast is approved, or whether a form element has the correct aria-label.

Centralized Quality Assurance: We test every component in the design system with screen readers (NVDA, VoiceOver), keyboard, and automated tools.

Quality at Scale: When a product team imports <Button /> from the system, they automatically inherit all this quality. If the rules change (e.g., WCAG 2.2), we update the component centrally, and all applications using it are updated.

That cuts the risk of non-compliance and lets developers work on business logic instead of the fine print of WCAG. Read about how we help with accessibility statements and accessibility audits.

Building v1.0 is the easy part of a design system. Managing it over time is the hard part, and without a clear governance model the system either dies out or fragments beyond recognition.

We help organizations choose the right model based on team structure and maturity:

1. Centralized Model (Overlord)

A dedicated team owns the system completely. They build, test, and distribute everything.

Best for: Organizations that need extreme control and consistency (e.g., banking/finance).

Risk: Can become a bottleneck for product teams.

2. Federated Model (Democracy)

Representatives from various product teams meet regularly to make decisions and contribute code.

Best for: Organizations with high technical competence distributed across teams.

Risk: Can lead to inconsistency and slow decision-making.

3. Hybrid Model (The Nordic Way)

Our recommended approach for most Norwegian enterprises. A small core team (enabler team) facilitates the infrastructure and documentation, while product teams are encouraged to contribute components through a defined process ("Contribution Model").

This creates ownership across the organization while the core team keeps quality in check.

A design system is useless if no one knows how to use it, so documentation is where most people meet the system.

We set up living documentation platforms using tools like Storybook (for developers) and Zeroheight (for designers and product managers).

Interactivity: Developers can test components directly in the browser, change props (parameters), and copy the generated code.

Principles: We document what a component is, when it should be used and how, including "Do's and Don'ts".

A design system is an investment in efficiency. Studies show that developers spend up to 50% less time on UI-related tasks when they have a proper system in place.

The math is simple:

If you have 20 developers, and each of them spends 2 hours per week "reinventing the wheel" (coding a button, fixing a modal, adjusting colors), that equals one full year of lost productivity.

A design system removes this friction. It lets teams shift focus from "what should this button look like?" to "what value does this feature create for the customer?"

We follow the same process whether we establish a design system or professionalize one:

Technical and Visual Audit: We map the current state. How many variants of "blue" do you have? How many different button styles exist in production? This forms the basis for cleanup.

Token Establishment: We define the visual language semantically and set up the technical infrastructure for distribution.

Component Architecture: We build the core of the system (Core Components) based on modern React patterns (Composition over Configuration) and Headless libraries.

Piloting: We test the system in a real project so we know it solves problems teams actually have.

Scaling and Training: We roll out the system to the rest of the organization, hold workshops for developers and designers, and establish the governance model.

Is your organization ready to move from manual processes to industrial standards? We combine design system expertise with deep competence in UX design and service design so the system supports the entire user journey.