Your systems pitch got a green light. You’ve started designing, building, and documenting your library. Your first big release approaches fast!
Hey, don’t forget your customers.
During that formative period, you’ll begin aligning with product teams intending to adopt your system so that you can:
Whether a product adopts all at once or incrementally over time, you can help them understand how to adopt by breaking it down into a series of steps. And the more you make it feel like a checklist, the better.
Teams adopt systems at different rates. New products are easy: use the system as a foundation to achieve complete adoption from the start. For existing products, it’s more complicated.
Some choose to stop everything, throw out the old, implement the new, and get back to work in a limited number of sprints. This big bang approach occurs because teams see immediate value (yes!), are forced to (sigh…), or want to just do it and move on.
Others yearn for an incremental approach, saying “We’ll be successful if…
Bit by bit, part by part, the system weaves in alongside features work. This feels both safe and consistent with how teams make products.
Takeaway: Translate their risks into a workable adoption that’s faster (“big bang”), slower (“incremental”), or something else.
Those that don’t go all the way right away need to know what’s important, how to approach it, and how far they are expected to go.
<div class="escom-pull-quote escom-pull-quote--light">
<div class="escom-pull-quote__the-quote">
“Help me understand how to order changes over time as a roadmap.”
</div>
</div>
You can show how adoption works by depicting how to go from an initial commitment to full adoption via incremental achievements based on specific criteria. For a more straightforward library of style and components, a model could use levels with literal names and detailed items:
For a system of broader concerns, a model may use more abstract level labels and include broader criteria for accessibility, editorial, and patterns:
Pitney Bowes’ design system team uses a similar progression across levels, noting that not every product aspires to reach the highest level due to constraints, plans to retire the product, or other reasons.
A model should progress from simple to complex, from most to least important so that teams can achieve levels with an unambiguous checklist.
Takeaway: Create simple levels to progress adopters across levels, with meaningful achievements you can tout at each step.
A deep system — style, components, patterns, editorial,…—intimidate a product team that may already feel overwhelmed by their own backlog.
However, scrumming product teams live and breath stories achievable in a sprint. Take advantage of stories to help express system achievement as:
Talking in stories is to talk the language of how teams organize work. Stories clarify specifics, align achievable goals, and present an opportunity for system team members to influence tasks.
Takeaway: Work with team members — managers, designers, and engineers — to order and craft stories based on their needs.
Products are different. Slotting a system can be straightforward for products already built and tested modularly.
However, systems can’t mandate that a team changes how it does business. Other teams have a far less systematic codebase, and may implement a page type at a time. Adoption can spread across deployments of pages or sections: early pilots give way to converting high value pages while other stragglers may be converted later (or, let’s be honest, never).
Some apps deploy features that span pages and shared components. Centralized system updates to such feature-based approaches can trigger an expensive, wide-reaching testing cycle for every tiny change. Until that team starts encapsulating work better, your collaboration with them may include more rigorous planning.
Takeaway: Empathize with how teams approach their work to tailor system integration and how you report on their adoption.
Systems change over time, and products can’t let their system version get too stale. Therefore, incorporate criteria around aging — “How old is your system dependency?” — for products to maintain higher levels of adoption. If a product’s system version gets too old, slide it down to a lower level.
Takeaway: Set expectations: it’s not one and done, and upgrades will come. Falling behind doesn’t mean failure, but may mean there’s more work to do.
Even after you pitch a system and move forward, expect to meet varying levels of often justified resistance. Interviews with and surveys of product teams — particularly from product managers — reveal themes of size, priority, and momentum.
Some see a system as a beastly monolith. That’s reasonable: it’s a big library!
<div class="escom-pull-quote escom-pull-quote--light">
<div class="escom-pull-quote__the-quote">
It’s too big to succeed. We can’t start some huge redesign. Migrating our product is too massive an undertaking.
</div>
</div>
Yet, a system is modular. It has lots of small parts. Some parts can prioritized and adopted independently, others ignored as irrelevant. Adoption isn’t an all or nothing, all at once. Instead, as you teach teams about the system, also probe what’s relevant to them versus what’s not, and how important each one is to their product.
Takeaway: Systems ≠ monolith. So shift conversation from adoption as “all or nothing” to it’s modular essence.
Product teams have a backlog bursting with features, optimization, and defects. What else do they have? Built buttons, massive modals, cards with content. Don’t they already have all the system offers?
Conversation can tilt to a torrent of reasonable objections like:
Use their language: cohesiveness IS a feature, both within their product and even more across a portfolio. Tactics can include:
Takeaway: Lean on leadership to endorse a portfolio-wide feature, and then steer conversation to benefits specific to their product.
A team’s velocity and momentum towards objectives is paramount. The system cannot get in the way. Admittedly, system adoption can hinder short-term momentum of feature development.
<div class="escom-pull-quote escom-pull-quote--light">
<div class="escom-pull-quote__the-quote">
Pressure from management has meant we’ve been on the feature treadmill for so long that we can’t get off.
</div>
</div>
Take the long view. Product teams will speed up gradually to a new level by ceding small solutions to a shared effort. They’ll also achieve benefits that they can’t do themselves or refuse to prioritize, like accessibility.
Systems are modular, efficiencies, and a platform for cohesiveness everyone believes in. Keep those in mind as you get down to brass tacks.
Takeaway: Long-term benefit can require a short-term cost, so reverse system perceptions from disabler to enabler and focus on efficiencies that improve what they already have.
Systems are modular, efficiencies, and a platform for cohesiveness everyone believes in. Keep those in mind as you get down to brass tacks.
You may see yourself as a system “advocate.” Or even a system “evangelist.” After years, I’ll admit: I’m a system “salesman” too. Following a systems pitch, I ask simple questions to sense if a product team is serious:
Inquiries are pragmatic and direct, not pushy. My goal: clarify a commitment — or lack thereof — to adopt.
It’s easy for a team to say they should adopt a system. But that’s different than articulating they will adopt a system. I’ll drive a conversation to:
<div class="escom-pull-quote escom-pull-quote--light">
<div class="escom-pull-quote__the-quote">
“I‘ve been asked to report on which products will and will not adopt the system. Should I put you among those intending to adopt?”
</div>
</div>
Ask the question, let them fill the silence that follows. If I get a “yes,” I can move on to the more interesting how soon and how much next.
Takeaway: Getting a product to declare intent only begins the conversation.
When you ask “When?” be ready for anything. Actual dates? Now we’re talking! Overt dithering? Don’t be surprised.
Some may avoid any talk of any timing whatsoever. They may cite a locked roadmap or allude vaguely to “next year.” These are completely reasonable, so respect their boundaries. Probe and add context of your constraints like:
<div class="escom-pull-quote escom-pull-quote--light">
<div class="escom-pull-quote__the-quote">
“Leaders indicate to me that 24 months is too long, so…”
</div>
</div>
This can narrow to a reasonable range (“How about 12 to 18 months?”) balancing product commitments and an enterprise’s systematic aspirations.
Takeaway: Bracket time estimates to narrower gaps to make discussions more precise and to inform subsequent planning with leadership.
Planning isn’t free. It takes work to learn a system, analyze a product, and plan an integration. Those sessions, emails, and hallway conversations aren’t just with you, either. They include product stakeholders too.
Such planning can take from 10%-50% of the time it takes to adopt overall.
Takeaway: Acknowledge the effort in and reward a team’s completed planning efforts by recognizing it as a milestone within your model.
Most teams deploy system assets as a reusable package such as via node package management. Getting the system in a product’s repository might be as simple as a one line pull request, like:
"dependencies": {"designSystem":"1.2.0"}
This commit marks the start of code dependency and a lead engineer’s signal of good-faith intent. It’s also an easy, early and tangible milestone.
Takeaway: Recognize a product integrating a dependency (such as via npm) as a milestone that forges a code relationship between system and product.
Code integration is one thing. Tangible design impacts is another. A few system-aligned improvements launched in production can boost momentum and result in small but meaningful customer impact.
These “Hello, system!” moments provide both product and system with a demonstrable win during a sprint review or system roadshow update, respectively. Aim small, start small, build from there.
Takeaway: Celebrate the moment a product launches a feature that depends on the system. You’ve achieved something, together!
For products citing imminent adoption, get specific on timing. If you to know what sprint they’ll begin and end an effort, you can:
Takeaway: Do what you can to be by their side to improve trust and confidence in the system.
With both individual products as well as reporting organization-wide, you need a structure monitor and report on adoption. This can be as simple as an adoption scorecard depicting products grouped by priority as rows and adoption levels, status and notes as columns.
Include the scorecard as front matter of a periodic update. Improvements can be displayed by movement from left to right across levels or via green and arrows for positive and negative progress.
Additionally, keep an initial focus on the portfolio before telling product-specific stories. Once you’ve set the tone with a summary, then you can dive into more detail around how active an flagship product is making incremental progress on some features but not others.
Takeaway: Monitor & regularly report on adoption with a scorecard across products, and make it visible to leadership and the community.
Some products may only partial adopt a system. A legacy product may warrant little further investment. A platform with limited flexibility inhibits modern design.
No matter the limitation, highlight accomplishments without making those products appear as second-class citizens. It can often be more effortful for such products to adopt system, even the basics!
Takeaway: Protect reputations of products justifiably not going all the way.
Praise recent adoptions during periodic system presentations as a lead story! Not only will those teams feel rewarded, but that achievement — product adoption — is the primary objective, more than any flashy component or tool you now offer.
EightShapes can energize your efforts to coach, workshop, assess or partner with you to design, code, document and manage a system.