(Excerpted from Design That Scales.)

As you’re scrutinizing your organization’s many digital products, you’re bound to encounter multiple variations of the same component, likely stemming from the lack of connection between design teams. For example, a cursory glance through multiple digital products from American insurance company Allstate reveals nine separate kinds of text inputs:

How could you reconcile all of these into one canonical version? The key lies in reusing as much of what already exists within each of these variations. Note the commonalities across four different criteria:

1. All: What do all versions of this component have in common?

2. Most: What do most versions of this component have in common?

3. Some: What do some versions of this component have in common?

4. Few: What do few versions of this component have in common?

In the case of this text input component, the chart breaks down like so:

1. All: White background; border

2. Most: Placeholder text

3. Some: Rounded shape vs. rectangular shape; italic placeholder text vs. regular placeholder text; border vs. no border

4. Few: Icon

As you start to design and build the “new” abstracted component, approach each area of the chart with these directives:

1. All: Every characteristic is mandatory

2. Most: Every characteristic is highly recommended

3. Some: Prepare proposals and/or facilitate workshop to form consensus

4. Few: Delay including these characteristics

All and Few are the simplest. If every text input has a white background, make sure that the consolidated, abstracted component has a white background. If only a few text inputs have icons, don’t include an icon just yet; wait for that obligation to become more common.

Most is a little trickier, but not much. If most text inputs have placeholder text, it’s a safe enough bet that your abstracted component should have placeholder text.

Some is the most contentious criteria by far. If some text inputs are rounded and others are rectangular, how do you resolve that conflict? The most infallible way is to facilitate a workshop. Call together as many people who have their own versions of the text input as possible and get them to agree to as much as you can. This effectively moves the characteristics up into the All or Most categories. For characteristics where an agreement can’t be reached, try to at least get the participants to agree that the design system team’s choice will be the tiebreaker. Given all of this, your abstracted text component may end up looking something like this:

The important thing about this version is that as many people as possible can look at it and conclude, “That looks pretty close to what we already have,” because they recognize some overlapping characteristics. In that way, they may feel like they’ve “contributed” that characteristic, which is a major boon for component adoption.

Follow these tips to increase the likelihood your components become great headstarts.