.jpg)
creating something from a system that already exists, it’s about figuring out what’s already there, how it’s being used, and what can be reused.
There is a time in the lifecycle of a design system when you need a change. Things have diverged and it’s a collection of exceptions. People aren’t using what we’re building and just building it all themselves. There could be a number of reasons, but the decision has been made: we need to do this a different way. Congratulations! You’re on the road to a new system.
Answer key questions
First, we need to answer some questions that help determine our approach.
What do we hope to get out of this?
This could be as simple as wanting to do things a different way. It could be that you need support that wasn’t there. But it also could be as complicated as “We have a thing. But it’s not working, it’s not supported, and it’s not helping us in our process in the way(s) that we’d hoped originally. We need a different way.” Answering this question clarifies what we’re going to do, what we’re going to make for teams, and how long it might take.
Are we going to start from scratch?
Starting from a blank page can be a great answer. At the very least, with nothing to build on, the people leading the charge on it have some free reign. From there, a larger group can be consulted to create a federated model and those using the system have as much of a voice and a vote so they don’t just feel as though a system is being forced upon them. Working this way brings everyone involved along and gives them a chance to have input into whatever is being created.
Are there things we can bring with us to reuse?
Hopefully, not all is lost. If there are assets and/or code that can be brought along instead of wholesale thrown out, we need to have a system for how we’re going to manage those changes, what they look like, and what they’re called and mean. Anything you can carry forward is more useful than something that needs to be completely rebuilt, and that ultimately saves a ton of time and effort for all people involved. It also provides you with a backfill system to provide to those who use it as you’re in the process of building that new thing.
Our approach at CarMax has been a bit of a combination of the above. The previous system helped to define what could be reused or repurposed and what would need to be rebuilt completely from scratch.
Starting the re-organization
For those not in the know, the term “The Great Reorganization” comes from the book and movie High Fidelity. In the book, the main character, Rob Gordon, goes through the process of reorganizing his massive record collection as a coping mechanism based on where he’s at with his life. They talk about how he’s had it alphabetized, and organized chronologically, and is now in the process of “reorganizing it autobiographically”.
As we move from the past phase of design systems at CarMax to what Horizon has become and will evolve to be, we also need to support those who are dependent upon the previous system. Reorganizing what we’ve got helps to give structure to where we are and what we’re providing, regardless of whether it will live on in its current form or evolve into something new.
Our plan of attack relied heavily on our third question from above: what we can reuse and how we approach migration from the old system to the new one. As something that we’re actively going through for Horizon (the design system at CarMax), structure and communication have been crucial for everyone involved. We accomplished this in a few ways.
For Horizon and the enterprise design system we intended to create, we knew there was a set of components that we could safely start with because they’re considered table stakes to create anything that exists on the internet or within a UI generally. Things like a button or a text input, all sorts of components that anyone who ever used a computer would know.
From there, they got prioritized. What would be the highest return, lowest effort components to build for everyone out there making digital products across our team?
The working file for the design system was structured the same way as our scrum board; each column became a grouping within a design file that spoke to its status: IDENTIFIED, PRIORITIZED, DESIGN, DEVELOPMENT, RELEASED. This allowed us to communicate where something was within our lifecycle for Horizon if people came with questions. We kept this file open for anyone to come and view and also published a matching status table on our doc site that provided the same information.
This organizational process helped us to be able to identify a list of things to work on, but it didn’t account for things that had already been built and existed: available, ready to use, and with a corresponding coded component that their developers could pick up and run with (in some form). These all already existed within another location, and they had a structure, but it wasn’t as straightforward as what we’d done for Horizon. This was where The Great Reorganization came in.
Reorganizing the library that existed involved some buy-in, but it wasn’t really a hard sell. Similar to the old system, this library was (sort of) crowd-sourced and didn’t have anyone to actively manage it. It had a structure to it, there was code that teams could point to, but it wasn’t as clearly laid out or explained as it could have been. It needed some love, so that was what we gave it.
How we did it
The same process that had been applied to our own backlog was now implemented within this shared library. Components were recategorized into one of five statuses:
- Current: This meant they were in use somewhere in a repo that someone could point to. There was live code somewhere, a design component that existed within this shared Figma library, and some form of super high-level documentation. These are our acceptance criteria for something to be included within Horizon, so it only made sense to follow this construct for this space as well. These components were suffixed with some status to denote what team used it or what its next steps were (if it was identified by Horizon to be built, if it had been rebuilt and released within Horizon, or if someone was working on its next form).
- Development: These are components that have gone through a design phase and code is currently being written. Within our Horizon process, this also defines the stage when we build the full-functioning Figma component as well, but that may not always be the case within this shared library.
- Design: These are components that are in some state of design exploration. They’re not ready for development yet, but work has been started by someone.
- Identified: These are components that have been identified by someone as a need. Where they live and who owns them (i.e., whether they’re within this shared library or within Horizon) depends upon how many teams use them.
- Archive: This is a graveyard space for things that aren’t useful anymore. It includes exploration work and old assets that have been succeeded by newer components.
In addition to reorganizing and reskinning the library, we added in a few things to assist with context and reference based on what was there. These included:
A high-level explanation of what the component was that had been agreed upon at the outset; the placeholder for these definitions was pulled from the component.gallery.
A link to the coded component within the repo so a designer could have something to point to as they began a discussion with developers around what they were thinking within their design and what their Figma components mapped to, if there was matching code somewhere.
A template for documentation. This part is still up for discussion, but providing designers with a template for what documentation should look like is helpful from the system team’s perspective because it provides a baseline for what should be included and how it should be structured.
Ready for the future
Once these changes were made, the next step was socializing the sunsetting process for previous libraries, getting buy-in from people who were potentially using them, and migrating those people to something that would live on. Horizon had been steadily working through its identified backlog, but the process for retiring assets from the previous system that wasn’t being fully supported was another part that required buy-in. It was important to make it clear that they were being replaced by something newer and better; that even though what had been accepted was going away, it was being replaced by something that would work better for both the designer and the person they’re designing for. But again, as with earlier in the process, it wasn’t that hard of a sell. The case was frequently reiterated for why we were doing this: better tools, backed by code, with ongoing support, and ever-evolving to match the pace of innovation as approaches changed. We made it clear that this wasn’t the end; we weren’t going to leave people out in the cold with tools that wouldn’t work or didn’t provide them with what they needed.
And that pretty much brings us up to now. We have a system that people like and use, complete with parity and documentation. Then on top of that, we have a shared components library that functions as a “soft backlog” of things that Horizon might build. This is not to say that things will be built for the enterprise system, but it gives us a list of things that we could build. And it gives designers a cleaned-up library with more context for what they’re getting into, which everyone loves.