Discovery: design system

[skibinska]

I'm planning to review the existing design system documentation.

I'll add a list of the reviewed documents.

Wellcome design systems discovery report.pdf

Link to design system playback

---

Here is a high-level summary of some best practices for creating a design system, based on Nathan Curtis' work:

• Establish a clear purpose: Define the goals and objectives of your design system. It should provide consistency, efficiency, and scalability for your organisation's design and development processes.

• Involve cross-functional teams: Collaborate with designers, developers, product managers, and other stakeholders to ensure a holistic approach. This helps gather diverse perspectives and ensures the system meets the needs of all teams.

• Document guidelines and principles: Clearly articulate the design principles, patterns, and guidelines that govern your system. This documentation should be easily accessible and regularly updated to reflect evolving best practices.

• Start small and iterate: Begin with a core set of components and gradually expand the system based on user feedback and evolving requirements. This iterative approach allows for continuous improvement and avoids overwhelming teams with a large initial release.

• Design for flexibility and customisation: Provide a balance between consistency and flexibility. Design system components should be adaptable to different contexts and allow for customisation to meet specific project needs.

• Foster a culture of collaboration: Encourage open communication and collaboration among teams using the design system. This helps ensure that the system remains relevant, evolves over time, and is widely adopted.

• Establish governance and maintenance: Define roles and responsibilities for maintaining and evolving the design system. Regularly review and update components, guidelines, and documentation to keep the system up to date.

• Provide comprehensive documentation and education: Create detailed documentation and resources to help teams understand and effectively use the design system. This includes guidelines, code snippets, usage examples, and tutorials.

[skibinska]

Design Systems with React & Storybook - frontend masters course

• This course is a high-level introduction to design systems.
• Course docs
• Course slides
• The most useful chapters for me were "Foundations of Design Systems" and "Foundations of Design."

Useful information

Design system checklist

Before a component is considered complete, it must meet several design and development requirements:

Design Requirements:

• Accessibly

All users, regardless of circumstance, must be able to accomplish the same tasks within our product. Our designs must account for users with visual impairments and must ensure all facets are consumable.

• Interaction
  How should a component respond when a user interacts with it? Is there validation feedback that must occur? The interaction definition must be defined.

• Context
  How and where should this component be used? When should I use a link versus a tertiary button, for example?

• Completion
  Are all states, including neutral, hover, focus, and disabled, defined?

• Content
  What type of content does this component rely upon? Does it accurately embody the brand identity?

• Customisation
  Are aspects of this component customisable? If so, how? For example, if my design system serves multiple products, the primary button might have a different background colour for product A versus product B. We must define these customisable parameters.

• Resolution
  How does this component look on varying screen resolutions? How does the layout change?

Development Checklist:

• Accessibility
  In addition to an accessible colour palette, we must develop our components with semantic HTML elements in order to ensure compliance with assistive technologies. We also must account for keyboard navigation.

• Responsiveness
  Our components must respond to browser window resizing and varying screen resolutions.

• Completion
  Does this component account for all aspects of the design? Have we implemented a near pixel-perfect component?

• Customisation
  Have we implemented all of the customisable aspects of this component?

• Error Handling / Data Validation
  How do our components respond when something breaks? Have we incorporated type checking with React Prop Types or TypeScript to ensure our parameters comply with expected data types?

• Browser Compatibility
  Do the technologies we use work across all supported browsers or must we include polyfills?

Calculating priorities

[skibinska]

Design systems to check out:

IBM Carbon
Material Design
Firefox Photon
Lightening Design System
Polaris
Base Web
Chakra UI
Atlaskit
Material UI
design system repo

[skibinska]

Design system expert (mentioned by Amy and Heydon):

• Nathan Curtis

Medium articles to read:

Visual Style
UI Components
Documentation
Releases
Planning
Process
People and Teams
Systems of Systems

[skibinska]

Systems of Systems / Consolidating Design Systems

Compare and rationalise differences

1. Compare Libraries & Outputs

To start, compare features of visual style, UI components, and other categories. Identify what features exist, how they are disseminated (as code and design assets), and depth of documentation of each part.

2. Evaluate System Practices, Too

• People
• Processes
• Products

How Do We Consolidate? Pick a Path.

Option 1. Keep Both. Do Nothing.

Option 2. Keep Both and Start Sharing Subsystems.

• For features, converge foundations, even if design before code. Start with style (colour, typography) applied to essential components (buttons, forms). Do teams share a dependency on design tokens that are separated from any given component library? Be realistic that a single source-of-truth for front-end code and documentation probably come later.
• For people and process, increase collaboration across groups.
• For products, demonstrate proof of intent through willing teams on both sides without a mandate wide change all products now.

Option 3. Retire Both and Build a New System Together.

When two systems come together in a merger that is presented as equal, it can create difficulties. It becomes unclear how decisions will be made and everything is open for discussion. Without a significant restart to create a fair and fresh start, the process of combining the two systems can take a lot of time and effort. Additionally, making changes to each product will be a slow and lengthy process. Overall, this path is challenging and not easy to navigate.

Option 4. Keep One and Inherit Features From the Other

When we start using a new product, we expect it to have the same features as the product we were using before. We don't want any important components, features, frameworks, or supported platforms to be missing. While it is possible to remove some of these things, the product that remains will need to expand and offer more options in order to cater to a larger group of customers.

[skibinska]

Systems of Systems / Design Systems Architecture Diagrams

An interesting example of a design system implementation for various frontend libraries/frameworks is one that offers translation of its vanilla HTML and CSS library:

[skibinska]

Systems of Systems / Design System Tiers

a design system’s core is predictable: a visual style’s color, typography, iconography and space applied to components like headings, button, icon, checkbox, input, and others everyone obviously needs. Until you get the core right, you can't craft the sophisticated stuff with confidence.

[skibinska]

Process / Getting Developers Started with a Design System

A smooth onboarding is an essential moment in a product experience. That’s why an Getting Started as an Engineer is arguably the most important documentation your system publishes.

Getting Started for Engineers is not just positioned prominently on system’s homepage and in navigation. It should also be composed early as you iterate towards launch.

Tips on how to create a good documentation for developers.

[skibinska]

Process / Design System Communications

For design systems, outcomes that matter include:

• Adoption incrementally deeper over time
• Awareness of new, upcoming features
• Satisfaction through open participation
• Trust through inclusiveness and transparency
• Alignment with other objectives and programs
• Feedback to redirect focus
• Celebration of adoption and contribution

[skibinska]

Process / Design System UI is More Expensive Than a Product Team’s UI

Design Systems Include More Steps
In most design system programs, a workflow includes five or six top-level steps. From what it will Propose to Design, a team outputs Code, Doc, and Design Assets that it will predictably Release.

[skibinska]

Design tokens and visual style / Naming Tokens in Design Systems

[skibinska]

Documentation / Component Examples

Documentation shouldn’t be a treasure hunt. Don’t make readers work hard to see what’s important. Instead, show an example’s many states by default on the page without requiring interaction.

[skibinska]

Planning / A Design System isn’t a Project. It’s a Product, Serving Products.

For a design system to thrive and survive, it needs a sufficient level of management.

• Who’s making the decisions?
  Modern design systems have a product manager who’s driving decisions, assertively aligning with partners, and serving as the go-to person.

• Who’s doing the work?
  Sustaining a design system requires a significant amount of work, including design, development, writing, and other tasks. This work is typically carried out by individuals who are committed, dedicating at least a partial amount of their time (more than 4 hours per week) to the endeavor.

• Who’s paying for it?
  Long-term survival of a design system is nearly impossible without deliberate sponsorship that provides budget and properly allocates time for its maintenance and development.

• What are each of you working on right now and where do you record and prioritise things you might work on later? Many high-performing teams increasingly formalise into a backlog over sprints using tools like Github and Jira.

• What can your customers (products using the system) expect over the next 6–12 months?
  Communicating an effective and concise system roadmap to customers is powerful. It generates awareness, encourages discussion, instills confidence in the system's organisation, and builds trust that the system will meet their needs.

[skibinska]

How you will use the icon in your application will help inform the name you give the token. This is what is commonly referred to as a semantic token, it has specific meaning to your design system or application’s context. For example, avoid names like “chevron-down” (that simply describes the icon), instead try something functional (e.g. “select dropdown”) or something conceptual, like “down”. [...] For more on naming, check out Nathan Curtis’ excellent article on token naming.

How to apply design tokens to your icons