Pilots are one of the best ways to put your design system through its paces, especially before the design system even gets to a v1. Like television pilots help test audience reactions to a series concept without investing significant resources to create the whole thing, application pilots are a good foundation for ensuring your design system’s design and code are battle-tested.
Here is how my teams and I identify great pilot candidates.
First, we want to know what kinds of digital products a design system should help our client to make. We’ll ask them to tee up as many product presentations as they can muster. They’ll usually do this by either generating a list of product owners that tend to be early adopters/risk takers, or they’ll issue an open call for willing participants.
We review anywhere from dozens to hundreds of existing products to get a good lay of the land for what the organization makes regularly and supports. This might be walking through products in person or on a screenshare with a product owner, asking questions and exploring as many of the hidden crevasses as possible. It also could be clicking through public or private apps ourselves, inventorying what’s common.
Simultaneously, we’ll also do an interface inventory, taking note of the frequency of usage of common components.
We’ll then try and reverse-engineer where our Pareto principle comes into play: what 20% can we design and build that can assuage 80% of the wheel reinvention pain?
There’s a sweet spot for great pilot candidates after planning for the pilot has begun but before it gets designed or built. If a product isn’t far enough along in planning, we likely don’t know enough about it to say whether it’ll make for a good pilot or not. But if it’s already in the process of being created or recreated, it’s probably too far along to be able to integrate parts—read: component design, patterns, and/or working code—from the design system without some amount of refactor, which teams in need of a design system often can’t afford.
I’m talking specifically about products that are being built from scratch or reimagined. However, it’s entirely possible that you may have a product already built that’s clearly a good foundation for a design system. If that’s the case, no need to pilot; instead, extract and abstract the appropriate components and patterns you need. Mobile designer Josh Clark describes this in more detail in his article, “The Most Exciting Design Systems are Boring.”
Once we find a some good potential candidates in that sweet spot, there’s a set of criteria we use to determine a pilot’s potential efficacy:
You might already see where we could go with this. Using a simple point system where 1 indicates a low match and 10 indicates high efficacy, you could create a Pilot Scorecard that shows you which products to tackle in priority order:
| Product #1 | Product #2 | Product #3 | |
|---|---|---|---|
| Common components potential | 10 | 3 | 5 |
| Common patterns potential | 2 | 4 | 4 |
| High-value elements | 8 | 3 | 2 |
| Technical feasibility | 3 | 1 | 5 |
| Available champion | 5 | 4 | 8 |
| Scope | 8 | 3 | 8 |
| Technical independence | 10 | 7 | 7 |
| Marketing potential | 4 | 6 | 2 |
| Totals | 50 | 31 | 41 |
| Averages | 6.25 | 3.88 | 5.13 |
Starting with pilots before you have anything in your design system allows invention to happen in the products. In the next pass of using your design system, you can cook with your new ingredients to make sure you have the right pieces in place.
Have you used pilots in your design systems journeys? How have they helped you?
Thanks to Brad Frost and Josh Clark for helping inspire this insight and reviewing this article.
Read Next
Join 5,300+ subscribers to the weekly Dan Mall Teaches newsletter. I promise to keep my communication light and valuable!