How Much of A Design System Do You Really Need?

If you’ve been around Sparkbox for more than a minute—subscribed to our newsletters, attended one of our UnConferences, or perused the Foundry—you have likely discovered three things…well, maybe more, but these three are evident: we’re a group of lifelong learners, we genuinely care about delivering quality work by providing a consultancy-like mindset, and we talk a lot about design systems. Like, a lot. And for good reason. Design systems can unite an organization, add clarity, and … you know how it goes. But full-blown design systems aren’t for everyone. So the question, then, is: How much of a design system do you really need?

We have a client we’re currently working with who would love a full-blown design system. They recognize its value and how much they could benefit from it, but they have a limited budget and, quite frankly, it’s simply not a priority for them and on their roadmap this year. Budget constraints are real, and we certainly respect that. But we also never shy away from the question, “I wonder…?” In this case, I wonder what we could deliver to address their current priorities and serve as the beginning of an eventual design system? It was a question that the client was on board to explore.

Let me share exactly how and where we arrived in this particular scenario.

Listen to What’s on Repeat

As a project manager, I play by the rule of threes when it comes to project pain point escalation. It goes something like this: take note the first time a pain point is mentioned. Dig in the second time it comes up. Begin solutioning if it’s repeated a third time. In this particular example, I was hearing from the client things like:

• We need a more streamlined source of truth when it comes to documentation.

• We’re too dependent on a single individual for the project’s success.

• Modifying and testing multiple use cases/scenarios has proven difficult.

• We need to know if a component is used in a new or unexpected way for our users so that we do not inadvertently introduce bugs as we modify the component.

• What are our standards for the various design themes? And where are the places we have deviated from those standards, and why?

All of these were excellent questions and—like any pain point—if left unanswered or unexplored, could certainly put the success of our work at risk. So we began solutioning.

For full transparency, at this point, we had already discussed the possibility of a design system—it had come up in previous sprint retrospectives. But there was so much hesitancy around building a design system due to the time and financial investment associated with what everyone was picturing, which was a mature design system.

Part of the solutioning process, which we titled “Discovery,” was to remove assumptions and focus on the “what ifs,” “what coulds,” and “I wonders.” Our Discovery goals included:

• The purpose of the design system and its team structure is understood by all

• All pain points have been identified and prioritized

• Pros and cons of different solutions have been considered

• An MVP (Minimum Viable Product) for the first phase of work has been defined

Solutioning for a Design System

Determining how much of a design system you need is incredibly similar—if not the same—as determining an MVP or feature set. There is information gathering, prioritizing, and then further defining the work. Let’s break down each step:

1. Information Gathering

As strategists, we must always start here to answer the question, “What are we trying to fix or solve for?” This includes gathering feedback from all parties to identify what pain points—and goals—exist. Where do inefficiencies and other threats lie that halt progress and keep us from achieving our ultimate goals? What are our ultimate goals? These pain points and goals-based conversations will help us identify what a potential design system might look like and ensure that we are building the right thing to achieve the right goal.

2. Prioritizing

Once you’ve identified your pain points, goals, or both, capture them on a Trello board, sticky notes, or other similar card creation system to have productive group conversations. In these conversations, and before prioritizing the work, make sure everyone has a shared understanding of what’s captured on the board. The pain points and/or goals should be well defined. Everyone should understand the users involved, the impacts, the effort associated, and how that thing is competing with or supporting the project goals.

Once all the cards have been reviewed as a group, begin voting. I prefer an anonymous voting system if possible, as it eliminates the possibility of groupthink or peer pressure. Take a look at the cards with the most votes and evaluate how they compare to any organization constraints like time, people, and budget.

3. Further Defining the Work

Once you’ve prioritized your greatest pain points and goals, define what tackling them looks like. For our specific project, we prioritized documentation and began building out our design system around that. After considering our constraints, we decided to build out the documentation in an organized Google Doc. It’s been a collaborative effort, and all stakeholders are shaping the documentation, which is the best way to build ownership over the design system in the long run.

You Don’t Need it All

You likely don’t need all the bells and whistles of a design system from the get-go. This turned out to be the case with our particular client. By lifting our assumptions about the one right way to build the one right kind of design system, we were able to iterate into the right amount of design system for right now. And I’m proud to say that our client has a solid foundation for a design system that they can grow into when it does become a priority on their product roadmap.

If you’re wondering how much of a design system you may need, determine what is the first milestone for your design system and invest in that. Like any other piece of software, push it out, get feedback, iterate, and repeat. MVP your way there as you shape the system collectively.