FAQs (Frequently Asked Questions) ​

Here are some of the questions we normally receive and the answers that might clarify them:

What is Zurich Design System (ZDS)? ​

Zurich Design System is a collection of reusable components and tools, guided by clear standards, that can be assembled to build branded digital products and experiences. It includes libraries for designers to produce UIs and code repositories for developers to implement those designs in both Web apps and native mobile apps.

How does ZDS fit into the Zurich ecosystem? ​

ZDS fosters collaboration between different teams and disciplines and establishes a common vocabulary. It provides internal and external teams with everything they need to build great digital products, while ensuring the finished products are on brand and look and feel like the original design.

Who builds and maintains ZDS? ​

There is a core team of designers and developers dedicated to building and improving ZDS. We also welcome and encourage collaboration with different teams to increase the systems visibility, remain transparent and push towards higher quality.

How do I gain access to ZDS? ​

If you are a designer, you can request access to the ZDS libraries using our form, check out the Get Started section in our documentation for the steps on requesting access to the libraries and further details.

If you are a developer, check out the Get Started section in our documentation for information on the ZDS code packages.

If you need additional support, you can reach out using our ZDS Teams Channel

Can we use the ZDS packages with our frontend or SSR framework (Angular, React, Vue, Next, Nuxt, etc.), CMS (Salesforce, Sitecore, etc.), or low-code framework (Mendix, Falcon, etc.)? ​

ZDS's DevKit uses web technology standards, so no extra libraries or tooling is required to use it in web contexts. Everything runs in vanilla HTML/CSS/JS, we only add tooling and interfaces on top for better integration. The different packages and outputs of the ZDS's DevKit are design and tested to work, not only with the main frontend frameworks, but they have been also reworked to be integrable with the development tools used across Zurich.

For low-code platforms like Mendix, we've even developed a platform specific components and utils so they can be easily used. So, as a summary, we provide solutions that work with every web-based stack and even for native development frameworks (like React Native), and when a it comes to DX for an specific framework or platform, we can always create an adaptation to your needs.

Can we stick to an specific version of the ZDS when we are using it? And check the documentation for that previous version? ​

The new DevKit approach is fully versioned. Not only for the packages, but also for the documentation and assets provided from our CDN. So you can stick to your preferred version. Also, we have mechanisms to use newer components with older versions of local installations, so even when we don't recommend it, you can have components of different ZDS's versions.

Is it difficult to migrate to the ZDS from the previous WebSDK or our own "design system"? ​

ZDS uses it's own approach when it comes to the implementation of the guidelines and components. This one it's completely different to the old WebSDK one and for very good reasons. That's why they have no continuity. This means that you will require to change the components. But there are some things to consider:

  • Both libraries can coexist in the same project, since they don't overlap, so the transition can be gradual, component by component.

  • The new documentation, the TypeScript support (even if your project has no TypeScript), and JSDocs in-code documentation make the implementation of the new components way easier.

  • The new components are compatible with almost every framework used inside Zurich, so you can also gradually migrate to ZDS from your own team's components library or previous styling. A clear and polished API for each component make them really easy to being integrated, since this tries to be as close as possible to the native component API, but hiding the complexities for browser support, accessibility, optimization, customization, and so on.