Applying Product Thinking Principles to your Design System

Rate this content
Bookmark
Slides

You've planted the seeds of your design system. Maybe you've built out a few components and set up a basic Storybook. But where do you go from here?


It can be easy to let your inner perfectionist take over and try to cover every scenario and edge case, especially when referencing established design systems. However, a more effective approach is to treat your design system as a product that grows and evolves with your users. Ultimately, its value lies in the problems it solves and the needs it meets.


In this talk, I’ll explore how to apply product thinking principles to your design system, interweaving examples from my own experience as a design system engineering lead.

6 min
12 Dec, 2023

AI Generated Video Summary

Today's Talk focuses on applying product-making principles to design systems, emphasizing prioritization, MVPs, and metrics. It highlights the importance of understanding user needs and business goals through research and data collection. The Talk also emphasizes the iterative process of building components, gathering feedback, and iterating based on user validation. Lastly, it stresses the significance of measuring progress with metrics to track usage and adoption, and to demonstrate the impact of design system efforts.

1. Introduction to Design System Principles

Short description:

Today, I'll be talking about applying product-making principles to your design system. A design system is not just a collection of components, but a product that solves problems. The principles I'll focus on are prioritization, MVPs, and metrics.

Hi, everyone. My name is Raymond and I'm a front end engineer based in San Francisco. Today, I'll be talking about applying product-making principles to your design system.

So, this is you. You are a front end engineer building out your company's design system. You have a basic storybook set up and a few components built, probably a button. Everyone always starts with a good old button. Where do you go from here? You start Googling notable libraries, bootstrap, material UI, ant design, chakra, blueprint, the list goes on. You see a ton of components, variants, props, etc. You think you need to build all this and start to feel overwhelmed. You start sweating. Has this ever happened to you? It's definitely happened to me but what's helped me is reframing how I think about a design system. It's not a comprehensive collection of perfect components that will handle every possible edge case and scenario. Instead, it's a product that exists to solve problems, much like the products your company is building. And you can use product thinking principles to help guide your path forward.

The principles I'll be focusing on today are prioritization, minimum viable products or MVPs, and metrics.

2. Prioritizing User Needs and Business Goals

Short description:

Start with your users and put on your UX research hat. Talk to them, discover their needs, find their problems, shadow them, run surveys, and collect data. Also, consider the broader product and business goals. Run code audits to gather data on current component usage. Use this information to prioritize your work.

Prioritization. There are an infinite number of things you'd be working on. Where do you start? Start with your users, of course. They're probably other engineers and probably internal, so they should be easier to reach. Put on your UX research hat. Talk to them, discover their needs, find their problems, shadow them, run surveys and collect data.

Also, think about the broader product and business goals. Is there a new component that would accelerate a major feature release that would unblock new sales? Are customers writing in about UX issues for a major product area? Even though your work is generally internal, it is important not to lose sight of the broader business. You can also run code audits to get data on current component usage. I like using the React scanner package, which scans your codebase and gives you numbers on component instances, prop usage, etc. From here, you'll probably see patterns. What do engineers commonly complain about? What do they use often? What do they find hard to use? What is important to the business? Use all this information to prioritize what to work on.

3. Building Components and Gathering Feedback

Short description:

Prioritize your work and focus on building components. Don't strive for perfection. Use the 80-20 rule to your advantage, where 80% of use cases can be built with 20% of your time. Ship something quickly to solve the majority of cases and gather feedback. Iterate and validate your solutions.

MVPs. So you prioritize your work, and most likely land on building components. When thinking about building, don't let perfection get in the way. You may have heard of the 80-20 rule, which applies here. Roughly 80% of your use cases can be built with just 20% of your total time. On the flip side, the last 20% of the hardest parts, or less common use cases, will take 80% of the time. Sequence your work such that you can ship something as soon as possible to solve the 80% case. After shipping, ensure there are channels for feedback. You will learn more by shipping and iterating than trying to make it perfect from the get-go. And through shipping sooner, you will continually validate whether you are actually solving problems for your users.

4. Measuring Progress with Metrics

Short description:

As you build components, measuring your progress is crucial. Start by tracking usage and adoption through tools like the react scanner package. Analyze trendlines to identify issues or success. Metrics provide validation for platform work and demonstrate the impact of your efforts.

Metrics. As you're building components, making updates, etc., it is important to measure your progress. The first place I start is usage and adoption. I mentioned the react scanner package earlier which gives you numbers on how often your components are being used. Use this data to build charts of component usage over time. What do the trendlines indicate? If they're flat or even going down when you don't expect them to, there might be issues, like bugs or a clunky component API, and your users may be reaching for other workarounds. If they're going up and to the right, it's probably good. You have data that shows that your component is being used, therefore, solving the problems of your users. Charts are also useful if you're deprecating or migrating a component, and it'll feel so satisfying when the line for that super old or janky component—we all have those—finally hits zero. Overall, metrics play a crucial role in platform work that is less directly tied to business impact. We all have this feeling that platform work will save time in the long run, but numbers validate the importance of our work and ground that feeling into data.

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

React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
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.
React Summit 2022React Summit 2022
27 min
Walking the Line Between Flexibility and Consistency in Component Libraries
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.
React Summit 2022React Summit 2022
20 min
Find Out If Your Design System Is Better Than Nothing
Building a design system is not enough. Your dev team has to prefer it over one-off components and third-party libraries. Otherwise, the whole effort is a waste of time. Learn how to use static code analysis to measure if your design system wins over the internal competition and data-driven ways to improve your position.
React Advanced Conference 2023React Advanced Conference 2023
19 min
Type-safe Styling for React Component Packages: Vanilla Extract CSS
Unlock the power of type-safe styling in React component packages with Vanilla Extract CSS. Learn how to effortlessly write scalable and maintainable styles, leveraging CSS-in-Typescript. Discover the seamless integration of Vanilla Extract CSS and take your React components to the next level.
React Day Berlin 2022React Day Berlin 2022
23 min
The Sorcery of Building a Cross Platform Design System Architecture
When we want to build a “cross-platform mobile app” the answer always is React Native but what if you want to build a “cross-platform app” that runs across mobile and browser? Here’s where React Native falls short. react-native-web is trying to bridge this gap to some extent but the primary requirement is to write your code in React Native which gets converted to the web, but that itself has a bunch of downsides and the biggest one being - forcing mobile app developers to understand how browsers work. In this talk, I’ll share how we are building a true cross-platform architecture without using react-native-web for our design system at Razorpay.

Workshops on related topic

React Advanced Conference 2022React Advanced Conference 2022
118 min
Rapid UI Development in React: Harnessing Custom Component Libraries & Design Systems
Workshop
In this workshop, we'll take a tour through the most effective approaches to building out scalable UI components that enhance developer productivity and happiness :-) This will involve a mix of hands-on exercises and presentations, covering the more advanced aspects of the popular styled-components library, including theming and implementing styled-system utilities via style props for rapid UI development, and culminating in how you can build up your own scalable custom component library.
We will focus on both the ideal scenario---where you work on a greenfield project---along with tactics to incrementally adopt a design system and modern approaches to styling in an existing legacy codebase with some tech debt (often the case!). By the end of the workshop, you should feel that you have an understanding of the tradeoffs between different approaches and feel confident to start implementing the options available to move towards using a design system based component library in the codebase you work on.
Prerequisites: - Familiarity with and experience working on large react codebases- A good understanding of common approaches to styling in React