How tokens, components, and patterns are pushed and pulled into a living, breathing Design System.
By understanding how Design Systems fit into the wider product development lifecycle, its chances of succeeding are better. You don’t need a dedicated team to start getting its benefits. It’s more than just components, too. I wanted to share how I was able to successfully build out a Design System from scratch, and used a “push/pull” mental model to embed a Design System culture.
Here’s an introduction to Design Systems, that’s friendly for non-designers, if you‘d like a refresher.
First, let’s recap a typical product development lifecycle, taking more of a Lean UX approach within a team working in sprints.
- As part of your Discovery Process, a new feature or problem is identified, and you’ve validated it’s worth investigating
- Next it goes to Definition and Wireframing. You articulate and agree the problem to be solved, identify barriers, do post-it note based storyboarding, and assemble some rough wireframes
- Next is Design Critique—getting input on this early thinking in a cross-team forum, and/or sharing it for technical input
- If that all looks good, it’s off to High Fidelity Prototyping. The fun part of using Figma to make a real solution tangible, with regular design critique throughout
- A quick Test and optionally Iterating on the design helps to work out any kinks in the flow or edge cases you hadn’t originally foreseen
- Handoff to your developers, and then Implementation begins
- Finally you may have QA or a Product Check before a Release
Assuming that all went smoothly, so the cycle carries on. Represented visually, it might look something like this:
With a basic product development process established, we can now introduce the two main forces in a Design System: push and pull.
- A push is when something is contributed to the Design System
- A pull is when something is consumed from the Design System
Pushing can be difficult to get right, because there isn’t a one size fits all. Even with a few set strategies in place for pushing, it’s not always clear at what point to push updates. It can happen at design time, at the end of implementation, or even way at the beginning you might realise there’s a system gap during the discovery process.
Much like the design thinking process, pushing is non-linear.
Informal pushes and young systems
Pushing, or contributing, to the system is what you’ll predominantly be doing in the early days. There isn’t a set time in the product development process where this can happen. Sometimes you’ll want to compile the resources you need before prototyping, and other times after handoff.
During system infancy, you and the team will be using mostly ‘scrappy’ methods to start compiling token, components, and guidelines together to form a rough system. Consider these as “informal” push methods.
Just because it’s scrappy doesn’t mean you should shy away from them, though. In fact, Dan Donald covers this very topic in his recent Zeroheight piece “Just do it — getting started with design systems”.
Formal pushes and mature systems
As the team and system matures, the methods used becomes more formal. Instead of adding components as you go along, you’ll have a method of assessing:
- What problem does this new thing try to solve
- Can the existing system express this already?
- If it’s worth it, a full process to design, develop, and document it
- Formal release and notification to all teams
I watched a fantastic webinar on the highly structured process they use at Booking.com, titled “Multi-platform design system at Booking.com”, delivered at Figma Config 2022. I highly recommend it for those with larger design teams, or with a team pre-dominantly dedicated to the system.
Over time, you start to establish, then mix and match, formal and informal methods of contribution.
Best times to push
Whether formal or informal, there are two key points in time that are great, in my opinion, to perform a push:
- During handoff—at this point, the design is mostly formed, and you can be more strict in capturing only work that will be in the product. Before picking up a new piece of design work, it’s great to do the housekeeping.
- After implementation—for teams that check their work before releasing to users, this is even more crucial. You can keep the code and the design assets aligned, capture user-facing work, and track drift.
Tackling Drift
After some time, you may notice something called Drift. Drift in Design Systems is where differences appear between the components the designers use, and the components the engineers use. It can, and will, happen to every design system no matter how eagle-eyed you are.
After all…
Humans are flawed, and thus systems we create are flawed, too.
I like to think of it as a tax that’s worth paying in order to have a system at all. It’s helpful to perform regular maintenance or “reconciliation” to keep drift to manageable levels.
Summarising push:
- pushes happen all the time, whether a system is young or mature
- the types of pushes can change over time
- informal pushes tend to add bulk and mass
- formal pushes are fine tuned additions, or refinements to existing work
- reconciliation is necessary, otherwise you get Drift
In contrast, pulling is much more straightforward. As long as there’s a central place everyone can start from and get resources to deliver on the product development process, you’re golden. Typically that’s a website or a wiki like Zeroheight, supported by things like Storybook and a Figma file.
For those compiling these together, be sure to:
- consolidate resources and how-to guides in one central repo
- cater to roles in your team e.g. designer, developer, product manager
- share, educate, and embed until it becomes the norm
Yes, garnering adoption will depend on how open the team is, but half the battle is simply providing a clear set of resources. In my experience, you’ll get success sooner by making it easier to use the system, rather than doing it from scratch.
This doesn’t mean you should compile resources and disregard or disrespect how each team likes to work, especially at a larger organisation, but it’s a great place to start.
Why don’t we pull during wireframing?
Great question—you do a little, but on the whole it’s all about semantics. During the wireframing process you’re more concerned with the flow and the semantic elements of a journey you’re putting together.
It doesn’t matter whether I use Material Design, Bootstrap, or Atlassian’s design language. What matters is if I use Tab UI, a Carousel UI, or a Two-panel Selector Pattern.
Once I’ve selected the best semantic choice to best solve the problem, then I can decide whether a push is necessary if the system doesn’t have that component, or to compromise.
Just like when exercising your muscles, you can do too many push exercises or too many pull exercises. The body likes to be in balance, and so does the system.
What I’ve found and keep coming back to, is a golden snippet from this article Design Systems are flawed:
“The system doesn’t define solutions; solutions define the system.”
I think it’s crucial that you’re constantly probing into each product team, to see how much or how little of the system is being used. It gives you incredible insight whether you’re providing the right resources for the challenge ahead, and whether you’ve designed it well to be used or not.
As a rule of thumb, a useful system encourages at least one pull per feature designed and deployed.
We could easily get lost in the complexity of a Design System, so this push/pull abstraction serves as a mental model that’s memorable and actionable. From beginning to end, Design Systems are inherently intertwined with the product development lifecycle.
Typically, young systems will push a sheer volume of tokens and components, whereas mature systems will be pushing patterns and refinements. Most importantly, get people pulling at least once per feature—to help, design some habits to get people Hooked.
Read the full article here
