No Preview

Sorry, but you either have no stories or none are selected somehow.

If the problem persists, check the browser console, or the terminal you've run Storybook from.

What's a design system at Talend?

First, it is a collaborative in-house product. It has the same lifecycle as any product (it begins, it iterates, it tries to fit its customer’s needs etc…). It is collaborative because its customers are also its contributors.

What is that product? It is a shared design language and the tools required to “speak” that language.

  • Documentation: design guidelines (when to use a layout or a component, how, why?), UX writing guidelines, component guidelines... This is the ruleset of the language, the grammar: it insures the design has a single voice and is homogenous.
  • Libraries: a Figma component library and a React component library. These are the "words", the vocabulary of the design system. Using the components according to the provided ruleset ensures both homogeneity and an efficient, high-quality experience.
  • People: a core design system team. They are caregivers, maintainer of the design language. They help gather the customers' needs and plan for evolution of the product. They are not the primary productive force behind the language, but simply its curators.

Why do we need a design language?

  • Single source of truth: we have many products, many teams and individual designers. All of them could provide different "voices" creating an overall product that lacks unity. Gathering around a single ruleset ensures we all speak the same language.
  • Homogenised experience: following a shared design language, the different products forming the Talend Cloud experience will share the same behaviours and patterns. Every aspect of the product benefits from one another: when users learn a pattern once, that pattern will be understood across the whole solution. This also create a singular brand identity.
  • Industrialisation and cost / time reduction: producing shared libraries and following the same rules ensures work is only done once. No more duplicates. Time is spent once and everybody benefits. This enables all teams to spend more time on quality, refining the experience overall.
  • Maintainability: having a core team and a dedicated roadmap helps maintaining this large product. They help prioritize and dispatch the necessary maintaining work. Additionally, having gathered components into shared libraries also means that maintenance is only done once: there's no need to update components in a variety of project anymore.

As a design language, it is only relevant if it is a foundation, a baseline behind every facet of the Talend Cloud products (ideation, design, implementation). If it is not being used, then it's actively being destroyed: as a language it needs to be "spoken" to be real.

How to contribute?

Synchronising is contributing. The design system needs to be aware of the product suite's entire needs to ensure that its vocabulary (components) is large enough or that its grammar (patterns, guidelines) still matches the current needs.

Using the design system is contributing. Using it to build Cloud products is keeping it alive, making it relevant.

Promoting is contributing. Promoting its use as a foundation of all design and implementation work is a huge contribution. Normalising its usage, its knowledge amongst stakeholders (PMs, developers, product designers, C levels etc...) is ensuring the shared language spreads and stays relevant.

Helping refine the roadmap is contributing. We always need to plan the next step, to iterate on something or to produce new contents. The core team will suggest roadmaps, but the customers' needs define which is the right one.

Producing new guidelines and new components is contributing. When the design system product lacks something any Talend Cloud product requires, contribution is necessary. The core team then acts as a support team, providing help (code, design, doc) when needed and ensuring the latest addition to the design system fits the established language.

Giving feedback is contributing. The Talend design system is a living language: it must stay up to date to fit its customers' needs. Telling us what went wrong, what needs to change is a contribution to that goal.

Maintaining is contributing. There's always something to be done. The system is a product, it grows old and needs updating, changing, challenging.

Contributing components (new ones or iterations on current ones), even without being asked to contribute is contributing. The design system is not "the design system team's product". It's Talend's product. Nobody needs the core team's validation to work on it.

"Ask not what your design system can do for you. Ask what you can do for your design system".

You are part of the design system. It only gives back the amount of care you put into it yourself.

What to expect from us?

  • Feedback: a systemic approach relies on established and documented patterns. Think of it as an "if this then that" mindset. A cause creates an effect. We provide feedback and challenge new patterns in order to better document the language, extracting from real-life usage rules that can be followed elsewhere.
  • Guidance: we are kept in the loop across all the Talend Cloud products, providing us with some visibility on a larger scope. We use this to provide guidance for the shared language, balancing its diverse customers' needs.
  • Support: our time is dedicated to this product that is built for you. We are here to help you learn this language, use it and make it grow when necessary.
  • Curation: we provide a way to see the design system as a long-term product, "owning" its roadmap, ensuring its libraries are up-to-date. We act as a source of communication, facilitating design system work with other teams and promoting the language as a whole.