#3: Our Roadmap, Stage One

Explaining design system implementation successfully is akin to navigating a field full of rabbit holes.

Each hole contains valuable information, holds potential for facilitating understanding of design systems, and the process of their becoming.

The challenge of this series:

To peer into every rabbit hole without falling down any of them completely, and thus losing perspective.

Why we use a roadmap for design systems implementation: to keep project teams oriented and on track. During implementation, we have to dive extensively into every phase of the process, and the roadmap is the tether that allows us to stay connected to the surface. When designers, developers, architects, stakeholders, content managers want to know where any project team member is in the process, they can raise their hand and say: I’m right here. This is where I’ve been. And this is where I’m going.

But real-life implementation takes weeks or months, and we’re bringing you through it at relative hyperspeed. So in order to ensure that our roadmap is orientating, clear, and educational, we wanted to map out the vast field that is design systems implementation before we begin to guide you through it.

We’re choosing to divide our roadmap into four stages.

We’ll cross them in order, start to finish, and each stage gets its own post in this series. You can read them one at a time, or in one fell swoop — they’re not that long.

(At this point, this roadmap may mean not very much to you. That’s okay. That’s why you’re reading this.)

Here are the Cliffs Notes for what happens in each stage:

Stage One is where we figure out how things are built now and define how we want to build in the future.
Stage Two is where we make bedrock technology choices about architecture, governance, maintenance, and documentation, and where we begin dovetailed conversations concerning business development and organizational change.
Stage Three is where we look at all current sites and do the pre-work for converting and expressing your sites as components that will render all web assets more maintainable, reusable, and consistent.
Stage Four is where we create the shiny new chunks of code that constitute your new pattern library — the brand- and purpose-specific “Legos” with which you’ll build every experience from here forward.

At the end, you have a Design System — a Why, a How, and a What.

The Why: you have a design system for a clear set of reasons, and it’s been built to address those: you’re part of a house of brands, you’re in a regulated industry, you publish content frequently. Whatever it is, you probably require multi-site management and cross-channel integration, and your design system will help you do it.
The How: you’ve done the hard work of determining how your design system will be governed, how it will be maintained, who will maintain it, how you will guide its evolution, and how it will be architected so it can perform for your organization.
The What: you’ve built your pattern libraries — the maintainable, reusable components that will power your elegant, consistent web experiences.

Now you can use your Design System to start building for the web better, faster, and with fewer resources.

Take a look at Stage One in greater detail — which, you’ll remember, is all about getting the lay of the land.

STAGE ONE consists of:

• conducting Discovery
• sharing and exploring Design Artifacts
• defining the design system’s Purpose and clarifying Design Principles. Because these are so important, they deserve their own document: the Statement of Purpose and Design Principles.

The point of Discovery is to reveal how a client builds for the web right now.

The project team should be interested in every part of the process currently used to develop a conceptual problem into presentable, polished experience. Very often, Discovery uncovers a messy, convoluted, inconsistent, and imperfect process, and that’s okay. That’s what the Design System is here to address.

Collecting and exploring Design Artifacts grounds Discovery in the actual design process (as opposed to what designers, developers, and stakeholders want it to be).

A Design Artifact is anything that helps to illuminate the current design process. Design Artifacts vary from organization to organization, but may include:

• photoshop files
• design comps
• wireframes
• functional flows
• user journeys
• prototyping tools
• user research

Having these Artifacts in hand grounds the delving questions asked during the Discovery Session in reality, leading to more meaningful conversations about current design processes, technical architecture, governance considerations, and readiness for organizational change.

Typical Discovery topics will include:

• content strategy
• information architecture
• collaboration and workflow between developers and designers
• the workflow used to build and deploy experiences

Design Principles define the functional and aesthetic logic you apply when you build.

Part of the benefit of a design system is clarity around design principles. And while design principles might be murky or inconsistent before the advent of your design system, there’s always something present that becomes their seed. And once they’re well-expressed, your design principles can better serve the purpose of the design system, and all the experiences it will power.

No matter where you are as an organization, clarifying Purpose and Design Principles creates and bolsters valuable self-knowledge, and answers the following questions:

• What is the core purpose of your web product(s)?
• How formalized are your current design principles?
• If you have them, are they used? Occasionally, or religiously?

…and if you don’t have them defined, this is where they’re created, formalized, and widely distributed in the Statement of Purpose and Design Principles.
One last note on design principles (which, since it applies to design systems at large, is a great note to end on): they are living principles. They are meaningful only if they are used. And their health and relevance is predicated on their continued revision and evolution.

Congratulations!

You’ve completed Phase One — your project team has the lay of the land. Now you’re ready for Phase Two: planning how to structure and govern your design system to make it your best navigational tool for the territory ahead.
To be continued…

You can find out more about us at basalt.io.