Applying Product Thinking Principles to your Design System

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.

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.

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.

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.