It's funny to think about a time when the concept was nascent.

I remember creating UI style guides paired with a brand guide and then throwing it over the fence to let the developers figure it out.

We've come a long way.

I've built many design systems from scratch, remixed a bunch, and worked with good (and very bad) ones belonging to some notable companies.

Here are a few takes and tips that I can provide from my experience.

• Designs systems are only as useful as it is usable for those implementing it

  A design system is just one approach to product development that makes it easier to communicate ideas for implementation. You create artifacts, organize them, and share them to communicate your designs to an engineer, designer, and product manager to execute.

  Thus, it is essential to acknowledge just creating a design system isn't the goal. The goal is to get across your ideas clearly and consistently.

  Here's a list of things I'd suggest you put that additional effort into as you're working through developing your system:

  • Technical docs - This is the key artifact for implementation. You may not be tasked with actually creating this as a designer, but your design will be synthesized into this. Provide as much clarity as possible, think about things through an engineering lens, and partner with your technical teammates to get this knocked out.

  • Variants - Documenting component variants is extremely crucial and will cut out at least 40% of the questions you would otherwise get. Make sure consistent with how you name and explain their use cases.

  • Interaction details - Interactions are another 30% of questions that you will get. If you have motion design skills or are good with any of these new animation plugins and tools, I'd highly recommend at least doing a pass for a few of your most crucial button or transition interactions.

  • Patterns - If we refer to the Atomic Design Philosophy, patterns are organisms. They combine information from variants and interactions into larger ideas. And, unfortunately, I don't think many designers do a great job of adequately communicating them. The patterns will likely become more evident over time to someone newly picking up the system, but front-loading some of this effort will help cut down on ramp-up time and unnecessary back-and-forth.

  • Walkthrough demos - I believe in async work and when it's recorded and able to easily be referenced, chef's kiss. Leverage Loom to provide a higher fidelity perspective on whatever it is you want to be implemented.

  • Common language - Every design system I've ever worked on ends up having a lingo of its own. It just comes naturally in communication when trying to communicate a complex asset or pattern. I recommend documenting this somewhere that is accessible for a new teammate to refer to and pick up quickly.

• Organization is a superpower

  Make things easy to find. This begins at the top level with a good team and file structure for projects and consistent naming conventions. Spotify has a great example of how they structure their projects in Figma. You can check it out here.

  Then, more granularly, naming things consistently on the component level is a godsend. I generally follow a structure similar to this: Category / Type / State / Version. An example would be you have a button with multiple states. You'd want to name it something like Button / Small / Hover / v1. Make sure you use the "/" separator because this is optimized for the Figma instance swap feature. It'll make it easier to search and swap your components.

• Good version control helps tell the story

  I can't express enough how important it is to have a single source of truth but also a track record of where you've been.

  One reason being it's very easy, especially with multiple designers, product managers, and engineers collaborating for things to slip through the cracks. It becomes difficult to track the state of the system. You lose designs, flows, components and constantly have to point people back to where things are.

  Another reason is you want to be able to explain the journey of the designs easily and how they got to where they did so, there's no redundant exploration or questioning of decisions.

  Figma has a built-in function for version control, but I mainly use this as a safety net. What you want to do instead is create a file structure that clearly defines what something is:

  1. First, have one file that is the single source of truth. This is the master project file.

  2. Next, have a file type that is for all exploratory but defined work. These are WIP designs that you're still iterating on and need to get sign off for.

  3. Last, have a file type that is your personal playground. This is a scratch sheet. Play with your concepts here, and then transfer them to the exploratory file when you're ready to share.

• Have an agreed-upon process for feedback, updating, and communication

  A defined process is the needle that threads all of the work together. This falls into the world of Design Ops, and you'll likely split duties with others. But, you want to make sure that there is a clearly defined written SOP on how designs move from one stage to the next, when and who you're pulling in at what stage, how you're gathering feedback, and how to communicate best and track the implementation of that feedback.

  Setting guidelines will help your direct team members and save you the headache from dealing with external or low-touch contributors.

• The design system should change from mobile to web

  This is obvious, but I've seen too many cases where designers try to force-fit cohesiveness between web and mobile. Whether due to laziness or pressure, we have to acknowledge that different form factors intrinsically require different needs.

  Don't use a component or interaction that works well on the web if it doesn't make sense on mobile. It's ok to deviate if justified. Document why and share your position with your team.

• Accessibility matters, dark patterns matter

  All great designers are great users. And to be a great user, the product has to be usable and trustworthy.

  This begins with ensuring that your product is conducive to the user's intentions and aspirations and leveling the playing field for all.

  Do yourself and your users a favor by digging into accessibility and dark patterns.

• The vibe should always be collective co-creation

  Building a company, product, or team is all about the people making it and who it ultimately serves. A design system is no different.

  Thus, it would help if you always worked with the mindset that the design system is built upon and for collective ownership. It does not belong to you, him, her, or me.

  We all play a role in its existence, and when we understand that, it can improve.

• Hand-off should be less of throwing it over the fence and more of a continuous, collaborative moment

  Throwing work over the fence is the worst operational process and philosophy ever, especially if you expect the product and users to be evolutionary and not something indifferent to change and time-sensitive.

  I love this graphic from Daniel Eden on how design fidelity should scale alongside engineering, not bifurcated into two cycles.

• This helps maintain expectations, contributes to less compromise and infighting, and ultimately yields higher quality work because everyone works in tandem and is on the same page.

• Balance enforcing with exploration

  Design systems limit creativity.

  The goal of a design system is to create a unified visual language that helps us work and iterate quickly while maintaining cohesiveness. But naturally, we have a tendency to go rogue because we might think we know of a better solution, or it might be more cumbersome to adopt an institutionalized system than to leverage what we're already comfortable with. This is the paradox of design systems.

  My advice is to keep exploring but to carve out ownership and a motivation to evolve the system.

  It will feel like an uphill battle at times, but cooperation and open contribution is the name of the game and will ultimately lead to better outcomes.

• The system should be more of a framework than a doctrine

  At the end of the day, a design system is just a means to an end. It is not a one-size-fits-all, even though it aims to be.

  Things will change as the product evolves. It's essential to establish flexibility and versatility within the system and the processes that manage it.

  Experiment often, track the impact and iterate. Your team and your users will thank you for it.

Thanks for reading.

It's funny to think about a time when the concept was nascent.

I remember creating UI style guides paired with a brand guide and then throwing it over the fence to let the developers figure it out.

We've come a long way.

I've built many design systems from scratch, remixed a bunch, and worked with good (and very bad) ones belonging to some notable companies.

Here are a few takes and tips that I can provide from my experience.

• Designs systems are only as useful as it is usable for those implementing it

  A design system is just one approach to product development that makes it easier to communicate ideas for implementation. You create artifacts, organize them, and share them to communicate your designs to an engineer, designer, and product manager to execute.

  Thus, it is essential to acknowledge just creating a design system isn't the goal. The goal is to get across your ideas clearly and consistently.

  Here's a list of things I'd suggest you put that additional effort into as you're working through developing your system:

  • Technical docs - This is the key artifact for implementation. You may not be tasked with actually creating this as a designer, but your design will be synthesized into this. Provide as much clarity as possible, think about things through an engineering lens, and partner with your technical teammates to get this knocked out.

  • Variants - Documenting component variants is extremely crucial and will cut out at least 40% of the questions you would otherwise get. Make sure consistent with how you name and explain their use cases.

  • Interaction details - Interactions are another 30% of questions that you will get. If you have motion design skills or are good with any of these new animation plugins and tools, I'd highly recommend at least doing a pass for a few of your most crucial button or transition interactions.

  • Patterns - If we refer to the Atomic Design Philosophy, patterns are organisms. They combine information from variants and interactions into larger ideas. And, unfortunately, I don't think many designers do a great job of adequately communicating them. The patterns will likely become more evident over time to someone newly picking up the system, but front-loading some of this effort will help cut down on ramp-up time and unnecessary back-and-forth.

  • Walkthrough demos - I believe in async work and when it's recorded and able to easily be referenced, chef's kiss. Leverage Loom to provide a higher fidelity perspective on whatever it is you want to be implemented.

  • Common language - Every design system I've ever worked on ends up having a lingo of its own. It just comes naturally in communication when trying to communicate a complex asset or pattern. I recommend documenting this somewhere that is accessible for a new teammate to refer to and pick up quickly.

• Organization is a superpower

  Make things easy to find. This begins at the top level with a good team and file structure for projects and consistent naming conventions. Spotify has a great example of how they structure their projects in Figma. You can check it out here.

  Then, more granularly, naming things consistently on the component level is a godsend. I generally follow a structure similar to this: Category / Type / State / Version. An example would be you have a button with multiple states. You'd want to name it something like Button / Small / Hover / v1. Make sure you use the "/" separator because this is optimized for the Figma instance swap feature. It'll make it easier to search and swap your components.

• Good version control helps tell the story

  I can't express enough how important it is to have a single source of truth but also a track record of where you've been.

  One reason being it's very easy, especially with multiple designers, product managers, and engineers collaborating for things to slip through the cracks. It becomes difficult to track the state of the system. You lose designs, flows, components and constantly have to point people back to where things are.

  Another reason is you want to be able to explain the journey of the designs easily and how they got to where they did so, there's no redundant exploration or questioning of decisions.

  Figma has a built-in function for version control, but I mainly use this as a safety net. What you want to do instead is create a file structure that clearly defines what something is:

  1. First, have one file that is the single source of truth. This is the master project file.

  2. Next, have a file type that is for all exploratory but defined work. These are WIP designs that you're still iterating on and need to get sign off for.

  3. Last, have a file type that is your personal playground. This is a scratch sheet. Play with your concepts here, and then transfer them to the exploratory file when you're ready to share.

• Have an agreed-upon process for feedback, updating, and communication

  A defined process is the needle that threads all of the work together. This falls into the world of Design Ops, and you'll likely split duties with others. But, you want to make sure that there is a clearly defined written SOP on how designs move from one stage to the next, when and who you're pulling in at what stage, how you're gathering feedback, and how to communicate best and track the implementation of that feedback.

  Setting guidelines will help your direct team members and save you the headache from dealing with external or low-touch contributors.

• The design system should change from mobile to web

  This is obvious, but I've seen too many cases where designers try to force-fit cohesiveness between web and mobile. Whether due to laziness or pressure, we have to acknowledge that different form factors intrinsically require different needs.

  Don't use a component or interaction that works well on the web if it doesn't make sense on mobile. It's ok to deviate if justified. Document why and share your position with your team.

• Accessibility matters, dark patterns matter

  All great designers are great users. And to be a great user, the product has to be usable and trustworthy.

  This begins with ensuring that your product is conducive to the user's intentions and aspirations and leveling the playing field for all.

  Do yourself and your users a favor by digging into accessibility and dark patterns.

• The vibe should always be collective co-creation

  Building a company, product, or team is all about the people making it and who it ultimately serves. A design system is no different.

  Thus, it would help if you always worked with the mindset that the design system is built upon and for collective ownership. It does not belong to you, him, her, or me.

  We all play a role in its existence, and when we understand that, it can improve.

• Hand-off should be less of throwing it over the fence and more of a continuous, collaborative moment

  Throwing work over the fence is the worst operational process and philosophy ever, especially if you expect the product and users to be evolutionary and not something indifferent to change and time-sensitive.

  I love this graphic from Daniel Eden on how design fidelity should scale alongside engineering, not bifurcated into two cycles.

• This helps maintain expectations, contributes to less compromise and infighting, and ultimately yields higher quality work because everyone works in tandem and is on the same page.

• Balance enforcing with exploration

  Design systems limit creativity.

  The goal of a design system is to create a unified visual language that helps us work and iterate quickly while maintaining cohesiveness. But naturally, we have a tendency to go rogue because we might think we know of a better solution, or it might be more cumbersome to adopt an institutionalized system than to leverage what we're already comfortable with. This is the paradox of design systems.

  My advice is to keep exploring but to carve out ownership and a motivation to evolve the system.

  It will feel like an uphill battle at times, but cooperation and open contribution is the name of the game and will ultimately lead to better outcomes.

• The system should be more of a framework than a doctrine

  At the end of the day, a design system is just a means to an end. It is not a one-size-fits-all, even though it aims to be.

  Things will change as the product evolves. It's essential to establish flexibility and versatility within the system and the processes that manage it.

  Experiment often, track the impact and iterate. Your team and your users will thank you for it.

Thanks for reading.