Extended Systems

What is an Extended System?

An Extended System is a custom library of components and patterns built with Canvas building blocks, which lives outside of Canvas. These are generally created, documented, and maintained by the team (or teams) who create it. They cater to the individual contextual needs of the user, and account for the products area’s tech stack and technical limitations. The components in the official Canvas Figma libraries and Canvas Kit code repository have been created to be as universal, flexible and scaleable as possible. This means they can be of most value to the most amount of teams using them.

Extended Systems may be created for a variety of reasons, usually to serve a more tailored, specific experience in a product area or for a technological need. New custom components should be composed using Canvas tokens and components where possible. These can be simple components (generally more shareable) or highly-tailored components (generally less shareable).

Check out our Step by Step guide to creating your own Extended System. Feel free to reach out to the team on the #canvas slack channel too.

Extended Systems start with the creation of custom components and patterns. If you need to create custom components for your product which don’t already exist in Canvas design libraries or Canvas kit, check out our guidance for creating custom components with Canvas and creating custom Figma libraries.

Note: due to the composable and flexible nature of React, Extended Systems is a concept generally reserved for teams building in React. While the overall set of Standard Tooling widgets/components/patterns can be seen as its own Extended System, product teams working with metadata-driven UI are generally not able to create their own Extended System.

Types of Extended Systems

Product Extended Systems

These systems exist to serve a particular product area or areas. For example, Workday Learning has a custom library of components tailored to their product’s need. These components have been made with Canvas as a foundation, but are specifically tailored to Learning’s needs. However, as these systems grow, they can also be useful to other products, particularly when multiple products share a similar interface concept (e.g. a toolbar). In this case, components can be shared between products, or the ownership of and maintenance of the Extended System can be scaled to multiple product teams.

Alternatively, some custom libraries may be more self-contained within a particular product area. So they may have a central library which serves multiple related products within that particular domain. For example, a product team might have a suite of components which they share only with other teams within their own product area, but not teams outside of this product area.

Generic / Universal Libraries

Some product teams build an Extended System that ends up being used by many other teams. Eventually, these are often abstracted outside of the original product, for general use. The examples below are created and maintained outside Canvas Kit, but use Canvas Kit for the basis of their components.

For example:

• WD Components is a component library that composes Canvas Kit tokens and components to support products built with React. It provides Workday-specific UI elements that are either too complex/composed to go in Canvas, or are too tied to Workday business logic.

• UI-C Features UI-C Features contains components built in React for Standard Tooling, as the metadata-driven platform slowly transitions away from GWT/UI-HTML.

• Productivity Technology Charts is just one data visualization library that exists at Workday

Anthology

Anthology is the curated collection of Workday’s UI Storybook stories - a Storybook-of-Storybooks, if you will. It will help you:

• Search for and discover available React components from many products and Extended Systems
• Improve awareness and communication between you and your development teams
• Share components between teams to encourage reuse over rebuilding

Essentially, its goal is to foster a community model for building and maintaining components at Workday by encouraging maximum visibility, code sharing between products, duplicate management, and more. Discover how to Add your Extended System. For discussions and more info, join the #anthology Slack channel.

How to Create Your Own Extended System

The needs of each Extended System will vary depending on a number of factors. As you build your system, consider details like:

• Who will use my system? (my team, or beyond)
• How generic/reusable should my components be?
• What can I do to save my team time in their day-to-day?
• Where can I introduce process and systems-thinking to provide a stable, maintable source of truth for my product?

Getting Started

1. Connect to and use Canvas as much as possible

Perhaps the most important aspect of creating a successful extended system is to opt for reusing Canvas components and assets over rebuilding custom. Every time you choose to reuse something from Canvas, you reduce the cost of maintaining your own system. This gives you more space to focus on the custom UI you need to evolve your product(s) in ways you need. It’s less about giving up creativity and expression and more about providing focus where you need it.

Similarly, engineers can import Canvas Kit into their repositories. This allows them to reuse existing components, assets and styling tokens. Opting to use components in Canvas Kit means teams can build UI more efficiently while also reducing their maintenance costs. You should take the opportunity to build on top of, or compose existing Canvas components, behavior, etc. wherever you can.

Before creating new components, review what’s available in Canvas already. Reach out on the #canvas channel to see if similar components exist or are in the works.

2. Create New Components

Check out our guidance for creating custom components. Maintain connection with Canvas when creating new components for both design and engineering. And remember, even though you’re building something new, it doesn’t mean you need to start from scratch. You can use Canvas tokens to style your net new components and leverage Canvas building blocks like buttons and inputs where possible. This will also help to future proof your designs and make the most of Canvas for maintenance and support.

3. Create a Standalone Code Library

Extended Systems built with Canvas tend to have a custom code library containing the new components they are building. This provides a centralised resource for the product teams to import these components from a single source.

We recommend using Storybook, which is a framework-agnositc web application that showcases components outside of a product application context, similar to a UI library. There are alternatives, but Storybook is the most popular and most widely used at Workday. Storybook makes it really easy to develop components in isolation, without having to worry about impacts from the rest of your product. Using Storybook v6 or higher also means it is compatible with Anthology, which will increase discoverability.

4. Contributing Assets to Canvas

New icons and illustrations which are created for your custom use should go through the Canvas contribution process. This will add your assets to the respective Canvas library so you can pull them from a shared single source of truth.

5. Contributing Components Back to Canvas

If suitable for general use, you may be able to contribute your custom components back to Canvas. Components best suited for Canvas contribution can be used in any application without specific product or Workday assumptions encoded into the component. The more tailored and specific the component, the less universal it tends to be.

Some aspects that make for good contribution:

Reusable

Simple

Agnostic

6. Share Components with Other Teams

Sharing components between teams can be an effective way to create cohesion, collaborate, and reduce the cost of maintenance. This is possible for teams with a common technology stack (e.g. React, Standard Tooling, or some combination). This can be accomplished in two ways: centralized and ad hoc sharing.

Centralized sharing: Two or more teams pulling from a single code source outside of Canvas to use new components. E.g. Team A and team B both pull from source C, a centralised library created and maintained by one of the teams. This is the preferred approach, provided both teams can agree on the overall design, functionality and API of the component.

Ad hoc sharing: Two or more teams create duplicates or branches of each other’s code in a way to leverage existing work when the centralized sharing approach is not possible or appropriate. This approach may require refinement or rework on the part of the receiver. E.g. Team A copies team B at a point in time and ‘owns’ the maintenance of their instance going forward. This is less ideal and should be avoided if possible, as the components can diverge over time, and it introduces duplicate components which can be confusing for users and other designers/engineers.

7. Ongoing Maintenance (Ownership & Governance)

Extended Systems are owned and maintained by the team who created them, with the execption of contributed components back to Canvas. Generally, the majority of custom components created for specific needs remain under the governance of the team who created them, or by multiple teams if they are in collaboration.