You’ve decided a design system is right for your product, and now you’re at a crossroads; what’s the next step? There are three potential directions to go from here: 1. Choose to adopt an existing design system from one of the myriad of options, 2. build one yourself, or 3. attempt to hybridize the two by customizing or adding custom components to an existing kit. There’s no one right answer, it depends on your resources and the needs of your product. Let’s dive into some of the pros and cons of each choice.
Option 1: Adopt an existing design system
The main advantage of adopting a design system is it’s fast! “superflat” by blinq is licensed under CC BY 2.0.
There are many existing design systems available, each coming with their own unique benefits and drawbacks. A handful of commonly used systems at the time of this writing (2022) include: Clarity, MUI, Ant, Polaris, Carbon, USWDS, Evergreen, Fluent, and Material Design. Additionally, you may be required to comply with certain interface guidelines for inclusion in the Apple or Google Play stores. Adopting a system can be a powerful option if you need to get started quickly, have talent constraints, or know you will be designing to spec for an existing platform.
Adopt PROS
Faster speed
Potentially robust system right out of the gate
Great if the product works well with generic components
Less impact on talent’s workload
Lower level of talent specialization needed in UI/interaction design and front end development
People may already be familiar and experienced with some of the more popular ones
A head start on governance, since documentation for development and design side components may already exist
Adopt CONS:
You will likely end up paying for advanced (or even some basic) features (e.g. the buttons are free but the date picker will cost you)
You may need to pay for 3rd party support, even with open source systems
You may not have any ownership over the system or by extension, its redistribution rights once you make it your own
You will be at the whim of third party updates: what they contain, and when they happen
The system or the version you’re using may stop being supported–– This can lead to substantial code rework down the line
Depending on the system, these can be fussy to customize, particularly when it comes to styling (see the “customization” section below)
Adopt Wishlist: What to look for in an existing design system:
✅ Payment models fit our budget: Open source, freemium, paid
✅ A robust component library (one that works with your code — for example, does it need to be React compatible?)
✅ The system is well documented, for example they may have a storybook library that is accessible to the public
✅ The design and its corresponding code are actively maintained; Check the recency of the last update. Was it last month or eight years ago?
✅ Code components are soundly made and easy to use and test
✅ The design-side components are well structured (check for resize ability /responsive friendly layouts/tagged colors and fonts, etc). Preferably they are already in a design-side file such as one in Figma/Sketch/XD.
✅ Design-side components match the current code and vice versa
✅ From a business strategy perspective, the source is an ally or neutral (not a competitor)
✅ Ideally, the system allows us to at least lightly modify the design & code to suit the individualized needs of our problem space & user base (both functionally and legally)
✅ Must be secure (e.g. actively patched and tested with security updates, not on foreign servers if that’s a concern for your type of business data, etc.)
Option 2: Create a new design system from scratch
Grow your own. Create Advantage: We can customize it as much as we want, and own the results
So, maybe your application isn’t just any old run of the mill product. Maybe it’s important to distinguish yourself in the marketplace, or create components for custom use cases (star charts, anyone?). Maybe it’s critically important not to be dependent on the potential failure of a third party, such as let’s say an app that controls life support for medical devices. It could even be that your eventual goal is to be able to sell or redistribute the system that you make. These are all great reasons to go the customization route.
Create PROS
Infinitely customizable styles
Highly customizable components — You can do things like make the look and feel your own, tightly fit your user needs/use cases, innovate, and maximize accessibility
Ownership of your own system (redistribution rights)
Ability to control timing and content of updates vs. being dependent on whims of a 3rd party
Create CONS
Takes a tremendous amount of work and a long time to make robustly (Although you can always start lean, I’d wager at least a year of teamwork to create a full base kit)
Requires dedicated senior and above level product designers with a high UI design skill level
Requires dedicated senior and above level full stack developers
Status messaging and change management (if applicable) necessary — so the team may need at least one product manager
Requires ongoing talent dedicated to updates and maintenance in perpetuity
Repository/library creation and maintenance necessary on both the design and development side
If something goes wrong, it is on your team to fix it (often immediately, are there people willing to have pagers on at night?)
Option 3: Customization; Is it possible to do both?
We’ll just mix this code right up with this other code…Who doesn’t love the idea of starting with a robust system, and then mixing in a little customization to make it their own? Unfortunately, this can be a lot easier said than done depending on the system. It also depends on what you’re customizing; to a certain extent, changing a color or a radius here or there may be easy, but changing how a component fundamentally behaves may not. MUI, a canonically fussy system to customize, has been trending towards more freedom recently — so this can also change over time.
Customize PROS
Faster speed
Robust system right out of the gate
Somewhat customizable components
Somewhat customizable styles
A head start on governance, since documentation of development and design side components may already exist
Customize CONS
Governance might get confusing: What is the same as the origin source system and what is different? How do people know which is which?
Repository creation and maintenance necessary for custom components
You still don’t own the system; subject to third party update whims
You still don’t own the system; little to no redistribution rights
You may still need to pay for the system or parts of the system licensing
Requires at least part time senior and above level product designers with a high UI design skill level to customize (design side)
Requires at least part time senior and above level full stack developers to customize (dev side)
Conclusion To recap, when choosing a path forward with your design system, some of the major considerations are how unique your product is, the availability and skill sets of your talent pool, and the timeline runway you have to get the system into full swing. If product management, development, and design strategy is the kind of thing you are looking to get started for your business, here at Tanzu labs we proudly partner with companies in the public and private sectors to enable them to create design systems, find a winning product-market fit, build and modernize apps, and more. < Previous [Medium]: How do we know if we need a design system? Up next [Medium]>: Design systems and politics part I of III