It's harder to start when there's not a company-led initiative

While it does not take much to see the benefits of a design system, and there's plenty of material out there on the best way to build a design system, it is a bit harder to know how to start when there's not a company-led initiative.

Non-enterprise companies may be more likely to not be familiar with designs systems and their importance, and many times, the need for them is unintentionally discovered in the thick of business needs.

Practical Use Case

Example: A company has found their niche in the _____ industry. As the company has grown, they acquire other startups that are a good fit, extend their product offering, and in turn, take the company to the next level.

Suddenly, there are variety of applications for products living under one company. These applications have originated independently from one another.

As a result, all the applications have very different experiences that they present to the user, even if the due diligence has been done to update the logo and some of the colors.

With time, the business realizes that organizing the applications to reflect one brand and communicate a common feel/experience to users will do much to drive the business forward.

Finally, an initiative for a design system comes. However, all the various teams implemented some small version of a design system (whether in an external codebase or in their existing one).

The company is basically asking for a design system (whether they realize it or not) and someone needs to step up.

If this practical use case sounds familiar (or plausible), then what do you do?

Well, first we need to consider how things would have shaken out in an ideal scenario.

The ideal start

We've discussed a less-than-ideal example. But, how would a design system be started in an ideal scenario?

Ideally, a design system would be initiated proactively and not reactively. Meaning, a design system would be created upfront because of it's ability to set a foundation to craft common experiences, even if the company should grow. This is in contrast to starting a design system when its discovered that the customers are (basically) asking for one.

In an ideal start, the company would dedicate full-time resources (whether internally or externally acquired) to build out a design system.

And hopefully, those resources would include at least one designer and one developer, both recognizing that design systems have to be prototyped by designers and distributed by developers with a huge amount of conversation overlapping the handoffs.

When a design system is created proactively, there are still some dangers:

• The design system team fails to showcase their work and invite visibility/input from other stakeholders (the designers and developers that will be consuming the design system).

Example: On the developer side, the design system assets do not meet the technical needs of all the applications and/or the assets force a technical transition that others don't want to make.

• The design system team releases documentation before it releases assets that can be consumed in code, leading to micro-design systems being created independently of one another.

Putting it all together, here's what we would ideally have when starting a design system:

1. Support from the company as they recognize the business value of the design system (and not just geeking out of designers and developers).

2. Dedicated resources working on the design system, including designers, developers, and a healthy amount of collaboration between them.

3. Communication about the design system to stakeholders, making the work visible through online documentation, well-documented source code, and announce and feedback sessions.

4. A streamlined process for releasing versions of the design system, including both documentation and consumable assets for both designers and developers (i.e. a Figma library, CSS file, shared components, etc.).

Making the best of the less-than-ideal situation

Ok, so that's the ideal situation, but what about when you are in the less-than-ideal situation?

Meaning, you are in the situation where you see the need for a design system, but there is no company-led initiative.

Usually in such a case, bandwidth and deadlines are tight but the need for a design system is wide.

What do you do?

Well, you have three options:

1. You put together a strong case, including the business impacts of a design system. Then, you pitch it to whoever can make it happen (whether directly or by promoting your case).

2. You create an initiative within the designers and developers, creating a proof of the concept and then doing the first option collectively.

For this option, you would start by putting together a strong case for a design system, but you focus more on the impact on the designers and developers. You pitch the idea to a group of designers and developers, and then see what happens.

1. You wait it out.

Truth be told, you need a bit of each of these options.

Everyone needs to familiarize themselves with the practical and technical implication from the perspectives of the business, the designers, and the developers. Everyone needs to know why a design system is valuable. Plus, you'll need to be patient throughout the process.

While each option has an element of truth to it, you'll need to discern what approach is best in your specific scenario.

Regardless, here are a few things you could do to get started:

1. If you're a designer, start organizing a design system in your design tools and drive product-specific prototypes from the unofficial design system.

2. If you're a developer, create a POC of a design tokens pipeline. If there's no designer with an unofficial design system, then reverse engineer one and organize it in code using design tokens. Surely, there are some commonly used colors, typography, etc. that you could organize. There is always a design system, it's just a matter of whether or not it is formalized/organized.

3. After a POC has been created, begin to share your progress with designers and developers you work with.

4. Prepare your pitch. Write out how you could communicate the value of a design system, and how you could speak to the specific points of interest depending upon whether you're speaking with a designer, developer, and business person.

5. Lay out some ideas of how a design team could be formalized. What resources would be needed? How would those resources work together? How would the team invite visibility?

6. Create a roadmap of what needs to be done to get to a stable state with a design system and its consumable assets.

7. Be patient and wait for an opportunity. Discern who to speak to and when.

Conclusion

When working for a company that is not aware of the value of a design system (a not uncommon case for non-enterprise companies), take initiative to lay a foundation and gain momentum.

Although the business may be reactionary, you do not have to be. That is no knock on non-technical workers, but with your creative, technical mind, understand that you may see things before others do. And when that's the case, taking initiative is better than wallowing in disappoint.

Don't become discouraged. Although in some ways the less-than-ideal scenario is (...well...) less-than-ideal, it can eventually bear sweeter rewards. There is always pros-and-cons, and do your best to see the pros.

What can you do to help start a design system?