We never set out to build a design system for NCSBN. It started as a simple pattern library for a single website, nothing more. But over time, it took on a life of its own, growing and evolving until, before we knew it, we had something that resembled the beginnings of a design system.
Typically, we carefully plan design systems for our clients, but this one snuck up on us. It happened almost by accident, and I want to share its story.
How It Started
2018 is around the time when I personally learned the most about pattern libraries. A pattern library, for those who don’t remember, is a curated collection of reusable design elements and UI components that help maintain consistency and efficiency across digital products. Everywhere I looked, I saw people talking about some new pattern library generators, such as Pattern Lab, Fabricator, and Drizzle, and I was having a blast trying them all. At this time, design systems were also gaining popularity as a way to take pattern libraries to the next level.
The First Engagement
Our initial engagement with the National Council of State Boards of Nursing (NCSBN) happened in 2018. Speaking personally, I was only beginning to think in terms of “design systems” at this point, but I was already focused on how to make development more efficient. I wanted to spend less time configuring the build and pipeline, and spend more time thinking about how to write really simple CSS that could handle complex theming.
NCSBN approached us to redesign their organization’s website. Our deliverable was a pattern library with page templates and compiled CSS and JS assets that they could integrate into their existing CMS. We decided to use Drizzle as our pattern library generator. Drizzle was a relatively new pattern library generator, but it was simple and easy to use, and even more importantly, easy to customize.
The Second Engagement
Fresh off the success of our first engagement, NCSBN approached us again with another project: a timeline that celebrates the organization’s history. This new website was completely unrelated to the first, but we really wanted to demonstrate how a pattern library would benefit them moving forward, so we added this new project into the pattern library created for the initial website. We ended up with a single code base powering two distinct projects. The templates and styles were unique to each site, but the single repository and build pipeline allowed us to get started building almost immediately.
At this point we still weren’t in design system territory, but we did have a nice framework for spinning up new NCSBN websites from templates that saved a ton of time in project setup. All we had to do was duplicate a couple of folders as a starting point, saving about a week’s worth of development work. Additionally, we were reducing the number of repositories and build pipelines we would need to maintain. If we continued to expand this project, the long-term savings would only grow, both for our team and for NCSBN, through faster launches and lower maintenance costs.
Becoming a Design System
We didn’t stop after the second engagement. The time savings from the first build made it worth it to continue adding new projects to the system. At some point we realized that since we were only duplicating the projects, that meant that each project had its own unnecessarily unique grid and spacing systems, along with other redundant code. For the most part, this approach worked well, each website in the system had the unique look and feel the client wanted for each engagement. The repository still wasn’t a true design system, it was a single pattern library that housed multiple projects, which would typically live in separate libraries, all sharing the same directory and build pipeline.
A well-structured pattern library can serve as a foundation for a system.
The Unexpected Evolution
Then one day, priorities changed. The client wanted to create a series of “microsites” that all shared a similar look and feel. This gave us the opportunity to refactor our pattern library and systematize reusable, themed components. While the first microsite project required more setup than projects before it, the payoff was that all future microsite projects would take a fraction of the time compared to those earlier projects. This is the point where we first stepped into design system territory with this partner.
Once we realized we were building a design system, we decided to really lean in and rework the entire build. We performed an audit of all of the projects in the system to identify any similarities and reusable elements, and worked to consolidate them into a single collection of shared systems that each of the projects then imports. Some projects still needed a fair amount of custom code, but each new microsite was able to build on the previous ones and typically only required theme token updates, with the occasional new component.
How It’s Going
This system has worked really well for the client and us, and it’s still in use today. Sparkbox regularly adds new features and updates that the client can easily incorporate into their production websites. Recently, we worked with NCSBN to redesign the main organization’s website again to align with those microsite designs. Since both the main website and microsites lived in the same system repository, it was straightforward enough to update our page templates to import the microsite CSS and JS, allowing us to continue expanding on the system.
Once again, this approach allowed us to bypass the initial setup work for a new project, enabling us to dive straight into modifying and building on what was already in place. This streamlined process saved time and kept the consistency we had established across the microsites, expanding it to the main website.
Is It Really a Design System?
I might have been a little disingenuous up until now. This isn’t a complete design system, though it is close. What it’s still missing is a formal layer of collaboration with design: shared standards, design tokens, and a feedback loop between designers and developers. Designers and developers still collaborate but that collaboration isn’t yet structured around a shared system of design decisions. But what started as a simple pattern library has evolved into a robust system that allows us to efficiently spin up new project templates while maintaining a consistent look and feel. More importantly, it has the potential to continue growing into a fully-fledged design system as we continue to work with this client team.
The key lesson here is that even if you don’t plan to build a full design system, focusing on reusability and structure early on can make scaling much easier. A modular, well-structured pattern library can serve as the foundation for a system, without the need to force a comprehensive design system from the outset.
Advice for Building your Accidental (Almost) Design System
Start Small
Don’t rush into creating an all-encompassing design system right away. Instead, begin by identifying and documenting simple, reusable patterns. Whether it’s buttons, forms, or layouts, start small and scale gradually. By focusing on these foundational elements, you create a more manageable starting point that can grow organically over time without the pressure of overcommitting too early.
Make Reusability a Priority
Even if you’re working on a seemingly isolated or unique project, always think about the future. Will this pattern, component, or style be useful elsewhere down the road? Designing with flexibility in mind ensures that the work you’re doing now won’t be wasted. By prioritizing reusable components, you’re building a framework that can easily scale as new projects come in.
Choose Tools That Scale
When selecting tools for your system, keep scalability in mind. It’s okay if the tool you choose isn’t the final, perfect fit, but it should offer flexibility and the capacity to evolve as your needs change. Over time, as the system matures, you can refine your choices and adopt more specialized tools, but the initial decision should be about creating a strong foundation that grows with your system.
Be Open to Iteration
Don’t feel pressured to have everything figured out from the start. Design systems can (and always do) evolve over time. A rigid plan isn’t necessary and sometimes the best systems are those that develop organically, responding to real-world challenges and opportunities as they arise. Embrace the journey, and be open to the way your system naturally develops.
