Forem: Paul Love

Design systems that scale: the case for composability

Paul Love — Thu, 18 Dec 2025 12:27:16 +0000

Many design systems eventually hit the same wall: By growing to accommodate every variation teams need, they become gruelling to maintain.

A designer needs a button with an icon on the right, not the left, for example. Or an engineer needs a modal that can nest inside another modal. And so on.

Soon enough, the system bends under the weight of prop after prop until it becomes harder to use than to work around. We see this pattern repeatedly on large-scale UI systems.

There is a solution: composability — a principle by which design systems continue to work well as they scale.

Composability should be a core principle when building UI, essential both for large systems and smaller systems with big ambition. But it’s poorly understood, and therefore often overlooked.

Here’s how to apply composability as the foundation of a successful, large-scale design system.

Organisation by technology — the problem composability solves

In early web development, the dominant approach was document-first. HTML, CSS and JavaScript were separated into distinct layers, each with its own concerns: structure, style and behaviour respectively. MarkoJS call this separation of concerns by technology.

Many people still passionately believe in separation by technology, but this purity is unhelpful in modern contexts. Not least because both CSS and HTML have gained behavioural capabilities themselves.

At scale, with large teams working on different parts of complex applications, separation by technology struggles. A CSS change to fix one page mysteriously breaks another. A JavaScript tweak cascades through unrelated features.

The separation that should contain the complexity instead disperses it. When systems become overly dependent on each other across these boundaries, it's known as high coupling — the classic anti-pattern that keeps on giving.

The emergence of composability, or organisation by functionality

Ironically, composability predates the web. It emerged as a principle in 1970s computer science and mid-20th century systems theory.¹ It involves building complex systems from smaller, self-contained parts with clear boundaries. It’s separation of concerns by functionality rather than technology.

Composability in this context means defining what a component does, how it relates to other components, and crucially, how it protects itself from unintended interactions. When done properly, parts can be reused, recombined, and updated without unintended side effects rippling through the system.

Modern JavaScript frameworks, particularly React, formalised this approach through component models. Each component keeps its own implementation close by, while staying small enough to be composed from and alongside others.

Why it’s powerful

For large organisations, composability isn't just a nice-to-have. It's the difference between a system that enables teams and one that obstructs them.

Composability reduces the need for cross-team coordination. Teams can work independently within well-defined boundaries, making parallel work possible without treading on each other’s toes.

Instead of negotiating every change, teams can simply get on with their bit. No more @here distraction bombs dropped into Slack.

It also makes updates safer and easier to test. Changes are contained, reducing the blast radius of bugs.

Conversely, when composability is overlooked, teams tend to work around the system. As a result, bad things happen:

Designers detach components from the system and retreat into Figma, widening the gap between design and implementation²
Engineers fork components or rebuild from scratch, fragmenting the codebase
Component APIs accumulate baroque collections of props (showIconLeft, showIconRight, iconLeftSize, iconRightSize, iconLeftColor…)
Styles and behaviours become context-dependent and unpredictable

A composable system prevents these outcomes. Components can be assembled with confidence, and behaviour remains consistent regardless of context.

The composability–configuration continuum

Note: This section contains contrived examples for purely illustrative purposes.

Composability and configuration aren't mutually exclusive. They represent different points on a spectrum, each with distinct trade-offs.

At the configuration end, teams extend functionality through props and toggles. A typical configuration-based button might look like:

<Button variant="primary" size="large" icon="arrow" iconPosition="right" />

It's intuitive and requires minimal learning. But configuration doesn't scale gracefully. Each new requirement adds props. Each prop increases testing and maintenance overhead. Performance degrades. The API becomes harder to reason about.

At the composability end, systems provide smaller, general-purpose building blocks that teams combine. Instead of a Button component with an icon prop, you might have:

<Button>
  <ButtonText>Continue</ButtonText>
  <ButtonIcon><Arrow /></ButtonIcon>
</Button>

The trade-off is that it requires more discipline up front. Teams must understand how components fit together.

But it scales better: new requirements are handled through new combinations of existing parts rather than adding new props. The component stays simple and the API stays stable.

Most systems land somewhere between these extremes. But composability serves as a useful north star. A well-designed composable system makes the right thing easy and the wrong thing difficult — not through restriction, but through sensible defaults and clear APIs.

Designing composable systems

Designing for composability demands intention.

Key principles include:

Co-locate structure, style and logic: Everything related to a component should live together.

Support internal composition: Design components that accept children, use slot patterns, or provide sub-components that work together.

Create clear, documented prop APIs: Every prop should have clear purpose, naming and type constraints. Avoid generic escape hatches like className or style props that allow arbitrary overrides.

Use explicit prop types and validation: TypeScript interfaces or PropTypes that make correct usage obvious and incorrect usage difficult.

Choose sensible defaults: Defaults that encourage correct usage without requiring configuration.

Composability is less about building a perfect system and more about designing for change. It allows systems to evolve safely. Versioning makes it possible to release early, gather data from real-world use, and iteratively improve.

Learning from existing systems

Existing design systems can provide useful reference points. It’s often said that teams need to build a bad design system before they can build a good one. Reviewing what’s already out there can accelerate that learning process.

There are many well-documented public design systems available. Building small features with them is a good way to see how composable patterns behave, and how boundaries are defined and respected in actual use.

Radix UI provides unstyled, accessible components built on composition. Material UI, Ant Design and Carbon similarly show different approaches to balancing composition and configuration. Primer demonstrates how composability works in a large, multi-platform system.

Adopting composability

It’s possible to shift from a configuration-heavy system to a more composable one, but it’s rarely straightforward. You can't simply deprecate the old and ship the new.

You often end up with two systems living side by side: one designed for configuration, the other for composition. This creates confusion and duplication. You carry the baggage of the old system for a long time — maybe forever.

In cases where existing systems must remain in place — what we call heritage systems — pragmatic workarounds may be necessary. But where new systems can be introduced, composability should be the starting point.

Strategies that help:

Version new components separately: Make it clear which components represent the new approach, reducing confusion about which to use.

Document thoroughly: Don't assume teams will figure things out. Provide concrete examples of translating old patterns to new ones.

Accept coexistence of systems: Fighting the reality burns goodwill and slows adoption.

Start small

If composability is new territory for your team, don’t rush into a big commitment.

Here are things you can do in the early stages:

Audit a problematic component: This might be a button, card, or modal with dozens of props. Map which props are actually used, which conflict, and which are workarounds. This reveals where configuration has failed.

Sketch a composable alternative: How would you rebuild it using composition? You don't need to implement it. Just design the API. What becomes simpler? What becomes harder?

Build a pilot component: Choose something new rather than a replacement for existing work. A feature that needs a component the system doesn't provide yet. Build it composably from the start.

Review an established system: Pick an established public design system. Build a small feature with it. Notice what feels natural, what feels awkward, how the pieces fit together.

Share your learning: Document what you've learned. Show examples. Build shared understanding before attempting larger changes.

Worth the effort

Composability is not a new idea. It’s a practical principle that supports maintainability, development speed, and consistency — particularly in complex environments.

It requires clarity of intent, thoughtful design, and a willingness to change how teams work. But the investment is worth it to build more resilient systems that you can iterate faster, and which your teams can trust without working around.

Inessential reading rabbit hole: Ludwig von Bertalanffy’s General system theory: foundations, development, applications (1968), David Parnas’s On the criteria to be used in decomposing systems into modules (1972), John Backus’s Function level programs as mathematical objects (1981). ↩
In Don’t Detach: Why Figma Component Health Matters, Salesforce’s Lightning Design System team identifies detaching as a critical threat to design system health. ↩

UI components as Lego: an analogy too far, or not far enough?

Paul Love — Tue, 09 Dec 2025 14:32:17 +0000

UI components as Lego: an analogy too far, or not far enough?

The UI Lego analogy is always good for an eye-roll. Components are bricks. Product teams build things with them. An apple a day. Red sky at night.

But if it wasn’t valid, it wouldn’t have persisted long enough to grow stale.

Is it still useful? We say it is — if you extend it, that is. Because having a nice set of bricks is no longer enough.

An incomplete picture

Here’s a common model for building complex things on the web:

A central UI team builds the components
Product teams assemble experiences from them

This scenario can reduce the design system to a fixed library of components.

Product teams choose from the box of pieces and fit them together. But it only includes pieces for the product needs you can see this side of the horizon.

A Lego set is perfect for building one thing. But when you’re finished, someone’s going to want to turn it into something better. There comes a time when the product team will need something that doesn’t exist yet. What then?

Beyond the manual

A good design system doesn’t only provide components. It enables teams to create new ones.

This raises an obvious tension: if product teams can build their own things, how do you maintain quality and consistency? Who maintains it? Who prevents chaos?

There's no one answer, but there is a continuum of options. At one end, you have complete lockdown: the UI team controls everything, making outside contributions difficult, if not impossible.

At the other, you have federation: anyone can add anything in the name of community ownership — which tends to mean no ownership. Quality becomes inconsistent and the system fragments.¹)

We find that successful systems start out with strict controls. Clear standards facilitate the rapid progress you need to show early on.

But to grow well, they need to gradually open up as they mature. That doesn’t mean phasing out control. It means putting governance systems in place. Create documented processes and controls for ownership, contribution and deprecation.

Maintaining over-rigid control indefinitely creates problems. Product teams build what they need anyway, outside the system. Shadow components proliferate. The design system becomes gradually less useful in enabling the work being done.

When you add means of both enablement and governance to your collection of components, you elevate it to a full-fledged design system. That is, it becomes a system of systems.²

In the shadows

Shadow components aren’t to be feared. They’re useful signals, not least that you have a motivated team that wants to get things done.

But they also signal that the system isn’t meeting all needs. That could be because the contribution process is hard to understand, onerous to follow, or both.

Ask what problem they were trying to solve and why the existing system didn’t work for them. The answer will reveal gaps to fill.

Making it work

Your design tokens, icons, and foundational elements need to be available in every format the teams use, be that CSS custom properties, JSON, JavaScript, or any other.

Documentation should cover both how to use and build components, structured around different user needs.³

Everything should live in one place rather than scattered across repos, wikis and Slack channels.

The payoffs are substantial:

Teams stop wasting time rebuilding primitives.
Consistency becomes the default rather than an aspiration.
Brand identity holds together.
Development speed increases because new problems are only new once — when they arise again, you’ve already solved them.

Building on the Lego analogy

These benefits only materialise when you move beyond the component catalogue model.

The Lego analogy holds – but only if your teams can tool up and make new bricks. The goal isn’t to provide every possible component. It's to provide foundational components plus the means to create more.

In other words, you’ve built a beautiful Lego factory. Now it’s time to hand out the golden tickets.

See Nathan Curtis’s The fallacy of federated design systems, on the “damage and distress of glorifying the wrong model”. ↩
Brad Frost's The design system ecosystem breaks down how design systems are ecosystems of interconnected parts all working together. The component library is just one piece. ↩
The Diataxis framework structures documentation around four distinct user needs: tutorials, how-to guides, explanations of concepts, and reference material. It’s a great starting point for planning documentation. ↩

Start with a slice: 7 steps to get your new design system moving

Paul Love — Tue, 14 Oct 2025 11:46:17 +0000

Getting a design system off the ground is hard. Teams often start too broadly. Without a concrete goal, it's easy to get stuck weighing up the options.

In this post we share how to take a more focused approach by choosing a narrow slice to build to show value quickly.

1. Start with a visible, bounded slice

Choose one or two target pages to begin with. These pages should be highly visible but clearly bounded. You want a manageable scope, but also show an immediate impact.

A focused slice helps reveal the right problems early and demonstrates progress everyone can see.

The homepage is often a strong choice. It’s rarely representative on its own, but it's often politically non-negotiable. People will inevitably ask, “… but what about the homepage?” Including it is a pragmatic way to avoid hassle.

Pairing it with a second, more typical page helps make sure you're solving recurring problems. This could be a product listing or dashboard, for example.

Avoid pages that make heavy use of overlays or modals. That’s too much complexity, too early.

2. Build a shadow world with Storybook

Create a shadow world. Recreate your product in a low-stakes space your team owns. It’s not live. It’s not connected to real data. It doesn’t need to be perfect. It’s a place to explore and demonstrate what your design system can do.

Set up a Storybook environment to develop and present components without delivery pressure. This removes risk by letting you experiment, validate decisions and get buy-in before touching production code.

Storybook lets you test components in isolation, explore states and variants, and prototype static pages. This creates a shared frame of reference and enables fast iteration.

3. Categorise your components deliberately

Next, analyse your target page. Divide what you see into three categories:

Potential design system components: Reusable patterns like buttons, cards or form fields.

Site furniture: Recurring structural elements like headers, footers, and navigation.

Custom components: Unique, often complex, items.

Design tokens tie all three together with consistent styling. This resists the trap of becoming the department responsible for all the things rather than a team that enables others.

4. Decide what to tackle and what to park

Be strict about scope. Account for layout mechanics and logic underpinning visible components. Keep a list of future needs, but resist tackling them now. (This makes a great starting point for an opportunity roadmap.)

Look out for what we call icebergy componenets: seemingly simple elements that hide complexity. For example, a bell icon might open a complex messaging panel. A text input requires validation states, complex accessibility features, and error handling.

Start with the simplest version that works. You can always add complexity later, but you can't ship if you try to solve every edge case upfront.

5. List components, then order your steps

List the components needed for your target page. Group them by type. Start with something basic like a button. Jot down what it needs to get it working.

This simple exercise reveals more than you'd expect. Particularly if you're new to design systems, or if your role isn’t hands on. it surfaces foundational work that wasn't on your radar. You'll discover you need to:

Define and create a starter set of design tokens
Set up tooling: code repositories, Storybook deployments, tests
Figure out versioning and publishing
Write basic getting started docs
Factor in cross-cutting concerns like accessibility, security, and internationalisation

One by one, move to the next component, noting only new tasks. The net-new work shrinks rapidly as foundational elements fall into place.

This approach reveals everything you need for an alpha release and exposes hidden complexity early so you can plan for it rather than scramble.

6. Create the right conditions

This approach demands a collaborative, cross-functional team. It helps to have T-shaped people: developers who care about design and designers with technical empathy.

You need a shared mindset embracing modern product development. Without it, teams fall back into old patterns. Design becomes a one-off handover rather than a collaboration, and the whole approach fails.

Set expecations: progress and learning in tandem are key.

Clarity, momentum, and progress

A narrow, visible slice gives your team a shared focus and a tangible goal. It helps you solve the right problems early, without overthinking.

The trick isn't having all the answers upfront. It's building something real that teaches you what questions to ask next. Get your slice working, and momentum takes care of the rest.

Continuums as a tool for understanding

Paul Love — Tue, 07 Oct 2025 15:37:51 +0000

People are natural problem-solvers. We like to fix things. So when we’re faced with a complex problem, it’s not surprising that we want to solve it. Usually in the fastest and best way possible.

But there’s risk in trying to fix the whole problem at once. For one, it can make it very difficult to know where to start, which often leads to a form of paralysis. People naturally bounce on to more readily-solvable problems instead.

Almost always, it helps to step back to visualise the range of possibilities. This is where the idea of a continuum can be a powerful tool in understanding. It helps move from reflexive solutionising to a more considered approach.

DIY as a spectrum

As an example, think of renovating a room at home.

At one end of the spectrum, you could handle every aspect of the project yourself. It’s the most time-consuming option, but it will save a lot of money. It's also difficult, and might lead to a less good outcome. (No offence.)

At the other end, you could pay to outsource the whole project to relevant trades. Expensive, but it does give you time back, and should lead to the best results.

But, assuming you have some time and money, you might look at a sensible middle ground. You could get a professional in to handle the tricky job of plastering the walls, but take on the painting yourself.

The mental model of the continuum helps to map out the interesting options between the extremes. In our experience, the ends of the spectrum rarely lead to a pot of gold.

Multi-brand design systems as a continuum

In our world, multi-brand design systems are a great example of the usefulness of the continuum. When an organisation has more than one brand, what’s the best way to approach a new or evolving design system? Should you have one system or many?

Note: We’re talking about brands here, but the same goes for multiple products or product groups. (Contextual re-nouning is encouraged.)

Instead of approaching this as a binary choice, you can plot a range of different approaches on an axis.

At one end you have simple theming. This means one design system to rule them all, switching out logos and colour schemes for each brand. It’s a fast and efficient approach, but the trade-off is limited brand differentiation.

At the other end, the organisation has multiple siloed design systems. Nothing is shared between them, be that code bases, components or anything else. Each brand has total independence, but at the expense of efficiency.

Somewhere in the middle is a multi-brand approach built on one system. You have the benefits of shared architecture and flexibility in brand differentiation. The benefits and trade-offs are more balanced.

Figuring out the best approach means arriving at how far along the continuum you want to land. How much flexibility do you need? How much time and effort do you want to commit to? Pinning the options to a continuum (real or imaginary) helps everyone understand the trade-offs.

Why continuums work

Thinking about this continuum isn’t an abstract exercise. It’s a practical method with real benefits:

It prevents hasty decisions: It encourages teams to pause and consider a number of alternatives beyond those that first spring to mind.

It helps you see the possibilities: It simplifies complex problems by providing an objective framework for comparison.

It fosters a considered consensus: The continuum makes it clear that there's no single correct answer. Each option has its pros and cons, and the best choice depends on the specific circumstances. This opens up a more nuanced conversation about trade-offs and helps everyone buy into a way forward.

It’s all about trade-offs

We often say that all decisions are trade offs. In fact, we probably should have written that post first. Continuums are a tool for understanding and talking about those trade offs.

It’s much easier than thinking about stand-alone alternatives. Plus you get to make funny hand gestures when you explain things. 🫲 🫱

In praise of opportunity roadmaps

Paul Love — Thu, 12 Jun 2025 14:14:12 +0000

Product roadmaps are a fact of life. They’re a good way to set strategy, and communicate progress.

But without care, they can become an albatross, burdening teams under the weight of hard deadlines and sprawling interdependencies.

But they don’t need to be. Sometimes you just need to know:

What’s happening now
What you think will happen next
What you’ve done
What you might do later

We recommend opportunity roadmaps to stay lean and adaptable. Here’s why we like them, and how we use them.

What a roadmap is, and why you need one

First, the basics. A product roadmap is a visual, strategic document that shows work that is happening now, and which might happen in future.

A good roadmap does two things. It helps the team prioritise what to do next. And it acts as a tool for transparent communication: it helps teams and stakeholders understand the status of the project, and its direction of travel.

There are many kinds of roadmap, which fall on a spectrum from lightweight to heavy-duty. At the latter end are the traditional roadmaps. These typically set out a linear plan, far into the future, mapping timelines and dependencies. They may also include KPIs.

At the other end, the case is sometimes made that you don’t need a roadmap at all. The rationale tends to be that good ideas always come back round, and next priority will always be clear.

Having no roadmap might work for single-product startups, it’s unlikely to fly in most organisations — with good reason. It’s perfectly reasonable that stakeholders in larger organisations keep tabs on what’s happening now and next — especially those ultimately responsible for the success of the project, who need to report on progress to higher-ups.

Much like our thinking behind why we use Kanban, not Scrum, we advocate for lightweight roadmaps. They maintain flexibility, which avoids locking the team into the wrong priorities. But they still communicate the strategy, reassuring everyone that the team isn’t flying blind.

The opportunity roadmap

We use something more adaptive — an opportunity roadmap. It sits somewhere between the just-in-time delivery of Kanban and the visibility of Scrum and waterfall roadmaps.

This kind of roadmap doesn’t make hard commitments. It doesn’t claim to know everything up front. It’s there to show:

What we’re working on now
What we could start work on next
Everything we could attempt given sufficient time and resources

It’s designed to evolve, not predict. We review it every couple of weeks. We might:

Reorder the upcoming milestones based on new information or changes to team capacity
Start working towards new milestones — if they still look like the right opportunities

Avoid artificial certainty

A common pitfall in roadmapping happens when your roadmap instils a false sense of certainty rather than acting as a guide to strategic direction.

Emil Kabisch’s Escaping the roadmap trap explains this well. Traditional roadmaps are often confused with project plans. They prioritise deliverables over discovery, create pressure to maintain arbitrary timelines, and encourage teams to treat strategic planning as a one-off activity. As a result, traditional roadmaps can be quite scary. Teams can feel set up to fail.

They’re also prone to being misread. A linear roadmap suggests the path is fixed — that all the research and learning is already done. Reality is never that neat. Product discovery is continuous. Priorities shift. Plans change. And these are good things — they keep your project on course. An opportunity roadmap allows for this.

Prioritise and communicate

Per Kabisch, our approach is a blend of opportunity tree and Kanban roadmap.

Like the opportunity tree, it encourages teams to regularly pause, reflect and choose the best next move rather than blindly following a fixed plan. Like Kanban, it separates the strategic priority we’re actively working (Now) from those we’re reasonably confident about (Next) and those we have tentatively in mind (Later).

That separation matters. It avoids the common trap of compiling an organisational wish list and calling it a strategy. If something’s in the Later column, it needs a plausible chance of being picked up in future. It’s not a holding pen for all the things.

Opportunity roadmaps don’t guarantee perfect prioritisation. But they make the conversation clearer and more honest for teams and stakeholders alike.

They work particularly well as part of our engagement check-ins. Kanban is optimised for delivery, but it can make it trickier for stakeholders to keep tabs on where things are heading. A shared roadmap closes this gap. It gives everyone a touchpoint to discuss priorities, risks and potential shifts in direction.

In summary, then

The opportunity roadmap doesn’t try to do everything. But it does give you a clear, adaptable way to ask the right questions — and a platform to work through them to identify the best next move.

They’re an example of the lightweight, flexible systems and processes that, in our experience, make it easier to get things done, done well, and almost entirely albatross-free.

The value of the client engagement check-in

Paul Love — Tue, 03 Jun 2025 14:28:18 +0000

It sounds obvious to say that consultancies and clients should maintain good communication, but regular check-ins are often overlooked. It’s all too easy to focus on deadlines and deliverables, and assume everything’s fine unless a problem becomes obvious. But without regular check-ins, small issues can escalate, and momentum can stall.

We call these engagement check-ins, and we see them as critical infrastructure. They help clients stay informed, help consultancies stay unblocked, and help both sides spot and solve problems early. They’re a simple but powerful tool for keeping projects on track and relationships strong.

Here’s why we see them as crucial, and how we approach them.

Note: We’re framing this around clients and consultancies, but this probably follows for any teams that work with external stakeholders. Feel free to substitute your preferred collective nouns.

What engagement check-ins are for

Engagement check-ins aren’t about reviewing work-in-progress or managing delivery. They’re about maintaining the relationship between the people responsible for the engagement.

We recently wrote about why we prefer Kanban’s flexibility over Scrum’s ritualism. The benefits are many, but it does create the need to keep clients informed. Regular check-ins close that circle. They build client confidence when things are on track, and reassurance that issues will be addressed when they’re not.

For clients, they offer a structured way to:

Stay informed about what’s happening
Flag changing priorities or emerging needs
Raise concerns early

For consultancies, they’re a chance to:

Understand the corporate weather, i.e. shifts inside the client organisation that might affect the work
Raise issues that can’t be solved through delivery alone, like strategic changes or sponsorship gaps
Build trust by showing they want honest feedback

Generally, check-ins create space for everyone to be human. This is so easy to overlook, but it’s absolutely crucial: engagements aren’t just contracts — they’re collaborations between real people, navigating real-world complexity and with their own unique priorities and contexts.

Those priorities rarely compete, but if they’re not understood and synchronised, problems can arise.

Who should attend

Keep check-ins as small as possible but no smaller. Start and end with who’s essential.

You want people who have oversight, context, and the authority to act. Too large a group makes conversations unwieldy. Too small risks missing critical perspectives.

You don’t need procurement or the whole delivery team. It’s about the leads on both sides who are directly responsible for success.

One or two people from each side is about right.

How long and how often

We recommend holding check-ins for one hour every two weeks.

That’s often enough to catch issues early without overwhelming schedules.

But adjust if needed. Move to weekly during fast-moving phases, or monthly if things are stable, or during holiday periods.

What you should cover

Always have an agenda — even if it’s light.

We suggest these core topics:

Current project status: A high-level alignment check — no need to go into delivery details
Corporate weather: Organisational changes that could impact the work
Process issues: Billing, timesheets, invoicing and other logistics
Concerns: Make a safe space for unstructured conversation where people feel they can speak freely

You don’t have to cover everything in depth every time, but a standing structure makes sure nothing important gets missed.

Time well spent

Regular check-ins aren’t overhead — they’re how good working relationships stay good. Talking regularly keeps people aligned, problems small and solvable, and projects moving.

The power of saying it three times

Paul Love — Fri, 04 Apr 2025 12:47:55 +0000

When it comes to making things memorable, the number three has a flawless track record. For example:

Veni, vidi, vici
Government of the people, by the people, for the people
Turn on, tune in, drop out¹

Beyond rhetoric, we’ve found that when communicating a complex idea, it helps to say it three times. That is, it generally takes three distinct explanations for a tricky idea to take hold.

Occasionally, people get it first time. If that happens, great, but avoid making this your benchmark. That will only lead to disappointment. More often, they won’t. In that case, be patient. Remember that other people won’t have all the context that you do, and have their own priorities jostling for headspace.

Don’t worry about whether people got it — that will become clear. It might be through a small piece of work, a comment in a meeting, or even a quizzical look. These are all useful datapoints that let you know you’ll need to say it three times.

When these moments happen, there’s no need to react immediately. Instead, make a plan to say it again in the way that’s most likely to land. Put it another way, or in another format. If you can, show the idea working.

But however you put it, make sure it’s clear, concise and, if possible, memorable. Do that, and they’ll get there eventually. And you’ll be able to tell when it lands in all the same ways you could tell that it didn’t.

So we often say to each other: say it three times. It’s as much a reminder to be patient and intentional as it is a guide to making ideas stick.

As attributed to Julius Caesar, Abraham Lincoln, and Timothy Leary. Caesar wrote it in a letter. Lincoln and Leary said it out loud. History does not record if they later emailed attendees their PowerPoint decks. ↩

Why we use Kanban — not Scrum

Paul Love — Wed, 26 Mar 2025 12:37:36 +0000

To produce only what is needed, when it is needed, and in the amount needed.

— Taiichi Ōno, Toyota Motor Company

We use Agile development because it’s proven to be the best way to build good things quickly. But there are many flavours of agile. Two popular methodologies are the much-debated Scrum and Kanban.

If an opinion is worth having, it’s worth putting on the internet, so here are the reasons we favour Kanban. This is not a definitive critique — it’s why it works better for us.

Some would say they’re apples and oranges. But whether they’re tools, frameworks or whatever else, Scrum and Kanban are two ways digital teams get things done. So, we think they’re ripe for comparison.

These are good recaps on Scrum and Kanban if you need them:

When Scrum makes sense

Scrum is an understandable choice when your organisation values rigidity in certain ways of working, such as:

Aligning team members from different disciplines and experience levels around a unit of work
Demonstrating whole-product improvements at very frequent intervals
Enabling routine forecasting and reporting in a work environment that demands them

The reality of work culture means that some rigidity is almost always needed. When one or more of these elements exist, Scrum — or elements of it – make sense to use.

But beyond that requirement, we advocate for working with as much flexibility as possible.

Why Scrum’s rigidity limits productivity

Scrum is optimised for interdisciplinary teams of mixed experience. It’s a way to get the team pointing in roughly the right direction, then make incremental progress.

The corollary is that it isn’t optimised for the productivity of individuals, and therefore the team as a whole. (We think about productivity in terms of greasing wheels, not cracking whips.)

Scrum assumes that everyone on the team is a generalist — that everyone can contribute significantly to the next sprint’s block of work. But that isn’t always the case.

The work demanded during a sprint can lean on some skills more than others. When deadlines loom, it’s often the most experienced people that crunch to meet goals.

Scrum’s rituals, like sprint planning, daily stand-ups, and retrospectives are intended to keep teams aligned and moving forward. But that rigidity brings inefficiency. When they’re too frequent, rituals can feel like time spent talking about work rather than doing it. So although we’re firm advocates of product demonstrations, we do them as and when there’s something of real value to show.

When your team is made up of specialists, you don’t need a planning meeting every sprint, or a stand-up every day, for people to know what to do. It’s enough to have open lines of communication and meetings when you actually need them.

Why Kanban works for us

Unlike Scrum, Kanban is a continuous flow system. It’s inherently flexible, making it a better fit for teams that value adaptability and focus.

It has its roots in lean manufacturing. It’s one of the 12 pillars of the Toyota Production System, designed to optimise workflow, reduce waste, and improve efficiency by visualising work and limiting work in progress.

The result of its introduction at Toyota was to transform a loss-making company into a leading global brand.¹ When a methodology is proven in the trial by fire of real-world mass-production, it’s probably worth a try.

Here’s how Kanban aligns with our approach to collaboration and project delivery.

Building teams around specialisms

Our approach is to build the team around the specialisms the project needs. This allows everyone to use their full skill set and improves quality of work. In our experience, it also enhances work satisfaction.

If a new specialist need arises on a project, we can map it to the right person. If that person doesn’t exist, we can bring a person in without disrupting everyone else.

Limiting work in progress

One of Kanban’s core principles is limiting work in progress (WIP). This prevents overloading the team with more concurrent work than it can reasonably do.

Too much WIP impairs the team’s output in the short term, and burns people out in the long term.

We use Kanban to cap WIP, making sure that everyone can focus on completing tasks before starting new ones. This leads to higher-quality work and fewer bottlenecks.

Putting flexibility first

Kanban doesn’t require rituals, but it doesn’t exclude them either. We still hold stand-ups and board walks to keep everyone aligned, but these happen when we need them rather than being dictated by a framework.

For example, our board walks are an opportunity to discuss blockers, celebrate progress, and reprioritise tasks as needed — and without the pressure of a sprint deadline.

Greater flexibility suits us in a number of ways:

Unbounded discovery work: When we’re exploring new ideas or solving complex problems, Kanban’s flexibility allows us to adapt as we learn.

Motivated teams: Our team is made up of experienced specialists who don’t need micromanagement. Kanban gives them the autonomy to manage their work effectively, helping them stay motivated and productive.

High trust: We cultivate a high-trust environment where the focus is on doing work rather than reporting on it. Kanban supports this by emphasising flow over formality.

Reprioritising: Scrum’s fixed sprints can be too rigid for projects that require us to provide a service or other kinds of support to a client over a period of time. Kanban makes it easier to quickly adapt to changing client priorities.

Results before rituals

We prefer to spend less time on process and more time on being productive. Kanban provides a lightweight, flexible framework that adapts to our needs rather than forcing us into a one-size-fits-all model. We can supplement it with elements of Scrum or, more likely, another framework² when it helps us — we think of Scrum as a toolkit and Kanban as a way.

If you’re considering your own approach to Agile, we recommend not defaulting to a framework without consideration. Think about what your team needs, what your workflow looks like, and how you can create a process that supports your goals.

By all means experiment, but be wary of clipping your team’s wings by enforcing a suboptimal way of working. Frameworks should bend to team needs rather than vice versa. That’s why Kanban is the right choice for us.

This history of Kanban explores its creation and implementation at Toyota in pleasing detail. ↩
When we need more structure, we tend to use Shape Up rather than Scrum. It follows a cycle of six weeks of building followed by a two-week cooldown to reflect, learn, and plan what’s next. We find this is a sweet spot between exhausting two-week sprints and inflexible quarterly plans, but we’ll talk more about this in a future article. ↩

12 tips to make project handovers a success

Paul Love — Tue, 05 Nov 2024 11:15:21 +0000

When you work on a large web project, there will come a time to hand it over to another team. This could be a handover from an outside agency to an internal team, or from one internal team to another.

Handovers are always tricky. They’re as much about people and culture as they are processes and technology.

Here’s what we’ve learned over the years, distilled into 12 tips. Whether you’re a client organisation or a supplier, hopefully you can benefit from our experience.

1. Assume zero context

Handovers involve two teams:

The incoming team picking things up
The outgoing team putting things down

The outgoing team might have made the thing. The new team might be coming in to maintain it. Those are very different contexts.

Whatever the circumstances, it’s possible the incoming team has zero context. They might not know the goals of the project, or even what they’ve been brought in to do. The team might be comprised wholly of new hires.

If people are moved from elsewhere in the organisation, it’s probably a gentler on-ramp. But whatever the circumstances, skew cautious. Don’t make assumptions about what the incoming team already knows.

2. Make a plan

Making a handover plan is essential. It should be an actual document. It doesn’t need to be long.

Handovers are mostly about people, so the plan should be people-oriented, with input from everyone.

A list is a good place to start. Lists help you:

Align as a team
Assign and prioritise activities
Adapt to different project structures like now, next, later¹
Report progress

Include all possible duties, especially when it’s not clear how to do them.

Talk through the list with everyone. You’ll land on things you’ve missed, and things you thought were clear but aren’t. Expand on these.

Over time, you can flesh the plan out with useful, more detailed information.

To start with, the plan will be mainly written by the outgoing team for the needs of the incoming team. Gradually, the incoming team will have more input.

3. Start with fundamentals

The plan should contain whatever the incoming team needs to continue the project autonomously before the outgoing team pack their boxes.

Helpful things to include are:

Aims of the project
A who’s who of stakeholders
Where things are (e.g. project documents)
Working processes (this saves lots of time)
Project history and context
Project architecture
Unusual and unintuitive aspects
Unresolved points of friction

Remember that it’s a working document, not carved in stone. Add generously, then edit ruthlessly. Keep only useful things.

4. Work in phases

Identify which list items you can start handing over straight away.

Use paired working to gradually hand over trickier duties. Let the incoming team member take responsibility as soon as they can, but take as long as is needed.

Not everything will go smoothly. Reassure the incoming team that points of friction are a chance to make the plan better.

5. Test, then iterate

The plan should evolve alongside the handover process.

As the incoming team ramps up, have them use the plan to find its gaps and weaknesses. Figure out who’s best placed to address them. Over time, it’s less likely this will be someone in the outgoing team.

The plan could pan out in these stages:

Drafted by the outgoing team
Iterated by the outgoing team based on feedback and observations
Iterated by the incoming team based on their learnings and needs

But there are no handover police. Do what works.

6. Don’t prescribe

A handover plan shouldn’t tell the incoming team how to run the project. It should help them reach the point where they can run it themselves.

It shouldn’t be:

A knowledge repo
A disciplinary guide
A product roadmap or backlog²
A list of problems to fix
The home of project documentation

Report what you’ve been doing to the incoming team, and how you’ve done it. The incoming team should have freedom to do things differently.

Avoid directly mapping outgoing people to incoming people. It’s a form of telling the incoming team how to work, and skills don’t align this way. Hand over at team level.

7. Acknowledge feelings

Letting go of something you’ve built is like sending a child to a new school. Anyone who cares about the work will have feelings about it.

Sometimes the incoming team will have strong opinions, and that can be challenging. Remember, they don’t have the organisational context for the decisions you’ve made.

Encourage frank discussion about why things were done the way they were. They may uncover organisational challenges that should be documented.

But be prepared to let things go. You can’t make people understand past decisions. An opinionated team is better than an incoming team that just wants to be told what to do.

It can be hard for the outgoing team members to not know how the story ends. Suggest ways to catch up in future, even if it’s just going for a coffee. This helps with closure and personal development.

Ultimately, it’s essential to let go. If by the last day and the outgoing team are holding on to things: problems.

8. Manage time

Don’t preempt a handover before it’s real. You’ll waste time on things that will change in future.

Start planning as soon as you know a handover’s coming. A few months is usual, although it depends on the project’s scale and complexity, as well as the number of people involved.

You’re handing over culture and relationships as well as systems and processes. Those aspects take time.

If you weren’t given enough notice, share feedback to sow seeds for a rosier future.

9. Tidy up

A handover is a great excuse to tidy up the project. Leave the incoming team with forward momentum. If they have to unpick knotty problems from day 1, the project will grind to a halt.

We like to think of it as parking the project nicely so someone else can get in and drive off.

Resolve as many problems and fix as many broken things as you can before final handover. Prioritise issues that require contextual knowledge.

10. Keep a friction log

You won’t be able to fix everything, and not everything should be done by the outgoing team.

Note outstanding issues in a friction log. This could be a section of your handover plan.

For example, you might discover a process that was hindering progress. It’ll be down to the incoming team to find a better way.

Any decisions that that will have a long-term effect should be left to the incoming team.³

11. Treat the handover as core work

Don’t think that two teams means double capacity. There’s plenty to do to keep the project on track while also handing over.

Project work and business-as-usual activities should continue. This prevents the handover plan being theory rather than practice. It shows how things work.

Don’t worry about keeping the outgoing team busy. If, by the end, they have nothing to do, things have gone well. If they’re grafting on their last day, you’ll be lost when they go.

Above all, don’t create urgency. It’s not the time to kick off a large or complex piece of work.

12. Make friends

The outgoing team should make friends with the incoming team. The incoming team should make friends with everyone.

If possible, get together in person at the beginning of the process. Be honest about the challenges the project and organisation has gone through.

Be engaged but not obsessive. Doom and gloom isn’t the vibe — keep it positive.

Three things to remember

Handovers are about people more than technology or logistics. So:

Make a plan around the needs of the people involved
Include people’s feelings in your thinking
Carve out time for the actual handover work

Prioritise these, and you stand every chance of a successful handover.

See Escaping the roadmap trap by Emil Kabisch for creating roadmaps which differentiate now, next and later. ↩
Although the plan shouldn’t be a roadmap, it should be easy for the incoming team to derive one from your list of duties.) ↩
The friction log is another source the incoming team can use to create a roadmap. ↩

Why design systems fail

Paul Love — Tue, 08 Oct 2024 15:02:12 +0000

Design systems fail for many reasons. Total disaster is rare. It’s more common that a project takes too long, or doesn’t serve the teams it’s meant to help.

Here are 11 reasons we’ve encountered:

Scaling problems
Bias for the boardroom
Lack of consensus
Unclear ownership
Gaps in the technology stack
Inflexibility
Multi-brand complexity
Short reach
Pre-digital legacy
No organising principle
Unrealistic ambition

Let’s take them one at a time, along with how we mitigate them.

1. Scaling problems

Small organisations have different ways of working to larger ones. If they don’t adapt as you grow, problems can arise.

If three teams use your design system, it’s easy to get feedback about a change. You can go and talk to them. If you have 30 teams, you need processes to make that work.

As you grow, watch for communication breakdowns and address them quickly.

2. Bias for the boardroom

External agencies sometimes build design systems for organisations, not with them.

The person making that buying decision usually isn’t responsible for the project’s success. The work might impress leadership, but not work for the teams saddled with it.

Instead, embed the agency into your organisation for as long as needed to understand teams’ needs and deliver the design system.

3. Lack of consensus

Design system means different things to different people. It could encompass the brand, design elements and technology components. Or it might only cover typefaces and colours.

There’s no right definition, but different perceptions create risk. Agree on what problems to solve, and set the scope and goals to solve them.¹

4. Governance challenges

Design systems often germinate in one team. That’s fine for a start, but if ownership stays there, it will only ever solve one team’s problems.

To succeed, the system must evolve from a team project to a shared infrastructure. The founding team shouldn’t dictate every detail, but they shouldn’t become a service desk either.

Instead, facilitate collaboration. Give all teams the means to contribute. They’ll be more invested in the system’s success if they help build it.

Support collaboration with:

Version control
Pull requests
Documentation
Automated testing
Access control

5. Gaps in the technology stack

It’s hard to make the design system work with all the technology used in the organisation. You may not have aligned around a technology stack, or decided not to. Maybe shadow IT is hiding in team workflows.

The design system doesn’t have to integrate with everything, but if it’s disconnected from essential parts, it won’t flourish.

Identify and agree necessary touchpoints to make sure all teams’ needs are met.

6. Inflexibility

Design systems fail when they don’t allow for change. Rebrands², acquisitions and new needs arise. You can’t plan for every change, but an adaptable system prevents headaches.

If your organisation needs a design system, it’s likely to have different project teams working at different speeds. It’s not realistic for everyone to adopt the latest version of the design system on release.

If you don’t use a monorepo, use robust versioning. This helps teams make the best decisions for their project. We recommend Semantic Versioning to flag the implications of an update for different teams. It flags mission-critical updates that affect existing implementations.

7. Multi-brand complexity

Managing several brands with one design system is complicated. You could be dealing with variations in theming or distinct identities. The design system must support each sub-brand’s uniqueness, and its cohesion with its siblings to the extent needed.

Identify where your needs fall on this spectrum. It gives you a reference point for decisions about what the design system should do — and how.

8. Short reach

Design systems aren’t only for the web. To make your UI consistent, identify everywhere users interact with your brand. Then decide what your design system should include.

Consider:

Web (desktop and mobile)
Native apps (desktop and mobile)
Emails
Social media
Support documentation
Digital advertising
Print, physical media and merchandise

You don’t have to include everything at once. Web and mobile are a good place to start.

9. Pre-digital legacy

Your starting point could be a brand guide developed for print, or other non-digital contexts. You might inherit an inaccessible colour scheme, a typeface that doesn’t support internationalisation, or a logo that doesn’t work in digital contexts.

Some organisations overlook digital in their foundational strategy. This makes life hard for digital teams charged with implementing it. There’s also a risk of leaders underestimating the scale of moving to digital.

But it’s also an opportunity to modernise. Make sure your design, technology and other brand-aware teams are in the room from the start.

10. No organising principle

To build a Lego castle, buy a set, not a tub of random bricks. Without an organising principle, your design system could become a collection of things that aren’t used, or used in disparate ways.

The principle could be anything that helps you filter out ideas that won’t help you build what you need. For example:

Composability: will it work consistently in different contexts?
Platform-specificity: e.g. should you build only with React?
Scalability: will it still work in a multi-brand future?

Identify a logical organising principle for the aims of your project.

11. Unrealistic ambition

Design systems fail when you try to do too much too soon.

Don’t try to eat the whole horse. Start with foundational elements like fonts, icons, design tokens, or logos. Then pivot to the processes that get people to use them, talk about them, and share feedback.

It’s tempting to fork old design-system work, but that’s like taking your carpets with you when you move house. It won't achieve the best results.

Remember: anyone that has built a good design system had to build a bad one first.

See Don’t build a design system — build what you actually need. ↩
See Scott’s Law of Rebrands, on the inevitability of rebrands happening, and how to plan for it. ↩

Don’t build a design system — build what you actually need

Paul Love — Mon, 09 Sep 2024 14:49:47 +0000

Saying you need a design system is like saying you need a vehicle. It might take you somewhere, but without a clear destination, you risk ending up lost.

This post looks at why the term design system isn’t that useful, and how to arrive at the outcomes your organisation needs.

Where design systems come from

Design systems evolved from the corporate identity manuals and style guides of the later 20th Century.

The NASA Graphics Standards Manual from 1976 is a notable example, prescribing everything from letterheads to spacecraft insignia in exacting detail.

Later, these guides became digital and began to include pattern and component libraries. In some cases, they merged into a comprehensive library and were given the name design system.

The Salesforce Lightning Design System, released in 2015, helped popularise the term. It’s a comprehensive tool to help teams design and build digital products and services as a whole.

More detailed accounts of the origins of design systems are available¹.

Siloed definitions

Holistic design systems are powerful, but not well-suited to the siloed disciplines we see in big organisations today. (That’s without considering broader systems that cover content strategy, voice and tone guides, internal processes, dishwasher policy…)

To be useful in their day to day work, individual disciplines have carved out their own versions. So design system has come to mean different things:

Brand identity systems. E.g. NASA’s Brand Guidelines.

Component libraries. E.g. The GOV.UK Design System is a well-considered case, but they can be more ad hoc.

Design components and standards. E.g. Volkswagen’s system for VW and sub-brands, discussed in Into Design Systems, presented by Matthias Fritsch and Thorsten Jankowski. It could also be for a product or single brand identity.

Design assets. E.g. Uber’s Base is Figma-heavy (which is usual) and geared towards designer needs. These may be organised to in varying degrees. The distinction is that there’s no accompanying technology implementation.

Fully-integrated design systems. E.g. Salesforce Lightning Design System, Google’s Material Design, IBM’s Carbon and Microsoft’s Fluent. These include guidelines, components and technology.

When a term means different things to different people, it’s risky to use in a general setting. Even the word design can imply ownership by one team. That sometimes makes sense, but it’s controversial as a universal rule.

Designers don’t want to worry about brand or engineering needs, just as engineering teams might overlook the needs of designers². For a design system to succeed, it must meet cross-functional needs.

Build the right thing

Instead of saying you need a design system, identify the problems you want to solve. Here’s how.

1. Set goals

Set clear, outcome-oriented goals that align with your organisation’s objectives and teams’ needs. Make sure everyone buys into them to the extent possible.

Identify non-goals too, like deprioritising internationalisation if you only serve UK users.

Ask questions to agree goals:

What does the business do?
What problem do you want to solve?
What are the user needs, internally and externally?
What results you want to see?
What are the accessibility implications?
What countries do you operate in?
What is your technology stack?
What are the brand implications?

When you set the right goals, it doesn’t matter if you call it a design system. Call it what you like.

2. Define terms

Clearly define what your solution does, and what it includes.

When we helped BT implement Arc, we called it a UI system³. And we defined this as:

… a collection of tools and practices that help teams working on BT Enterprise digital products build high quality web user interfaces at scale.

Adding a definition beyond the term helped everyone understand what Arc was supposed to achieve.

3. Communicate openly

Internal communication is vital. Everyone with a stake needs to know where they can see progress, and ask questions.

Consider week notes and frequent demos. These help communicate changes, from small refinements to what you’re building up to revisiting the main goals.

Having the project history in the open helps new joiners get up to speed. Sharing progress gives everyone the chance to flag issues at the first opportunity.

4. Expect change

Design your system with change in mind. The project should adapt as your understanding develops. This is especially important for projects that cut across many disciplines and teams.

Involve relevant people as early as possible, but understand that waiting for everyone can halt progress. Create processes that incorporate new information and perspectives as they emerge.

We sometimes hear that discovery work and goal-setting slows down work being done. Make it a goal to support the progress of the teams you’re working with. Design iterative processes, and avoid blocking other teams.

The most important thing

Unclear terminology shouldn’t stop you from doing good things. If you set goals, define terms and get the right people in the room, you stand every chance of building what your organisation actually needs.

Brad Frost explores the origins of design systems in the opening of his talk, A Global Design System. Jay Hoffman’s From designing interfaces to designing systems is worth a read. ↩
Tools like Figma and Storybook are powerful collaborative tools for designers and developers respectively, particularly in enabling feedback. But they can calcify design systems into something that solves the needs of one discipline while disenfranchising others. This isn’t an inherent weakness of these tools. They’re tailored to the needs of the relevant discipline, and not intended to house design systems for organisations. Yet, this is the reality of what happens in large organisations where siloed working is the norm. ↩
If they’d been called UI systems to begin with, we might have avoided this confusion. We’re not the only ones saying this: See this X thread with Nathan A. Curtis and Brad Frost. We tend to say UI system rather than design system. It’s a more accurate description of building systems to create web UI, and it helps set expectations. But if a client wants to call it a design system, we won’t argue. ↩

Scott’s Law of Rebrands

Paul Love — Tue, 25 Jun 2024 09:14:23 +0000

Over time, the probability of a rebrand starting in the midst of a large web project approaches 1.

— Scott Boyle, Measured Co-Founder

Like any good axiom, Scott’s Law of Rebrands was borne of experience. We’ve seen it enough that we know it to be truthy. (We call it Scott’s Law with tongue lodged firmly in cheek, of course.)

Rebrands happen for any number of reasons — repositioning in the market, new or evolving contexts, or to breathe new life into a brand. Brand identities tend to last 2 to 5 years, so the odds of a rebrand overlapping a major web project are high — and grow over time.

For our purposes, let’s discuss a rebrand outside the scope of your project, but which will affect it in myriad ways.

Such rebrands are always challenging. But approached the right way, they can bring long-term benefits to your project. Here’s how to go about it.

Accept the cards you’re dealt

A major rebrand will disrupt a large web project running in parallel. Expect questions from your digital teams:

What’s the scope?
When’s it starting?
How long will it take?
What does it mean for my project?

No one has the answers when a rebrand kicks off. All you know is that it’s happening, you won’t have control over it, and it will take as long as it takes.

Ongoing communication with brand and marketing teams is vital. They’re often siloed from the implementing teams, which adds complexity (although less so for digital brands.)

Make friends. Create lasting feedback loops between brand, marketing and your implementing teams.

Get on the front foot

When you’re surrounded by uncertainty, take it as an opportunity to build something better. Here are three ways to do that.

1. Systematise

Look at what aspects of the existing brand can be systematised. For example:

Colour schemes and their contextual uses
Typography (type sizes, typefaces, fallback font stacks)
Icons (size, location, design descriptors)
Spacing and alignment (margins, component spacing, vertical rhythm)
Motion (timing, duration, motion descriptors)

Systematising the brand leads to a more consistent and polished UI.

It also makes the brand easier to understand, which helps to assess the impact of change. You move from the mindset of “there’s so much to do” to “here’s what we’ll do”.

2. Encode the brand

As far as possible, derive variables for what you’ve systematised.

This doesn’t necessarily mean creating design tokens, although it may. The aim is to make it easy to change any aspect of the brand identity. We call this encoding the brand.

Some might say otherwise, but you won’t be able to encode everything up front. New needs will emerge. And some things can’t be made into variables.

Encoding the brand makes your implementation as rebrand-ready as possible, and it simplifies future tweaks.

3. Plan for flux

Brand work, and the digital gubbins around it, is never finished.¹

With robust versioning and good communication, your organisation can safely manage changes to your system.

Label and communicate versions clearly, so everyone can see what’s changed, and make informed decisions about when to adopt. (We recommend Semantic Versioning.)

Call out changes in a visible and timely way.

Be flexible above all

Reality is messy and the future is unknowable. Systematising your brand and planning for change lay the foundations for success.

Seeing rebrands as an opportunity to make your system adaptable saves time and money in the long run.

Even when there’s no rebrand happening, people will always tinker. Technology and humanity continually evolve — and so must brands. Duncan Nguyen’s Medium post on the evolution of Apple’s design language captures this well. ↩