#4: Our Roadmap, Stage Two

Welcome back. Now that you’ve completed Stage One by conducting honest discovery, collecting the appropriate artifacts, and settling on the Design System’s Purpose and Principles, we’re ready to take you a little further.

Your design system is a tool. In Stage Two, you decide on certain technical aspects of your tool, and begin planning how your organization is going to use it.

Per our Cliffs Notes from last post, Stage Two is where we make foundational technology choices about architecture, governance, maintenance, and documentation, and where we begin dovetailed conversations concerning business development and organizational change.

Here’s our whole roadmap. Today we’re talking about laying the Foundational Framework — everything in blue:

We like to think of Foundational Framework as two interconnected processes happening in tandem: the Technical Foundational Framework, and the Organizational Foundational Framework.

Following the roadmap, the Technical Foundational Framework involves every technology choice you must make before you begin creating the components that will make up your re-usable pattern library. The Technical Foundational Framework comprises the technical architecture and operational laws of your design system, including:

• where it will be hosted
• what templating language it will use
• how you’ll update and maintain your design system, and who will do it
• how you document and fix bugs

There’s a ton more to say about Technical Foundational Framework, but we’ll save that for another post (stay tuned for our deep dive into Foundational Framework in a few weeks).

At this point, what’s important to know about the Technical Foundational Framework: you want these technology choices to stick.

Making a decision to change the templating language after you’ve built the design system, for example, would be akin to moving your restaurant across town, brick by brick, the morning after you open, because you’ve changed your mind about which location is best for your business. (For non-tech types: in simple terms, the templating language is the language developers most directly use in order to create HTML, which is the language that creates what a user actually sees when they go to a website.)

Why we don’t represent Foundational Framework in two tracks in our roadmap: brevity, but also because a design system’s technical specs intermesh so intimately with the business side/organizational structure that we’re loathe to represent them separately. In fact, we think the nexus of the Foundational Framework is one of the ripest discussion topics discussion for understanding the purpose, and the nature of design systems.

The Organizational Foundational Framework involves everything you have to do to get your organization ready to effectively use your design system.

This involves a pretty broad spectrum of things, but we think it’s helpful to divide the Organizational Foundational Framework into two major categories: Governance, and Change Management.

Governance

Choosing a governance model for your design system begins with the preliminary question: how do we plan to use this tool? Form follows function, and knowing — and articulating — what its best function will look like helps you answer questions about how it should be built (which informs the Technical Foundational Framework), and helps you answer further questions about how it should be governed.

For example, if your design system will be used by a tight-knit team of five semi-telepathic developers, designers, and content editors to build sites and push content, it probably doesn’t make sense to set up a really highly structured system. You can tend towards something with clear guidelines, and a more malleable pattern library that allows for greater downstream control.

But if your design system is destined for use by fifty people — or five hundred — it will probably better serve your organization to build something with stricter guidelines that keeps your creative direction integrated.

Change Management

When an organization makes the decision to adopt a design system, they’re making a decision to grow into a new way of communicating, building, and being. The change management aspect of your Foundational Framework addresses what you need to do in order to transition from where you’re at right now, both operationally and philosophically, to a new place of empowerment with your design system. How will you train people to use the design system correctly? How will you vet that the tool is being used as it should? And, during its creation, how will you invite meaningful input from the people who’ll be using it to increase buy-in, and to increase your design system’s relevance?

Ultimately, a well-wrought design system should support a symbiosis between an organization’s technology, its business goals, and its creative direction.

Laying your Foundational Framework generates the organizational and technical structure you need to start:

• building the right components for your design system when the time comes (…in Stage Four).
• mapping the new business processes that will accompany your design system. (This continues throughout the process. While the Technical Foundational Framework decisions are largely answered prior to building components, developing the Organizational Foundational Framework doesn’t have a hard end date — it’s productive to keep iterating on it. What’s important is that you begin these two conversations — Technical and Organizational — at the same time, because they’re dovetailed.

We like to think of Design Systems Implementation as a constellation of interconnected conversations which, over the course of the process, trace together to create the design system that integrates your creative direction.

We believe that implementing a design system is healthy for organizations because of this cross-pollination: the process is interdisciplinary and connective, and catalyzes deeply revelatory conversations about an organization and its identity, how it creates, and where it’s going.

Next up: Stage Three of our roadmap — how we look at all your existing sites and get ready to build the actual muscle of your design system.

Thanks for reading!

Originally published at basalt.io.