Design Systems: Walking the Line Between Flexibility and Consistency

Rate this content
Bookmark
The video discusses the intricacies of design systems, particularly focusing on balancing flexibility and consistency. It uses the ActionList component from GitHub's design system as a primary example. The talk explores how Shopify's Polaris and Material UI handle component flexibility differently. For instance, Polaris offers a tightly controlled config API, while Material UI allows extensive customization, including colors, borders, and icons. The video also delves into the concept of a slots-based API, where predefined slots like leading visual, text, and description are dynamically filled based on the child components used. It also highlights the importance of composable APIs in achieving a balance between control and flexibility, allowing developers to create complex use cases without breaking the API. Lastly, the video emphasizes the significance of considering the target audience, design culture, and product maturity when deciding on the level of flexibility for a component library.

From Author:

Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.

This talk has been presented at React Advanced Conference 2021, check out the latest edition of this React Conference.

FAQ

The speaker is Sid, who works in the design system team at GitHub.

The main topic is walking the fine line between flexibility and consistency in design systems.

Sid compares Shopify's Polaris and Material UI's Component Library to illustrate the differences in flexibility and consistency.

In Shopify's Polaris, alerts are called banners. They are rendered with a status (e.g., critical) and a title as props. The banner component controls the rendering, including style and actions.

Material UI allows more customization. It uses a severity prop (e.g., error), and you can import and use any icon, customize styles, and control the layout and contents within the alert.

The flexibility of a design system depends on whether it is built for a specific brand or for open-source use, the design culture of the organization, and the maturity of the products it supports.

The ActionList component is a versatile component used in various parts of GitHub, such as repo pages, dropdowns, and release panels. It allows for different configurations like dividers, destructive actions, and leading visuals.

A config-based API is more controlled and predictable but can be rigid. A composable API offers more flexibility and can handle complex use cases better by allowing components to be composed together, making the API more scalable.

A slots-based API is a design approach where different parts of a component (slots) are predefined, and you can fill these slots with specific child components, ensuring consistent layout and behavior.

Sid suggests using composition to allow flexibility without ejecting from the design system. This means creating composable components that can be combined to meet specific use cases while maintaining consistency.

Siddharth Kshetrapal
Siddharth Kshetrapal
47 min
22 Oct, 2021

Comments

Sign in or register to post your comment.

Video Transcription

1. Flexibility vs Consistency in Design Systems

Short description:

Hey, I'm Sid. I work in the design system team at GitHub. I want to talk about walking the fine line between flexibility and consistency. I have this alert that I've been looking at other design systems for inspiration, for API ideas, all of that. And I was looking at this alert and trying to build it with Shopify's Polaris and Material UI's Component Library. So this is how they differ. With Shopify, it's a tightly controlled config API, while Material UI offers more flexibility. The spectrum of flexibility depends on various factors such as the target audience, design culture, and product maturity. It's important to find the right balance for your component library. Thank you for coming to my talk!

Hey, I'm Sid. I work in the design system team at GitHub. I want to talk about walking the fine line between flexibility and consistency. So let's start directly with code.

I have this alert that I've been looking at other design systems for inspiration, for API ideas, all of that. And I was looking at this alert and trying to build it with Shopify's Polaris and Material UI's Component Library. So this is how they differ.

So with Shopify they call it a banner. So you render a banner and then it takes a status, in this case status is critical, and it takes a title. So it takes these props as config, right? So the title doesn't go in the child, it goes on the component as a prop. And then you have the action and you only say what is the action and what is the contents that go inside the action. You don't really get to pick the action per se. And the component takes care of where it's rendered, how it's rendered, what color, the border, all of that. So this is an example of a config API, which is very tightly controlled.

And in fact, if you try, I played around with this. When I tried to give a style tag, I tried to give it different class names. It doesn't accept any. This is what you get. And then when I tried to build the same thing with Material UI, they had a severity as well. They call it error not critical, which is all the same. But you could give it any icon you want. So I was able to import an icon from the Material icon and pass it. I could also give it different styles. So I could customize the border. And for the contents inside, I had to take the alert title which they export and take a button and try to make the button look exactly the way I want it. Plus the space in between, I had to do it with the margin in between the components. So that's just like a tiny example of how the flexibility can be so different between two components. Like if you compare the API of these, the Shopify one is super tightly controlled versus the Material UI one is you can customize basically anything you want. That kind of brings us to this line or this spectrum of flexibility where Polaris is probably somewhere here. So it's very opinionated. It's built for Shopify. It's not built for everyone. It has a very strict API and that leads to predictable and consistent outcomes. When you use that banner, you know exactly what's going to come out. But then it could become rigid and restricting for experimentation or different use cases.

On the other hand, the Material UI one is probably somewhere on the right edge. Maybe even all the way there. And that's because it's open source. It has an extremely flexible API because it has no context of where it will be used. So it needs to be flexible so that you can fit it in the product that you're building. And then of course, with so much customization, it can become messy and fragmented because, well, the component library doesn't have a lot of design decisions baked in. All of those lie in the product side of things. So taking this, it kind of is like, what is right for you? Where should your component library fall into the spectrum of flexibility? And the answer is that it kind of depends, doesn't it? Always. But this is what it depends on. It depends on is your component library built for a brand or is it built for open source? Which is like everyone. What's the design culture in the brand that you work for? Is it consolidated with a small group of designers or is it a bunch of independent teams that operate pretty much on their own? And even what's the maturity of the products that you're working on? Do you have established patterns or is it still early and it's more experimental, still playing around to find those patterns?

So the answer then basically is that it depends, right? Thank you for coming to my talk. Bye bye. But no, I tried to use these and tried to apply them to this component. This is an ActionList component inside an overlay.

2. ActionList Component and API Design

Short description:

This is an ActionList component with various variations used across GitHub. The API design journey explores the balance between control and flexibility. The menu can be created by passing items to the action list and defining the on select behavior. For different actions, a divider API is considered, with the option of using a specific text or a type. The ActionList.divider provides a good balance by hiding the implementation detail.

This is an ActionList component inside an overlay. And you'll see this spread across GitHub. There's a lot of variations of this, but this is a pretty involved component. So it has a bunch of variations. And this is some of them. So you see this on a repo page. Just to the side, you see this as options in a dropdown. You see these as in the releases panel. This is the releases one. You also see them as trying to select assignees or reviewers. So there's a bunch of... There's a lot of range in this component.

And I was trying to figure out what should the API look like, how controlled or flexible should it be? And let me take you through that journey, so that I can quantify what it depends means. So let's do this API exercise from the start. I'm building this action list. This is the issues page. And quick, quick warning for you, none of these designs are actually production design. These are all from an exploration. So if it doesn't exactly match the aesthetics of what you see on GitHub.com, that's actually intentional. This is all an exploration.

Okay, that out of the way, this is the menu that you see, and it has some styles. I think it has some keyboard interactions. Yep, there you go. So to make this menu, let's see, the simplest menu over here could be, you have an action list and you just pass it items, and the items are these options that you're going to do. And then on select, you do something with it. So you can call your own action depending on the string. It feels a little weird to do these actions based on just like the string content. Like if you say quote reply, this is what you get in return. So it feels weird to just act on a string. So maybe something like this is better where it's a config, it's an object, and then you can pass in your on select. So depending on the copy of that, you can also pass it what the selection should be. And that feels decent.

So we move on to the next use case where not all of these have the same actions. So some of these are based on action to, you know, like, taking it outside. Some of these are about the content itself. So edit and delete. And this is third, which is, you know, it's a report. It's a moderation thing. So we want to separate them with dividers and now what should the divider API look like? So I thought about it and I was thinking you already have text, should it be like a secret text, like a very specific text that you give. Like if you give me underscore divider, then I know how to put a divider or maybe it shouldn't do that at all. Maybe it should be a type, right? And all the other ones are type row and this is type divider. But then of course, you know, like is it small case divider, upper case divider, all of that. So maybe you should import it from the ActionList and then it's just a value on the objects with ActionList.divider type. And if you're already doing this, then maybe this is ActionList.divider, where, you know, ActionList.divider is an object that is an internal detail that knows how to render the divider. This feels like a good balance where we're hiding the implementation detail of divider. Nobody needs to know there's a type divider. All you do is put an ActionList.divider there. Feels good. OK, moving on. Next use case, some of these are destructive.

QnA

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Don't Solve Problems, Eliminate Them
React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Kent C. Dodds discusses the concept of problem elimination rather than just problem-solving. He introduces the idea of a problem tree and the importance of avoiding creating solutions prematurely. Kent uses examples like Tesla's electric engine and Remix framework to illustrate the benefits of problem elimination. He emphasizes the value of trade-offs and taking the easier path, as well as the need to constantly re-evaluate and change approaches to eliminate problems.
Using useEffect Effectively
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
Watch video: React Concurrency, Explained
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.
Managing React State: 10 Years of Lessons Learned
React Day Berlin 2023React Day Berlin 2023
16 min
Managing React State: 10 Years of Lessons Learned
Top Content
Watch video: Managing React State: 10 Years of Lessons Learned
This Talk focuses on effective React state management and lessons learned over the past 10 years. Key points include separating related state, utilizing UseReducer for protecting state and updating multiple pieces of state simultaneously, avoiding unnecessary state syncing with useEffect, using abstractions like React Query or SWR for fetching data, simplifying state management with custom hooks, and leveraging refs and third-party libraries for managing state. Additional resources and services are also provided for further learning and support.
TypeScript and React: Secrets of a Happy Marriage
React Advanced Conference 2022React Advanced Conference 2022
21 min
TypeScript and React: Secrets of a Happy Marriage
Top Content
React and TypeScript have a strong relationship, with TypeScript offering benefits like better type checking and contract enforcement. Failing early and failing hard is important in software development to catch errors and debug effectively. TypeScript provides early detection of errors and ensures data accuracy in components and hooks. It offers superior type safety but can become complex as the codebase grows. Using union types in props can resolve errors and address dependencies. Dynamic communication and type contracts can be achieved through generics. Understanding React's built-in types and hooks like useState and useRef is crucial for leveraging their functionality.
Debugging JS
React Summit 2023React Summit 2023
24 min
Debugging JS
Top Content
Watch video: Debugging JS
Debugging JavaScript is a crucial skill that is often overlooked in the industry. It is important to understand the problem, reproduce the issue, and identify the root cause. Having a variety of debugging tools and techniques, such as console methods and graphical debuggers, is beneficial. Replay is a time-traveling debugger for JavaScript that allows users to record and inspect bugs. It works with Redux, plain React, and even minified code with the help of source maps.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React, TypeScript, and TDD
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
Designing Effective Tests With React Testing Library
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Top Content
Featured Workshop
Josh Justice
Josh Justice
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
Master JavaScript Patterns
JSNation 2024JSNation 2024
145 min
Master JavaScript Patterns
Featured Workshop
Adrian Hajdin
Adrian Hajdin
During this workshop, participants will review the essential JavaScript patterns that every developer should know. Through hands-on exercises, real-world examples, and interactive discussions, attendees will deepen their understanding of best practices for organizing code, solving common challenges, and designing scalable architectures. By the end of the workshop, participants will gain newfound confidence in their ability to write high-quality JavaScript code that stands the test of time.
Points Covered:
1. Introduction to JavaScript Patterns2. Foundational Patterns3. Object Creation Patterns4. Behavioral Patterns5. Architectural Patterns6. Hands-On Exercises and Case Studies
How It Will Help Developers:
- Gain a deep understanding of JavaScript patterns and their applications in real-world scenarios- Learn best practices for organizing code, solving common challenges, and designing scalable architectures- Enhance problem-solving skills and code readability- Improve collaboration and communication within development teams- Accelerate career growth and opportunities for advancement in the software industry
Next.js 13: Data Fetching Strategies
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
Alice De Mauro
Alice De Mauro
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up