It’s easy encouraging teams to adopt a new component into a design system. Right?! It’s shiny… ooohhh aaahhh! But, how about encouraging adoption of an improved component, especially when a team already has said component in their product. Now that’s harder. 🧵 - ThreadSky

robjmccarthy.bsky.social • 99 days ago

It’s easy encouraging teams to adopt a new component into a design system. Right?! It’s shiny… ooohhh aaahhh!

But, how about encouraging adoption of an improved component, especially when a team already has said component in their product. Now that’s harder.

🧵

Comments

robjmccarthy.bsky.social•99 days ago

Design System folk: I would love to hear tips and techniques you’ve tried and tested to encourage adoption of improved components?

Or another, somewhat corporate way of putting it, what change management techniques have you successfully applied?

yonatankra.com•97 days ago

We maintain and apply semver with zeal.
Any new feature or bug fix should not in any way break current interface.
In regards to design - if a design changed, it means it should change company-wide, and then an upgrade is mandatory to comply with the "same look and feel" policy of the DS.

iknowdavehouse.bsky.social•99 days ago

Ultimately though, this is one (only?) drawback of the Gov approach to component definition - it’s difficult to release a change that fundamentally changes the HTML structure without a consumer needing to do anything.

robjmccarthy.bsky.social•98 days ago

Yes to all you’ve said Dave, thanks for sharing your tips.

And yes to making it as easy for the consuming user as possible. I think that’s definitely key, especially if it comes to a PM prioritising a backlog.

“Why do we need to spend time updating this thing when we already have it”.

iknowdavehouse.bsky.social•99 days ago

There’s probably no silver bullet for this. On the consuming side, culture shift with Product to make sure maintenance is factored in - suggest they shouldn’t ever really be 2-3 versions behind and updating the version of the package every 3-4 months will save a lot more time in the long run…

iknowdavehouse.bsky.social•99 days ago

On the design system side it’s making sure your changes are as easy to update as possible. Ideally the team would have to do nothing. For example, is there a way of making this change that doesn’t require a change to the template? Anything that requires “a discussion” on the consumer end will delay

iknowdavehouse.bsky.social•99 days ago

If there are wholesale changes to something people use a lot, it may be worth giving them their own release. There is also the potential of trying to automate the work - if you look up the concept of codemods it might be something to consider. I think it was Shopify that have an auto updater script

wolfbruening.de•98 days ago

1. Build your components in a way, that switching to new versions is minimal or even happens automatically. Web Components are a solution for that.
2. Invest time in community management. Foster a great relationship with the devs consuming your DS. If they feel that you really care about them… (1/2)

wolfbruening.de•98 days ago

…and their needs, they will be way more open to snuck in a little extra task to switch to the new component. For them it's a good feeling as well to have the part of their product "up to date".

frankieroberto.com•99 days ago

Having support for multiple tempting languages and frameworks, whether officially or community-maintained, massively helps with this.

Eg see https://x-govuk.github.io/posts/releasing-rails-libraries-for-version-5/ from @peteryates.bsky.social which made it much easier to Ruby projects to update!

robjmccarthy.bsky.social•98 days ago

An amazing community resource. Thanks for sharing it Frankie.

marwa.gorvan.com•98 days ago

This is a pickle of a problem. We basically pull support from old components and eventually deprecate them. If they need help they need to update their designs with the newest components.

Comments

Posting Rules

Reply