Drift: why your Design System isn’t working
Plenty of existing literature talks about treating your Design System like a Product in its own right — some people may even be so lucky to have someone dedicated to overseeing it. This is absolutely the right approach to take, but there are still threats on your journey to adopting and experiencing the benefits of a well-orchestrated Design System. One threat that many can’t see or manage until it’s too late, is drift.
Detecting drift is tricky enough, but there is one role you can add to your team that will not only identify drift from a mile away, but eliminate it before it gets out of hand. With the role in your arsenal, what normally takes weeks will take only a matter of days. In some cases, hours. Whilst I’m sure your journey is still possible without this role, you’ll save yourself from running around in circles and chasing your tail asking yourself why it just isn’t working yet.
If you want to learn the basics, there’s already existing literature about how to bootstrap, how to grow, and how to structure a Design System.
Where drift comes from
Drift begins as soon as you begin to build any software product, even if you bake in a Design System approach from the start. It’s like tech debt that creeps up on you until it’s too large to unpick on its own. God forbid you end up creating something as difficult to maintain and iterate on as legacy banking software.
I’ll recap the typical steps taken from idea to production code, assuming you’re still growing your library of Components:
- a problem is defined, ideated and a wireframe solution is produced, using design best practices
- once the wireframes are shared and critiqued, you use your existing components to build a high fidelity prototype
- design critique and user testing help to refine that design and any new components created
- handoff happens from design to engineering, and your designs go into build
- the cycle carries on with the next iteration, or the next piece of work
