So your company is thinking about investing (or re-investing) in a design system. What does that look like? Beyond the seemingly never-ending debate about what your design system will include, there is a whole decision about what it will be built on.
Many teams look at the software landscape of design systems and immediately look toward many popular but partial solutions that solve for important pieces of the system stack: Storybook or Styleguideist, Figma or Xd, and even things like GitHub Pages or Confluence can all support elements of a design system. But even if you pull these tools off the shelf there’s more work to be done to effectively power a cross-functional operation end-to-end.
So, how do you go about standing up a true platform for your design system operation?
Typically, the choice falls into one of three categories that we’ll explore in more depth below:
- DIY / Build your own
- End-to-end platforms
- Multi-tool integration
DIY / Build your own
Many organizations look at a design system infrastructure as a few simple features tied to a design tool. A few engineers with a code repo and some plugins are seemingly all you need to have some reusable design and code. While there can be some value in a system like this, most organizations reach a ceiling quickly. As demand for new features and customizations pile up, they advocate for more resources to build “what they really need” in a way that is “perfectly tailored to their needs”. You can see where this is going.
To fully build a DIY system you quickly find a nearly bottomless well of features and nice-to-haves that can all become need-to-haves in order for anyone other than the core team to adopt the system. Not to mention the features that are table-stakes to stand up a platform in your enterprise environment (raise your hand if you’re excited about building a permissions system!).
Most organizations end up with a quagmire of spaghetti-meets-Frankenstein’s-monster platforms that work if you don’t stray too far from the happy path. Teams with lots of experience, buy-in, and budget can build a system that does deliver value, but typically has brittle parts that require significant continual investment in custom software development. Even seemingly easy extensions to existing platforms (e.g. Storybook) ultimately create software that is often limited, variable quality, and requires continual reinvestment. Support, if available, is usually a patchwork of overlapping vendors forcing reliance on key internal resources that may leave or change roles.
But doesn’t a DIY system get you exactly what you want in a way that is tailored to your specific business needs? This is a trap. Sure, if you’re Google, IBM, Salesforce or another highly mature organization, you may find that you can’t meet your needs any other way. Then DIY – and the hefty price-tag that comes with it – may be your only option. For most, however, the lure of DIY gets you what you thought you wanted 18 months before you started building it (when you planned your build), and it usually shows its age quickly as tech and approaches mature in a fast-changing environment.
Bottom line, unless your business is building design systems, then you probably shouldn’t go down this road. Most likely, your business cares a lot more about investing in the content and adoption of your system rather than what you build it on.
End-to-end platforms
In contrast to DIY, an end-to-end system is fully managed by a provider and gives you a platform infrastructure for your design system. These platforms are all relatively new with most of them being created in the past two or three years. These types of platforms represent the Software-as-a-Service (SaaS) model that has been successful in recent decades in shortcutting time to value and displacing the burden and cost of innovation for enterprise platforms. The goal of these solutions is to create a single platform that manages the majority of the design system’s needs (documentation, token management, code + CI/CD integration) and balances their ability to be flexible and configurable for a wide variety of organizations.
Simply put, these platforms help your organization go further faster while reducing the long term overhead of operating effectively and efficiently at scale.
There are solutions that vary on the spectrum of how opinionated their approach is to your design system. Typically, smaller and less mature organizations look toward more opinionated solutions as they have “headroom” to mature within these platforms. Further, the baked-in opinions are often valuable absent a concrete understanding of implementation details, even if they come with significant impositions for your engineering org (e.g. using a new coding framework).
Larger or more mature organizations typically look toward more flexible un-opinionated platforms that provide a wide range of options and allow them the ability to fine-tune their design system without the need for extensive customization or maintenance. These platforms – like Knapsack – often pair technical solutions with white glove services and support to help enterprise organizations, as well.
Multi-tool integration
Using multiple point solutions - a documentation tool, a code rendering tool, a design library manager, etc. - can seem like an appealing way to go for many teams. The challenges most teams encounter are similar to those found by teams on the DIY path: there’s a lot of manual work required, and you’re on your own.
Point solutions typically provide robust feature sets around a more limited set of solution areas, creating what we think of as a ‘lumpy’ experience or foundation.
It may be easy to spin up a rich documentation site that reflects what’s in design, but that experience isn’t directly connected to the workflows used for shipping code to engineers or showing what’s actually used in product. Likewise, engineers may have great solutions for reusing well-built components, but those aren’t easily available to design without additional engineering overhead.
More often than not, these teams continue to experience the pains that led them down the design system path in the first place: inconsistent output, confusion and disconnect across disciplines, and overall inefficient production. This hampers adoption, and most organizations quickly hit limitations they weren’t expecting.
Conculsion
At Knapsack, we most often guide teams down the end-to-end platform path, because it helps them go farther faster and find ways to get ROI quickly. Instead of spending months building the system and the tooling to use it, they find quick wins by getting tokens out of Figma, into code (JSON), transformed to styling (CSS/SCSS/XML/Swift, etc.) and distributed to engineers to use - within days.
End-to-end enables teams to focus on how they work - enabling reuse of solutions and sharing of innovation - which in turn enables the return they set out to realize.
