#6: Our Roadmap, Stage Four

Congratulations! You’ve set up all the dominoes, and you’re ready to start developing your components.

COMPONENT DEVELOPMENT is both inception and culmination — it activates every atom of your project team’s prep work to fill in the scaffold of your Foundational Framework with the actual moving parts of your design system. (Remember: a pattern library is a library of components, and it encompasses how each component looks, how it functions, and how it is used.)

But building the core of your design system correctly isn’t as simple as tipping the first one over and watching it cascade: the magic of design system implementation stays dynamic, all the way until the end. Here’s how.

Take a look at the component development cycle — everything in purple.

Following the flow of the chart, the main thrust of component development is fairly straightforward: build the component, review it and test it, accept or reject it. If it needs improvement, you cycle back to the beginning; if everything looks brilliant, your shiny new component goes into your pattern library.

But the devil’s in the details. Here are five commandments that make or break component development.

(We want to talk about these because they’re important, and because explaining each helps illuminate a different facet of what a design system is and does.)

1. Revise Your Component List
2. Define The Schema Of Your Data
3. Map Your Component Dependency Hierarchy (which components consume which components)
4. Field Test The Build Process and the Foundational Framework With Your Pilot Component
5. Represent A Complete Page As Early In The Development Process As You Possibly Can (it’s great for reassuring stakeholders)

Revising your component list

Notice from the flowchart: to begin component development, you need the list of components you intend to build. And no matter how in-depth your interface inventory, there’s always a little clean-up to be done before you’re ready to select your first component and get started.

Mostly, this involves taking a close look at components and figuring out which should be split into multiple components, and which components should be merged into one.

• An example of when it’s right to split components: a card that contains a button. Better to build the button separately as its own component, so that it can be applied independently to any larger component that needs it.
• An example of when it’s right to merge two or more separate components into one: three slightly different versions of the same card. If 90% of the code used to build each is the same, better to build one basic component, and then differentiate the cards as three different versions — less effort, greater consistency.

Revising your component list makes your components better, and thus creates a better tool for your content editors — your boots on the ground; the ones who’ll be using the design system to create sites and pages. Because component development is about creating the actual reusable pieces of your design system, the entire process should closely consider the people who will actually be deploying content using the system, which brings us to…

Defining the schema of your data

Remember, way back when, when you created your Foundational Framework, and asked such questions as:

• How will your design system be governed?
• Do you want it to be highly structured in order to lock in the will of your designers, and the consistency of your brand?
• (Or do you want it do be pretty flexible, allowing your content editors more creative license?)

Defining the schema of your data essentially means determining how much of your components to expose to your content editors within your design system’s interface. When your people use the design system to build, what you want them to be able to see and control?

The low-altitude question that ties each component to the core purpose of your product, your design principles, and your foundational framework: How will this component actually be used?

An even lower-altitude question: What will the edit form for this component look like?

In other words, what controls do you want to include on the dashboard, so to speak, while the rest stays under the hood?

Above is the dashboard inside a CMS (Content Management System). This is the “edit form” for a media tile — a component which might itself consume several other components to display the page it controls. Notice what’s exposed: drop-downs for text color, text size, and so forth. Notice what variation is available within the component. These are the parameters content editors can control in order to style what they publish: the schema defines what data you expose to content editors.

The choices you keep incumbent on your content editors are as important as the ones you omit, because they each have a hand in creating the right balance of consistency and creative agency for the people who will be building with your components and representing your brand.

Mapping your component dependency hierarchy

This is your order of operations for building. The central idea: build the smallest component first. But zooming in even further, don’t forget that…

…it’s all about style.

At the center of everything, you have the fabric of the design system: the Styleguide. Colors, typography, and spacing that support the tone and feel of your brand. Whatever component you’re endeavoring to build, your component dependency hierarchy begins with that.

Follow the Styleguide, and start small. What consumes what? Build the most granular components first, then use them to construct what follows.

Testing the plumbing with your Pilot Component

When you build components, you are using your design system’s tooling to build your design system’s reusable core. Thus, it’s a really good idea to give that tooling a test drive to make sure it all functions correctly. Simply put, the pilot component is the crash test dummy that vets that tooling and all its involved processes.

The pilot component process sends a component all the way through development so you can take a real-life look at things like:

• Prototyping
• Documentation
• Versioning
• Functionality
• Hand-offs

If something in the process can be improved, now is the time to make the adjustment.

Considering stakeholders: Get a page up and running ASAP

At the end of the day, stakeholders want a design system because it helps their organization build faster, better, and with fewer resources. And because their organization is putting a lot of work, time, and capital into creating the design system, showing an actual web page built with the components (before the entire component library is even complete) is a balm for executive anxiety.

The best way to do this: follow your component dependency hierarchy, and then ask yourself: which simple page or site section (of a preexisting site, or a future one) might you be able to construct first, with the fewest number of components?

…Now BUILD it, Young Paladin!

As you move through component development, your component dependency hierarchy loosens somewhat, becoming more of a Choose Your Own Adventure — but the process remains the same. And as you build more components, you continue to prototype and tinker, which may send some of your earlier components back through the development process as new ways to improve their compatibility becomes apparent. This is something to expect, and to welcome.

Once it’s over, you’re ready to put your design system into motion everywhere you build for the web. You are allowed to be really excited. You’ve created a tool that will safeguard the consistency of your brand, and integrate your organization’s creative direction. And if you take care of it, your design system will provide structure and ballast for your organization as it anchors how you build, facilitates the transfer of knowledge and expertise, and endow your designers and developers with new collaborative power.

Thank you for for reading.

We’d love to know what you thought of the series — what you found useful, what you want to hear more about, and anything that wasn’t crystal clear. We think about design systems every day, and we believe they can make the web better for everyone.

We want to clearly illuminate what design systems are and what they make possible so that more people and businesses can benefit from them.

Visit us at basalt.io to continue the conversation — we’d love to hear from you.

Originally published at basalt.io.