Agile, design systems and the great railway gauge war
On the 15th of September 1830 a grand ceremony launched the newly built Liverpool and Manchester railway. The new line was part of the first ever railway boom in history. Fuelled by new steam engine technology and a desire to make a fat profit, privately funded railways sprang up all across the country. Thousands of miles of new track were laid at an extraordinary rate, allowing freight and people to be transported like never before. Soon however it was apparent that there was a problem, a very big problem.
Each railway company had used its own gauge (the distance between two railway tracks — see image below) meaning that a train running on one line invariably couldn’t run on another. Because each company had worked in isolation, and without agreed standards the railway network wasn’t a network at all — it was a collection of unconnected tracks. There followed a period now known as the ‘ Gauge War’. Different companies went into battle, desperately hoping that their gauge would come out the winner. Finally in 1846 regulations were set-up to establish a standard gauge (4 feet and 8.5 inches). However, even with agreed standards in place it took many years, and thousands of miles of track being re-laid at great expense to finally connect the country together. The great ‘Gauge War’ was finally over.
Designing without a design system
History has a habit of repeating itself. Many organisations that have moved to Agile have experienced their own version of the railway ‘Gauge war’. Like the early railway builders, Agile teams working without a shared design system in place risk building unconnected railway lines with different gauges. Not only are they likely to be continually reinventing the wheel (or track), they will be creating designs that are inconsistent for users and incompatible with those from other teams. This is not only inefficient, it can also lead to damaging design debt quickly building up (see my article how to deal with design debt for more about this).
Without a design system in place teams tend to spend an awful lot of time worrying about the little details, such as which shade of grey a button should be, or how many pixels wide something should be. Having a design system in place (and ideally also DesignOps and ResearchOps functions) frees up an Agile team to instead worry about the bigger details. Details such as: Are we building the right features? What should our product be doing in the first place? To put it another way, rather than worrying about how wide the track should be, teams can think about where the track should be going.
A design system is a must have, not a nice to have for Agile teams. However, creating one takes time and effort. What about if a team wants to start without one and then retrospectively put a design system in place. Let’s look at how that usually turns out.
Design system now, or later?
The temptation for many Agile teams is to plough ahead and worry about a design system later. We need to get something out of the door — we can’t afford to waste precious time creating a design system. Fair enough you might think, but once the genie is out of the bottle it’s very hard getting him (or her, do you get female genies?) back in again. Retrospectively implementing a design system is nearly as hard, and as expensive as retrospectively creating a standardised railway network. Components have to be rebuilt, UIs have to be updated and a mountain of design debt has to be addressed. What usually happens is that teams grasp the scale of the task and simply abandon it, or soldier on with a design system held together with sticky tape and designers’ tears.
A team doesn’t need a full-fledged design system from the word go, although if they do have one it will make progress a lot quicker. In the absence of an existing design system, teams should at least have the beginnings of one, along with a framework in place that allows them to easily add to and change their design system in the future.
Creating a design system takes time and effort. But, whose time and whose effort? Who should build and maintain a design system? Who should be its guardian, protecting it from erroneous patterns and components? With Agile teams there tends to be two different models for managing a design system. The centralised model and the federated model.
Centralised or federated design system?
For some reason I always think of Star Wars when I hear of the centralised and federated models for managing design systems. I know, I know, it’s the ‘ Trade Federation ‘ in Star Wars but it’s close enough to set me off humming the iconic theme tune. Da da, da, da, da, da, da, da…
As its name suggests, in the centralised model a design system is owned and managed by a central team. It’s like the Death Star (the massive moon like ship that Luke blows up in Star Wars: A New hope), in so much it serves the wider Empire, and there is a dedicated team keeping it running and protecting it from pesky Alliance fighters firing duplicate UI component photon torpedoes (really stretching the Star Wars analogies here).
The federated model on the other hand is more like the Trade Federation in Star Wars. It’s a distributed collection of people who come together, perhaps as part of a community of practice to build, maintain and manage the design system. Importantly, this is in addition to their project or product work.
The federated model sounds appealing because there isn’t the need for dedicated design system resources. However, like Emperor Palpatine (shown below) revealing himself to really be the evil Darth Sidious (I really hope you’ve watched the Star Wars movies, otherwise these tenuous references will be lost on you) the federated model is not as great as it initially seems. Building and maintaining a design system, not to mention the guidance, training and documentation that should go with it is a full-time job. It’s not one that someone can do whilst also working within an Agile team. Creating a temporary SWAT team to work on a design system can also be disruptive for those Agile teams momentarily losing someone, and all too often momentum is soon lost once the temporary team disbands.
Another problem, as highlighted by Benjamin Messinger, Design System manager at Forge in his excellent article, So you’ve built a design system, now what? is one of priorities. As Benjamin puts it:
The problem is that different teams have different priorities. Given the constraints of budget and release deadlines, the mantra of many agile product teams (for good reason) is that “perfect is the enemy of the good”. While product teams are responsible for delivering production-level code, they are not required to make sure that the components that they build will be robust and useful for others — rather they simply need to work just well enough for them. Compare this to the mandate of a design system team: to provide components and documentation that can be used by other teams, ensure everything adheres to accessibility guidelines, design components that sit comfortably within the rest of the system. The gap in desired outcomes between the components that a dedicated design system team builds and those that a product team builds is often understandably large. In fact, we’ve found that in many cases the amount of work that our design systems team would need to do in order to accept a contribution would be a heavier lift than just building the component from scratch themselves.
The inconvenient truth for the federated model is that there is often very little for Agile teams to gain from contributing to a design system. Therefore, most don’t, or do the absolute bare minimum required.
For all these reasons I’d recommend having a dedicated centralised team for creating and maintaining a design system. This provides clear ownership, allows that team to solely focus their efforts on the design system, ensures a consistent quality and avoids the resourcing headache that the federated model can induce.
Thinking beyond a design system
Finally, I’d advocate thinking beyond just having a design system to: How might we further empower and free up Agile teams? The rise of Agile has also brought about a second wave of new disciplines, such as DesignOps and ResearchOps. Just like design systems, they are becoming critical for ensuring that Agile teams can be effective, and can focus on where the track is going, not how wide it needs to be. As Nick Stamas, Design system lead at WeWork points out:
“A Design system is a tool, but it can’t just be a design tool, it’s not just a tool for designers, it should empower everybody”.
If you like this article then please recommend and share it. You can find lots more articles like this on my blog: UX for the Masses
See also
- So you’ve built a design system, what now? (Benjamin Messinger)
- Stop doing design system projects (Daniël De Wit)
- How building a design system empowers your team to focus on people — not pixels. (Hubspot product)
- Selling a Design System at Your Company (Nick Stamas)
- Building Design Systems for happier teams and better products (Jules Thivent)
- Design Systems Handbook (InVision)
