Member-only story
Managing Change in Continuous Design
A diagram can be the difference between an organization of “petty kings” doing their own thing and having actionable plans built on a shared identity: What we need is some kind of governance.
This is an excerpt from a course I have released on Newline, called “The newline Guide to React Component Design Systems with Figmagic”. You might also be interested in my article “How To Automate Design Handoffs and Set Up a Design System with Figmagic”.
When we’ve been indoctrinated with this fiery vision of how we can work, and we have all the tooling needed…then what? Well, I’d say we should proceed with formalizing how we want to work into a simple process. The process I will propose isn’t very hard… Note that this is not a limitation, it’s a feature!
Also, I totally understand that most people find diagrams of processes — at best — tedious, but they are needed so that we can embody how we do things into something material. It’s always better (not least, it’s easier) to critique a process instead of a person.
High-level: The change process
The very first thing we want to do is to draw our intended flow: Where it starts, what it can go through, and what its state or states can be.
It’s certainly the case that very complex and distributed systems can have changes emanating from many sources, but these would require some way to consolidate or negotiate how they adopt changes, unless one is willing to have completely out-of-sync variants. Such factors of consolidation could be a review board, an open forum, or anything else that works with your culture and leadership model.
In our case, the typical unit of change could be that someone has identified the need for a new component or feature. Depending on your organization, this intake process will vary; let’s just roll with the assumption that someone has identified a change and that it’s considered valid from a business standpoint. You’ll notice that in our…
