Design Configuration Management: The Awesome Best Practice You Didn’t Know You Needed

We’ve had a design practice at SEP for over a decade but didn’t have an official Design Configuration Management (DCM) process until recently. For most of that time, we’ve been a pretty small group of designers who typically had their hands full doing good work for our clients. Historically, designers on a project would hit the ground running and get right to doing the work, applying best practices as they went.

As we’ve grown our practice, we have learned better best practices, such as unified processes for storing, managing, and caring for our assets and creating our own DCM.

What is DCM?

You may be familiar with Configuration Management (CM), which is a process for establishing consistency in a product throughout its lifecycle (Atlassian). This is frequently seen more on the engineering side of software through things like version control.

So, what differentiates Design Configuration Management from regular CM?

We wanted to apply the same concepts, which ensure consistency across projects, to product design specifically. It was no easy task. Establishing a consistent practice with one unified brand at a software product company can be complex enough. We needed one that spanned many project teams, industries, and complexity levels without adding extra work to the designer’s workload.

With our goals in mind, we set out on our DCM creation journey.

Why DCM?

Before we get into the final product of this journey, let’s answer one question:

If we have projects ranging from quick, single-product applications to large-scale, multi-year projects that span multiple product lines, why would we take the time to define a process that aims to work for all of them?

The answer has several parts.

👥 Streamline Team-to-Team Collaboration

We wanted to make it easier for everyone when designers and developers change projects. If all our designers use the same processes, picking up where the last designer left off will be much easier.

The same goes for the engineers. If the designers work the same on any project they move to, the staffing swap is much smoother. Everyone can spend less time learning processes and more time collaborating and solving problems together.

📜 Meet Quality System Standards

We wanted to make sure that our design process met our quality system standards.

Since 2003, SEP has held an ISO 9001 certification. In short, that means we are committed to ensuring quality for our clients, managing risk, and continuously improving our systems. Design configuration management plays into all of those aspects. We ensure we provide quality code, so why wouldn’t we do the same for design? We’ll start by following our DCM process and evolving it over the next several months until it’s ready to be formally incorporated into the SEP quality system.

↗️ Scale Design Practices

As we grow our practice beyond our current size, we want to make sure that we have consistent best practices among our designers to continue providing quality product design to our clients.

DCM for a Custom Software Consultancy

As a software consultancy, we have a wide range of projects, both in industry and in complexity. Some of our larger projects cover multiple product lines and devices, while others are a single small application. Our DCM process needed to account for both ends of this spectrum and everywhere in between.

When we started working on our DCM process, we looked at the project with the most robust design process to see what worked well for them.

Navigating Complex Design Projects

This project had files broken out by category, like a Source of Truth that showed the most recent, stable designs and a Design System, which housed all the colors and design components, and then by product. That project began with a much simpler architecture. Still, as it grew to encompass so many products, it needed that level of separation for the sake of wayfinding and Figma performance. Just one application can have dozens and dozens of screens.

Imagine trying to navigate several of those all in one file!

Organizing on a Smaller Scale

Next, we looked at some projects with a more informal design process. These projects tend to have shorter timelines and work quickly. They also typically have only one or two products to keep track of instead of many.

For that reason, it made more sense for them to keep all their assets in one Figma file. Some areas were typically dedicated as a Source of Truth, and others were more unofficial work in progress. How those were individually structured varied between projects.

Mapping Existing Practices into a Process

Once we had our parameters, we began creating our process. We wanted to keep it open enough that designers would have the flexibility to meet the needs of their team while still maintaining a consistent practice. It needed to be clear what was official (source of truth/what developers should reference) and what was a work in progress.

Conveniently, a while ago, some of our designers created a file template in Figma to spin up teams faster with this exact architecture. Our smaller projects could use this template to define these areas of work. As the project grew, they could split out the different sections when it became too unruly to manage in one file.

With this, we had a common architecture all our designers could use, but we weren’t done yet.

Adapting DCM to the Quality System

In addition to structuring our files clearly, we need to ensure that what we tell the client we are going to make matches what was made. This is recorded in the statement of work at the beginning of the project.

However, it’s not uncommon for what the client wants to evolve as more information becomes available. If a project gets audited for quality systems purposes, we need to be able to show that what we told the client we would do and what we ended up doing match. Leaving a “paper trail” of all the pivots and client decisions we encounter along the project’s course helps us do that.

The Nuts and Bolts of a Design Configuration Management Process

Now that we have some structure for the process, let’s put it into practice. A lot of our DCM process shouldn’t sound too revolutionary. It may seem like common sense, but we wanted to be explicit in how we practiced for the sake of consistency across our diverse project portfolio.

There are two core aspects of our DCM process:

1. Stay organized
2. Document your work

1. Stay Organized

Staying organized covers everything from keeping your workspace tidy to the orderly structure of your Figma files. We all know the design process can get messy as you iterate through idea after idea. Your first idea may not be the best one, so it helps to consider different ways of solving the problem to find the best solution.

If you take a second to document your design decisions along the way, any future designer can see what you were exploring and where you landed.

The other aspect of staying organized with DCM is structuring your files properly. There should be a clear delineation between what is work-in-progress and what is official. Official pages should be stable and consistent since clients and developers will be referencing them.

These pages will include the Source of Truth, the Design System, and the Tickets page, which is a zoomed-in view of designs for a specific development task. On the Source of Truth and Tickets pages, leaving annotations or implementation notes that supplement acceptance criteria in the work tracking tool ticket can also be helpful.

2. Document Your Work

Annotating your work is another big part of our DCM process.

Have you ever returned to work you haven’t touched in several weeks? It can be so difficult to recall what past-you decided and why. That’s what we’re trying to prevent.

Not every little decision needs to be recorded, but just enough so that “future you” or the next designer can know what you were thinking and pick up where you left off. We drew inspiration from these design annotation recommendations to shape our best practices on design annotations.

Besides just documenting your own design decisions, we are also encouraging designers to leave implementation notes near design artifacts. Sometimes it can be hard for a static 2D asset to convey all the information that a developer needs to make a dynamic application.

That’s where implementation notes come in! Implementation notes are extra explanations paired with a design artifact to help explain details of the design that the viewer may not notice or account for during development. These could cover things like page transitions, micro-interactions, previous client decisions, or hardware limitations.

—

Adopting & Implementing New Design Practices

Creating our Design Configuration Management process was a nuanced challenge from start to finish. We needed to account for a wide variety of complexity on our different projects while still satisfying the specific needs of our quality system. We chose a file template that could be scaled with a project’s growth so each designer has some flexibility to implement the DCM process in a way that works best for their unique project.

Encouraging designers to keep a paper trail of design decisions, annotations, and implementation notes helps us stay in alignment with client expectations. These practices also prevent details from being lost in the transition from Figma designs to live code.

By integrating these practices into our design workflow, we should see increased consistency in our design work. Also, it greatly improved the experience when people switched teams. Now, all that’s left to do is do the configuration management of our configuration management system!

You Might Also Like

• Chaos or Clarity? Improve Your Product Design With Systems Thinking
• The Building Blocks of Design Hierarchy
• 10 Figma Shortcuts to Improve Your UI Design Proficiencies