Cedar’s main benefits as a design system are in the reusability of its code, which increases our overall consistency and design and development efficiency. By distributing flexible atomic design system elements (Vue components, design tokens, CSS styles) we provide teams with all the tools necessary to create performant branded reusable components.
At times, you may have a specific use case where you feel Cedar is not providing the customization or support needed. This is normal, as a design system is not intended to distribute business logic, domain-specific styling, or other more complex UI elements. So what to do?
Reach out to the Cedar team on Slack: Contact us at #cedar-user-support or join our office hours to get 1:1 support. We’ll evaluate the issue and can help make changes in our system to better support you. This is the first and best option.
Build a reusable component: After talking with us, we may find the Cedar design system elements don’t satisfy the requirements for your application. At this point you may need to override Cedar directly or replace those elements with entirely new ones. Read on for further guidance on our shared standards for building reusable components.
When building a new component, we encourage you to keep these core principals in mind to create durable solutions that can easily be shared and maintained:
Consistent styles and interactions across channels builds trust with customers and improves overall usability. Designing with unity and consistency in mind enables our visual language to scale across an omnichannel experience.
Quality over quantity. Be deliberate about how you approach creating, building, documenting and maintaining components.
Provide options for a component to work under a range of circumstances. The design should be flexible enough to support different scenarios, while still specific enough to be useful.
Design to allow the addition of new capabilities or functionality. Create forward-compatible solutions that can be reused and extended in the future to make maintenance easier and help support speed to market.
Accessibility is at the core of how we design usable experiences for all. Every design, asset, and piece of code should meet or exceed WCAG 2.1 AA accessibility standards, and should include guidance for any necessary implementation details.
Build with reusability in mind:
Note that not every front-end element should be built as a reusable component. There is a maintenance cost associated with reusable components as they must be updated and released independently of your micro-site. If a component is infrequently used or is not sufficiently complex it may take more time to distribute and maintain it than it would to simply duplicate. Moreover, once a component is distributed and used by multiple teams it may become difficult to modify that component without impacting those other consumers.
There may be cases where the Cedar design system elements do not satisfy the requirements for your application, at which point you may need to override Cedar directly or replace those elements with entirely new ones. In such cases, all of the above requirements for reusable components still apply, in addition to the following considerations and risks: