Should you use 3rd party libraries in your design systems?
Dan Donald
Whether self-driven or requested from a senior stakeholder, you need to make a ‘design system,’ whatever that is! You may or may not have people to work on this or any experience working in this space, so what do you do? The dev and design community has always been incredibly generous with sharing knowledge and artifacts, so what are some benefits and drawbacks of using some?
There are many reasons why using 3rd party developed libraries makes sense, from either the developer or design side. The authors help us all by sharing their experience, knowledge, and craft in ways that benefit us and our work. There are times when these projects can be hugely beneficial and others where there may be some drawbacks, so explore some and evaluate their impact. As always, your context matters – are these projects solving your problems?
Most of these points can apply to a 3rd party used in either discipline, but we’re mainly focused on the developer side of the equation.
They can help you get started quicker
Pro: They definitely can get you started quicker! If someone has put in a lot of work and made many decisions about syntax, structure, and process, you can skip those foundational aspects and start with the code you need to write.
Con: This initial speed can mean the solution you’ve used remains in the codebase for years. That may be fine if it’s a mature, well-supported project, but that carries a risk. You’re also building on top of those decisions from that 3rd party that becomes fundamental to everything that comes after. With experience, you may want to change, which may mean adapting or moving away from that library. It is not a reason not to use them, but it can be an unintentional side-effect of getting started quickly.
One example might be using something like Bootstrap or Tailwind in CSS. You’ve got some great work to build on top of, but it’s worth recognizing that you’re then building every subsequent decision off that dependency, which can make a change to another approach difficult in the future. It’s as much about the way of working and writing your code as much as having a code dependency.
It gives us a great foundation to build from
Pro: Whether it’s a CSS library or something built on a JavaScript framework, having a project with experience baked in can empower you and your team. Some can be borderline magic in what you get out of the box!
Con: It’s worth being conscious of the design patterns and choices made in the 3rd party solution, as their methods won’t be the only solution to the problem. It might not be clear until much later whether these choices the author made are entirely appropriate for your organization and your problems.
It’s just CSS/JavaScript, so shouldn’t matter too much what we use
Pro: This is true! There’s great work available to us all to use for free, so why wouldn’t we just find the right solution for the job? Often their work bakes in a lot of their experience and expertise and you get that to embed in your work!
Con: It is ‘just CSS/JavaScript,’ but with it comes maintenance, updating, etc. You need to be confident that any 3rd party project is well-supported and maintained. As people contribute their time and effort to help the community, there’s no requirement for people behind these projects to continue indefinitely. There’s risk in including any 3rd party that you can quantify – if this went away tomorrow, how much effort would it take to replace it?
Using [X] will save us a lot of money
Pro: We’re fortunate to have such a great industry that promotes sharing freely with open-source code. Most often, the 3rd party solutions you work with will be free or cost very little. It’s hard to deny that would save us time and so much money!
Con: Much as with getting started quickly, there’s the potential for hidden costs in the future. That’s not a reason not to use a 3rd party, just an aspect to be aware of before committing. Needing to move beyond the 3rd party or replace it in your codebase will have a cost associated with it. If your product or service is to be long-running, then the cost saved at first can be incurred later in the project.
Very much like how we might evaluate the use of a plugin or something we use as part of a build process, 3rd party libraries can sometimes be a double-edged sword. The initial benefits can give way to longer-term issues, which is no reason not to use them but to do so with that in mind. You’re not just committing to using the code but the intent behind it, the design patterns, and processes. Looking at it in the round, you might find a perfect solution for getting you started but already have a migration path in mind to one day move away from it and roughly what amount of effort that might require.
You could quite happily build on top of 3rd parties and have that as part of everything that comes after; it’s just worth having that longer-term view and shared awareness of potential risks so that everyone goes on the journey with you. Capturing decisions made (through ADRs of DSDRs) can be a significant part of that as it encourages people to present their case for a potential solution, discuss it, and store the result for future reference.
One strong use case for using 3rd parties is for proof of concept or demo work. Where the focus is to validate the idea or approach, the code often doesn’t need to be written to production quality as it is often seen as quite disposable for those kinds of projects. It’s also a great opportunity to test out some projects you’ve heard about without needing to apply the same rigor that your production code might need to.
When reviewing what 3rd party code to use, you can often find that the great work the contributors have put into it can often be high quality and help with using standards, improving accessibility, and embedding modern ways of working. I know I’ve been guilty in the past of wanting to use the ‘new shiny’! It can be hard to dispassionately look at what you’re trying to achieve and see what the pros/cons of using various 3rd parties in your codebase are. Being clear on short-term gains against longer-term constraints or costs can be pretty difficult.
The pros and cons of adopting a CSS library or pulling a Javascript dependency will vary depending on the use case, but looking more holistically at what that actually means beyond the short term is an important step for us all to consider.