Three strategies I’ve tried for landing a design system into existing software

The “blow-it-up” strategy

What is it?

What do I think about it?

How did this manifest in my career?

The “Ship of Theseus” strategy

What is it?

What do I think about it?

  1. You accept that your new elements may feel out of place in the platform for a while until you can get a critical mass of design updated.
  2. You have to dial back your desired aesthetic changes so that they fit better within the bounds of the existing product.

How did it manifest in my career?

The “land & expand” strategy

What is it?

What do I think about it?

  • It gives designers a big enough scope of work up front to think holistically while also limiting that scope to one landing point, reducing complexity, dependencies and risk.
  • The landing point serves as a de facto testing ground for the system. Because no matter how well-defined a component looks in isolation, it isn’t until you put it in context that you know for sure whether or not it’s delivering.
  • You get both a system starter kit and a visible chunk of new feature UI that can represent it, helping you feel the momentum and build organizational support for expanding the system.
  • It allows most of your customer-facing feature design workflows to continue business-as-usual until the time comes for them to adopt the system.

How did it manifest in my career?

  1. It was already in need of work due to new constraints from the company’s growth.
  2. It was an important feature but not the most high profile. So it had sufficient complexity to test the system but not a ton of organizational pressure to deliver anything too mind-blowing.

In sum

  • Don’t “blow it up” with software unless you really have no alternative
  • Try to make “Ship of Theseus” style system enhancements possible, just don’t expect that approach to be the best for establishing new systems.
  • Aim to “land” your system with a well-scoped pilot project and then gradually “expand” it over time to the rest of your platform.

--

--

--

Principal Product Designer @JupiterOne. Writer of ‘Better By Design’ newsletter on Substack. @itspatmorgan on Twitter.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How to read and understand existing open source code in an efficient way

How To Crack Parallels Desktop 11 For Mac

10 people you’ll meet working with a software house

#NFT WL Puzzle Solution #0034

I love to REST, but is all well that ends GraphQL?

A REST API endpoint returning data about cocktails

How to set up an API with a Cloud Function backend that queries BigQuery on GCP

Rebranding to Netwise

EthSign Community Moderator

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Patrick Morgan

Patrick Morgan

Principal Product Designer @JupiterOne. Writer of ‘Better By Design’ newsletter on Substack. @itspatmorgan on Twitter.

More from Medium

The nature of using design systems (Design ops I)

design ops

Tidy workspace, tidy mind: How to optimize collaboration in Figma

Four collaboration lessons from the Jacobi Design System

Why Your Team Needs a Design System