What components go into the Design System? A set of rules

[gfellerph]

The Swiss Post Design System enables project teams to create seamless user experiences across all digital touchpoints by providing patterns, guidance and tooling.

– Swiss Post Design System mission statement

In other words, the Design System is standardising the way UI is designed and built at the Swiss Post. This guide describes criteria that components (and patterns) must match, before they can become a standard. A Design System operates at the lowest speed on the pace layer chart (https://bigmedium.com/ideas/design-system-pace-layers-slow-fast.html).

Design Principles

New components must follow our Design Principles.

Easy to use

A component must follow the five elements of usability: Effectiveness, Efficiency, Engagement, Error Tolerance and Ease of learning.

Trustworthy

A component must be robust, well tested and comprehensively documented.

Inclusive

A component must be usable by people with diverse abilities, access to technology, literacy, economic circumstances, educational backgrounds, geographic locations, ages and languages.

Cordial

We approach our customers on equal footing. By aligning our communication patterns with the Posts’ guidelines, we ensure that our interactions mirror how Post employees engage with clients: cordially, courteously, anticipatively, and empathically.

Design rules

[TBD]

Development rules

Desing System components enable the organisations to access their potential in re-using UI components across different applications and teams.

• A component must be reusable across multiple applications and teams
• A component must be composable. It should be possible to combine components or use them in different contexts of an application
• A component should not be similar to an already existing component because this creates confusion over which to choose in what situation
• A component must be responsive (min. 320px to at least 1920px screen width)
• A component must adhere to the current WCAG specification
• A component must be framework agnostic
• A component must work independent of context
• A component must work in all specified Browsers and within the specified version range (https://github.com/swisspost/design-system/blob/main/packages/styles/.browserslistrc)
• If a component can be implemented with HTML and CSS alone, there has to be a HTML/CSS variant
• A component needs to have a visual regression test, interactive components need to have end to end tests and helper functions need to have unit tests

[oliverschuerch]

I disagree with the point "If a component can be implemented with HTML and CSS alone, there has to be a HTML/CSS variant".
Would change to "If a component is describing a native element, there has to be a HTML/CSS variant"
In my opinion, all custom components should be available as web-component only.
This means (for example):

• less work for us
• less documentation work
• less maintenance tasks
• less testing cases
• less confusion for consumers
• ...

[gfellerph]

Web components have limitations. If for some reason they can't be integrated into a project, the HTML/CSS component will serve as a valuable fallback (happening on Post Portal side at the moment). Having an alternative would also enable us to create web components that cover 80% of use cases and if anybody is not happy with that, they can always fall back to a more bare bones approach.

So, having a fallback enables us to:

• Create components faster because they can be simpler
• Iterate on components, adding new features later
• Possibility to re-use styles for both versions (not always possible)