FAQ

About CDS

What is CDS?

CDS is Coop's shared system for tokens, components, and guidance used across digital products. It helps teams reuse proven solutions instead of solving the same UI problems repeatedly.

Who is CDS for?

Designers, developers, and product teams building Coop's digital products. If you're creating interfaces for coop.se, the Coop app, or any other Coop product, CDS is for you.

Does CDS define entire products or only shared UI?

CDS defines the shared layer: tokens, components, and guidance. Product teams use those to build their own flows and screens. Page structure, business logic, and product-specific decisions belong to the product, not to CDS.

Ownership and scope

What belongs in CDS and what stays in the product?

Rule of thumb: if it’s reusable across products, it belongs in CDS.

CDS contains reusable tokens, components, and guidance that can serve more than one product or team. Product-specific flows, business logic, and one-off UI stay in the product.

If something depends on routing, data fetching, search logic, business rules, or a single feature flow, it doesn't belong in CDS.

What's the difference between an app-specific and a shareable component?

An app-specific component lives in the product codebase. It may use CDS tokens and shared styling, but it solves a local need.

A shareable component is reviewed, documented, and published through CDS because it solves a reusable UI problem that shows up across most products.

Can product teams create custom solutions?

Yes. CDS is there to support product work, not block it. If the system doesn't cover a need, build the solution in the product using CDS tokens and accessibility guidance where possible.

If the same solution starts appearing across products, it may be a candidate for CDS.

Does CDS own product-specific UI?

No. CDS provides building blocks. Product teams own the screens and flows they build with them.

Components and patterns

How do I know if something should be a token, a component, or a pattern?

Rule of thumb: tokens name values, components name UI building blocks, patterns name repeated tasks.

Use a token when you're naming a reusable value: colour, spacing, radius, or typography. Use a component when you need a reusable UI building block with structure and states. Use a pattern when multiple components work together to solve a repeated user task.

If it spans multiple steps or decisions and needs guidance to be applied consistently, it’s probably a pattern, not a component.

When should I request a new component, and when should I extend one instead?

Rule of thumb: extend for a variant, request new for a new reusable UI problem.

Extend when the use case is a variant or configuration of something that already exists. Request a new component when there's no reasonable way to meet the need through existing ones, and when other teams are likely to need it too.

What do I do if a component I need doesn't exist in CDS?

Build it as an app-specific component using CDS tokens. If you think it belongs in the system, propose it in the CDS Support channel on Teams.

What should I do when CDS almost works, but not fully?

Start by identifying whether the gap is visual, behavioural, or structural. Small visual or content differences usually stay in the product. If the change affects the component's API, states, or reuse potential across products, raise it with CDS before extending it too far.

Can I use CDS components inside product-specific wrappers?

Yes. Product teams can compose or wrap CDS components with product-specific logic. CDS handles the shared UI layer. Product code handles data, business rules, tracking, routing, and feature-specific behaviour around it.

What should I prepare before proposing a new component?

Bring the use case, the problem you're solving, where it appears in the product, whether existing components were considered, and why they're not enough. A proposal is easier to review when it shows likely reuse beyond a single screen.

Tokens and styling

What are design tokens?

Tokens are named values for design decisions: colours, spacing, typography, border radii. Using tokens instead of hardcoded values means visual changes can be made in one place and applied consistently across products.

See Terminology for a short definition.

What's the difference between global, semantic, and component tokens?

CDS uses three levels:

Global tokens are raw values. They define the full set of possible values without any context.
Semantic tokens give those values meaning. Instead of a specific hex value, a semantic token says "this is the primary action colour" or "this is muted text."
Component tokens are semantic tokens scoped to a specific component, such as the background colour of a button in its hover state.

In practice, you mostly work with semantic tokens. Global tokens are rarely used directly.

Working in Figma and code

How do designers work with CDS in Figma?

CDS components are published as a Figma library. Use components from the library rather than recreating them locally. Apply semantic tokens for colour, spacing, and typography instead of fixed values.

Can I detach or override a CDS component in Figma?

Rule of thumb: don’t detach just to make it fit — raise the gap in the support channel (start at /docs/help) with a link or screenshot and what you needed to change.

You can, but do it deliberately. Detaching makes the component local and removes the link to future CDS updates. If you're detaching because the component doesn't quite fit, raise it with CDS. The gap may be worth resolving in the library.

How do developers consume CDS in code?

Consume CDS through the published package and follow the setup guide in the documentation. Use semantic tokens for any custom styles you write, and follow each component's usage guidelines for supported props and configurations.

What happens if Figma and code don't match?

Treat it as a gap to resolve, not something to work around silently. Check the docs first. The mismatch may come from an outdated Figma library, missing documentation, or a component that has drifted between design and code. Raise it with CDS if the docs don't clarify.

What does using CDS correctly look like in practice?

Use published components rather than recreating them. Apply semantic tokens rather than hardcoded values. Follow each component's documented use cases and accessibility guidance.

Using CDS correctly doesn't mean waiting on CDS before making progress. When the system doesn't cover a need, build the product-specific solution and raise the gap if it looks reusable.

Accessibility

How does accessibility fit into CDS?

CDS components are built to meet WCAG 2.2 AA when used as documented, but they still need to be used correctly.

Each component page explains what “used correctly” means for that component (for example labels, keyboard behaviour, focus, and supported states).
When you implement components at page and flow level, you still need to handle accessibility in the full composition (for example heading structure, focus order, error handling, and announcements).
As a designer, you still need to use components in the right context: apply semantic tokens and place components on the intended backgrounds so contrast stays accessible.

If something in CDS isn’t up to WCAG 2.2 AA, let us know in the CDS Support channel on Teams so we can fix it.