Forem: Measured

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.

Problems with font distribution, and why versioning matters

Scott Boyle — Wed, 07 May 2025 12:13:07 +0000

Problems with Inter, and why font versioning matters

When we refreshed the Measured visual identity, a website rebuild was always part of that scope.

We expected to make some careful typographic refinements in that process. But what followed was an unexpected deep dive into how fonts are distributed and integrated into modern web infrastructure.

This is an account of what we encountered, the choices we made, and some thoughts that may be relevant to teams using fonts — and those making and distributing them. We’ve gone quite heavy with hyperlinks by way of explaining terms if needed.

Note: Though true when we were rebuilding the site around December 2024, some of the detail of what follows has since changed. I’ve done my best to call this out when that’s the case. Hopefully the broader thrust is still useful.

The plan

When we embarked on the brand refresh and site rebuild, we landed on Inter for its many benefits — readability and ease of implementation among them.

We wanted to use next/font/google to implement the Inter Google Font for its magical ways of optimising font performance. We wanted a fast site with green Lighthouse scores. (Along with images, custom fonts are a major cause of poor site performance.)

But when we came to implementation, we ran into some blockers:

Inter on Google Fonts didn’t have some OpenType features and glyphs that we wanted (rounded “quotes” and commas, for example)
Google Fonts not having Inter Italic at all (true at the time, but no longer¹)

Inter-vention needed

So - how best to optimally integrate Inter (Italic) with Next.js if it's not available as a Google Font?

Our answer was to use next/font/local, a feature that provides similar font optimisations to next/font/google, but for self-hosted font files.

But though this method worked, performance was significantly downgraded compared to using Google Fonts, and Lighthouse scores were distinctly non-green.

There were a couple of reasons for this:

Downloading Inter from Rasmus’ site offers no way to subset, meaning that our self-hosted Inter files were very large (weighing in at 740kb combined)
It turns out next/font/local doesn’t optimise quite as well as next/font/google, which leverages Google's CDN caching

Like the good stoics we are, we dialled into problem 1 as being within our power to affect, so we looked to subset the fonts as aggressively as possible to reduce the file size and get us back into the green.

After much trial and error, we eventually managed to subset the two Inter files so that they had all the glyphs we needed while remaining as small as possible. To do this, we used fontTools to try various subsetting and optimising techniques, and FontDrop to test the output.

In the end we arrived at this command line magic spell:

pyftsubset InterVariable.ttf \
  --unicodes=U+0000,U+0020-007E,U+00A0-00AC,U+00AE-00FF,U+0131, \
            U+0152-0153,U+02BB-02BC,U+02C6,U+02DA,U+02DC, \
            U+0300-0301,U+0303-0304,U+0308-0309,U+0323,U+2002, \
            U+2009,U+200B,U+2013-2014,U+2018-201A,U+201C-201E, \
            U+2022,U+2026,U+2032-2033,U+2039-203A,U+2044,U+2074, \
            U+20AC,U+2122,U+2191,U+2193,U+2212,U+FEFF \
  --layout-features=calt,ccmp,dnom,frac,kern,locl,mark,mkmk,numr \
  --flavor=woff2

The result was that our self-hosted files had a combined size of 144kb and Lighthouse performance scores were back in the green — not quite as good as they would have been with Google Fonts, but green nonetheless.

Most importantly: our site speed was fast again, and with the custom-designed true Italics and all the other typographical nuances we were after.

The need for font versioning

So how does this lead us to font versioning?

A good example is that Inter 3 didn’t have a separate file for Italics as they were handled with a variable font slant axis. When Inter 4 removed this variable axis and replaced it with a completely separate and custom designed Italic file, it took — and is still taking — tools a long time to catch up.

And because font versioning isn't really considered, someone using Inter from Google Fonts would have their italics switched from the variable font slant axis in Inter 3, to faux italics with Inter 4 overnight.

And all this without really any visibility. Google Fonts doesn't announce version changes, or even show the font version (at least not clearly that we can find — answers on a postcard).

To double check what version they were serving, we had to use FontDrop. So you really need to be tuned in to the font’s release history, and to typographical nuances in general, to have any idea about this.

Though it was a mission, digging into the details paid off for us. We were able to achieve the typographic clarity we wanted without significantly compromising performance.

Google Fonts now has all the Inter OpenType features and glyphs, plus Inter Italic, so the original problem is nearly solved. However, at time of writing, next/font/google still does not include Inter Italic. Hopefully it will be added in future — we should probably open a pull request! ↩

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. ↩

Understanding the trade-offs of using Tailwind CSS

Scott Boyle — Tue, 11 Feb 2025 10:55:05 +0000

If you work in web development, there’s a good chance you’ve come across Tailwind CSS. If not, it’s a good tool to have on your radar.

Tailwind is a CSS framework that uses a utility-first approach. Elements are styled directly, without needing to leave your HTML.

Its promise is that you can build modern web pages quickly and simply. Choosing a utility-first framework could have a significant impact on your project — particularly in maintenance and scaling. It undoubtedly has benefits, but they come with trade-offs.

In this post we want to explore some counterpoints to those benefits. Hopefully this will help you decide whether it’s the right tool for your project.

In no way is this intended as a take-down. In the quest to make life better for the people that build the web, Tailwind is a positive force. We write this from the point of view of practitioners evaluating a tool.

Benefits of Tailwind

Much has been written on the benefits of Tailwind, so we’ll cover those we see in brief:

No custom CSS: It provides ready-to-use utility classes that let you style elements directly in your markup.
Less need for naming conventions: It largely does away with creating and naming custom classes.
Good performance: It’s a small library with production builds that automatically strip out unused CSS.
CSS knowledge is less important: There’s less need for CSS skills on your team — lots of developers know Tailwind.
Good design defaults: You can mostly trust Tailwind’s defaults to quickly help you build something decent.
Easy to customise: If you do want to edit its defaults, it makes this easy through changes to a single configuration file.
Design consistency: Developers can apply consistent styles without having to choose exact values.
Responsive design: You can apply classes conditionally at various breakpoints without writing additional CSS.
Fast iteration: You can test and adjust things quickly, making changes directly in the markup.
Well supported Tailwind is backed by many plugins, extensive documentation and well-known paradigms.

For more on the benefits of utility-first, see:

John Polacek’s The Case for Atomic / Utility-First CSS (via Tailwind)
Ryan Flynn’s Mastering Tailwind CSS: An In-Depth Look at the Utility-First Framework
This Reddit thread, where the community shares benefits from a boots-on-the-ground perspective

Counterpoints to Tailwind’s documentation

Many of Tailwind’s benefits are clear-cut. But we’ve also seen cases made that we think require caveats, including those in Tailwind’s own Utility-First Fundamentals. Let’s look at these in turn.

1. Effort saved with class names and selectors

You don't spend any time coming up with class names [and] making decisions about selectors […] so your designs come together very fast.

Naming things is hard. But a well-named styling or theming architecture is a worthwhile investment on large projects.

Thoughtfully-named styles help teams develop a shared language for components and layouts, making it easier to collaborate across disciplines. This reinforces consistency and helps make sure that intentional design choices are carried forward as the project evolves. Consequently, experienced CSS people generally don’t spend time agonising over class names and selectors.

In contrast, relying too heavily on utility-first classes can result in context being lost. For example, developers have to interpret design intent from raw style rules rather than clear names.

Going further, advanced CSS selectors can make it easy to do things that are much harder, or cumbersome, using only utilities. For example, focus by demotion can be achieved in a few lines of CSS, but is an absolute casserole to do in Tailwind — less than ideal if the object is to keep your codebase simple.

Naming CSS classes isn’t that hard in any case. Well-considered naming conventions provide a straightforward way to choose intuitive class names.

There are also technical solutions that make naming CSS classes easier. For example, CSS Modules lets you scope class names locally. This means you can use simple, logical names without worrying about conflicts in the global namespace.

Overall, taking the trouble to develop a well-named styling architecture may mean more up-front effort, but it can pay dividends longer term.

2. CSS stops growing

Since utility classes are so reusable, your CSS doesn't continue to grow linearly with every new feature you add to a project.

This is true, but by using Tailwind your markup gets bigger every time you add a utility class. Consequently, it becomes harder to read and maintain.

Front-end abstractions are about more than CSS. Tailwind encourages utility-first development to avoid thinking about encapsulation and accelerate development, but this can have diminishing returns.

In our experience, it can mean time-pressed developers choose to keep adding Tailwind classes rather than breaking up their components into smaller, systematic pieces. Over time, this can make your front-end cumbersome and difficult to scale.

When you have a system of composable components, you rarely need to write new CSS. You can simply reuse the components.

3. Safer changes

Adding or removing a utility class to an element only ever affects that element, so you never have to worry about accidentally breaking something [on] another page that's using the same CSS.

This is a problem that has been solved by hard encapsulation in general. This means a component’s styles are confined to only that component — they can’t leak to other parts of the project.

Of course, Tailwind’s approach is a form of hard encapsulation, but it’s by no means the only game in town.

With CSS’s natural inheritance, styles can cascade across elements and contexts, sometimes unpredictably. Tailwind defines styles locally in the markup, sidestepping CSS inheritance by making sure that each element’s styles are explicitly declared.

This can reduce unintended side effects, but it also bypasses one of CSS’s strengths: the ability to create flexible systems that adapt globally with minimal duplication.

There are others tools available to do hard encapsulation, such as:

But, if your project is relatively simple, soft encapsulation through naming conventions like SUIT CSS may be all you need.

In sum, there are many ways to architect your styles so you never have to think about unintended side effects. Weigh up the options and choose an approach that works for you.

4. Designing with constraints

Using inline styles, every value is a magic number. With utilities, you’re choosing styles from a predefined design system, which makes it much easier to build visually consistent UIs.

We don’t advocate for inline styles, but this does raise a question about the problems Tailwind solves.

Magic numbers are arbitrary values in CSS that lack clear purpose. They tend to persist for fear of breaking something. Or they break things when they’re removed because their purpose wasn’t clear.

Avoiding magic numbers is good practice. But Tailwind utilities can be magic numbers too. In fact, Tailwind provides advice on how to use arbitrary values.¹

Designing to constraints can be done in several ways. CSS Custom Properties enforced by linting is a technique we’ve used at Measured.

Tailwind’s out-of-the-box utilities define a system, but it’s broad, with little guidance on usage. They can be an aid to consistency but they’re not a panacea.

5. Responsive design, hover, focus, and other states

You can’t use media queries in inline styles, but you can use Tailwind’s responsive variants to build fully responsive interfaces easily.

And:

Inline styles can’t target states like hover or focus, but Tailwind’s state variants make it easy to style those states with utility classes.

These points highlight Tailwind’s advantages over raw inline styles, but they’re less about why Tailwind is uniquely good and more about why inline styles are problematic.

While it’s true that Tailwind’s utilities can simplify responsive design and state-based styling, these problems can also be solved in other ways.

Libraries like CSS Hooks let you manage responsive designs and state styles directly in JavaScript. Similarly, approaches like styled-components or other CSS-in-JS libraries let you define styles with responsive and state-based capabilities in a flexible, programmatic way.

Tailwind makes these tasks easier in its own context, but is that a reason to choose Tailwind?

Other considerations

Here are two more considerations, though these aren’t in reference to Tailwind’s documentation.

Potential brand conflicts

Tailwind makes design choices so designers and developers don't have to. This can result in a recognisable look. Those familiar with Tailwind can often spot Tailwind-built sites.

However, every brand has its own architecture and identity (sometimes complex), which needs to be represented in UI design decisions. Though Tailwind supports theming, this is done within the constraints of Tailwind’s naming conventions, which might not make sense for your brand.

This is more complex with multi-brand systems, where one of two outcomes is likely. Either the resulting solution will make all the brands look like Tailwind, or it requires so many escape hatches that you'd be better off not using Tailwind in the first place.

You need to know some CSS anyway

To be most effective with Tailwind, you still need to have some understanding of the underlying CSS. For example, to understand Tailwind's flex class, you probably need to understand how flexbox works.

If you only learn through Tailwind, you will only have a truncated understanding of CSS. This means you will likely struggle to debug more complicated issues, or transfer your skills to other CSS architectures in the future.

To some extent, it’s an example of ecosystem lock-in, and one that creates barriers for experienced CSS people. Sometimes the class names are intuitive, and sometimes they’re not. Modern CSS is pretty concise in any case.

All things considered…

There are no silver bullets when making web UI. Weighing up CSS against Tailwind means weighing up:

Time spent naming CSS classes against time spent reading and parsing utility names
CSS size against markup size
Inheritance against encapsulation
Opinionated systems against flexible systems
CSS expertise against Tailwind expertise

Tailwind’s utility-first approach can work well for small-to-medium projects where speed and cost-efficiency are top priorities. This is especially true if you already have Tailwind skills — or a lack of CSS skills — on deck.

But for larger projects or teams with established CSS practices, it introduces challenges around readability, maintainability, and scalability. The larger and more complex your project, the less sense Tailwind might make.

Thank you to Matthew Lynch and Chris Villa for contributing insights and feedback to this article.

We recommend linting to prevent magic numbers in Tailwind, using ESLint-plugin-tailwindcss, for example. ↩

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. ↩