We call these hidden pieces of complexity UI icebergs. The bit above the surface is evident, but you have to look deeper to see the true scale of the work.

The trick is to make sure icebergs land on the radar before they cost unexpected time and money. Fortunately, there is a way.

What lies beneath

During design, teams often zero in on primary flows, but can overlook the complexity behind the clicks. 

The problem compounds as Figma designs look increasingly real. People forget that designs aren’t the thing, even if they look like it. They’re lossy. They don’t capture every implication.

As an example, say a public sector client has a website of services for homeowners, including checking eligibility for grants and calculating energy savings. The designs look straightforward: a few buttons on a landing page plus some simple navigation. Dev teams estimate a few weeks work.

But it turns out grant eligibility needs rule engines for property type, location and income. Energy calculations need building data, usage patterns, and local climate factors.

Each tool turns out to be a complete application in its own right. That would have been good to know in advance.

Iceberg-spotting is a team sport

In the waterfall days, designers assumed developers would figure out the details. Developers assumed designers would spec everything thoroughly. User experience fell into the gap in between.

The difference today? Ownership of different parts of the experience is still siloed, but there are more roles and disciplines in the mix, and usually more product complexity. So there are many more gaps for things to get lost in.

Take an online shopfront. One team handles product pages, another owns checkout. The product page team doesn’t think about what happens after you hit the buy button. The checkout team doesn’t think about how items arrived in the basket. Iceberg ahead!

There’s rarely any one person who understands, or is responsible for, the end-to-end journey who also has the bandwidth to find and address icebergs.¹ The team must get together and think through each journey.

When to spot icebergs

Ideally, you’ll catch icebergs during early design work. The surest way to find them is to gather everyone together and go through every element systematically. 

Ask what’s behind each interaction — every link and every button. The response is often that it hasn’t been looked at yet, or it was presumed to be someone else’s responsibility. Iceberg discovered!

Behind that innocent-looking button could be a complete other web app, potentially more complicated than the one at the surface. It might be a system that doesn’t exist. Or it might need wholesale changes to support your proposal. It could be a third-party service that hasn’t been chosen yet.

You need to constantly review designs and consciously look for these hidden implications. A critical checkpoint is when the scope starts to become definitive. There’s no better time to ask whether it’s possible the team has overlooked massive piles of stuff.

Be sure to record every iceberg you discover, and remember that it shouldn’t automatically become the responsibility of the people that found it.

Risks of looking the other way

Fortunately, there isn’t a Titanic in this analogy to sink your project. The hidden work always appears eventually. 

The risk is that you discover more work to do after you’ve committed to timelines and resources. Worst case, you complete a program and discover significant extra work at the end. 

This is unlikely in practice as there are usually enough people who care to catch problems earlier. But unexpected icebergs can cause real budgetary headaches if they’re discovered too late.

Ultimately, the responsibility is collective and continuous throughout design. That way, delivery can remain a matter of execution rather than a series of unexpected discoveries.

Here are 11 reasons we’ve encountered:

1. Scaling problems
2. Bias for the boardroom
3. Lack of consensus
4. Unclear ownership
5. Gaps in the technology stack
6. Inflexibility
7. Multi-brand complexity
8. Short reach
9. Pre-digital legacy
10. No organising principle
11. 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.

We’d love to hear your thoughts. Get involved on Bluesky or LinkedIn.

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 
  icon="arrow"
  iconPosition="right" 
  size="large"
  variant="primary" 
/>

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.

We’d love to hear your thoughts. Get involved on Bluesky or LinkedIn.

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:

1. A central UI team builds the components
2. 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.

We’d love to hear your thoughts. Get involved on Bluesky or LinkedIn.

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 components: 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 expectations: 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.

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. 🫲 🫱

We’d love to hear your thoughts. Get involved on Bluesky or LinkedIn.

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:

1. Inter on Google Fonts didn’t have some OpenType features and glyphs that we wanted (rounded “quotes” and commas, for example)
2. 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:

1. 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)
2. 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+2190,U+2191,U+2192,U+2193,U+2212,\
U+FEFF --flavor=woff2 \
--layout-features=calt,ccmp,dnom,frac,kern,locl,mark,mkmk,numr,ss03

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.

We’d love to hear your thoughts. Get involved on Bluesky or LinkedIn.

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:

1. Reorder the upcoming milestones based on new information or changes to team capacity
2. 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.

We’d love to hear your thoughts. Get involved on Bluesky.

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.

We’d love to hear your thoughts. Get involved on Bluesky or LinkedIn.

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

We’d love to hear your thoughts. Get involved on Bluesky.

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:

• What is Scrum?
• What is Kanban?

When Scrum makes sense

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

1. Aligning team members from different disciplines and experience levels around a unit of work
2. Demonstrating whole-product improvements at very frequent intervals
3. 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.

We’d love to hear your thoughts. Get involved on Bluesky or LinkedIn.

Like the cobbler’s children our visual identity had been somewhat neglected. When we founded Measured we quickly put together a nascent visual identity . It wasn’t terrible, but we always knew that the branding, and by dint our website, didn’t reflect who we are, or the quality of work we deliver.

In mid-2024, we decided it was time to do something about it. Here’s a look at how we developed our new visual identity, the thinking behind it, and some tips we’d share as a result.

The design process

We partnered with James Cross, a highly-experienced designer based in Copenhagen, to develop a new identity. James has a storied career spanning print, digital, and art direction, and his expertise was invaluable.

We kicked off the process with open-ended exploratory work: reading, research and prototyping ideas in Figma. We wanted the identity to come from us. This work was then distilled into the brief that we gave to James.

From there, the process was collaborative and iterative. James worked in rounds, presenting a number of options in the early stages, and then iterating on the preferred routes.

At each stage, James would send over the latest designs for us to look at. Once we’d had a chance to digest them, we’d jump on a call where James would present the thinking behind them, and we’d give feedback. We didn’t need to share written feedback at any stage.

We went through three or four rounds, starting with the key concepts before arriving at the last details, and ultimately a system that felt right.

The corner

At the heart of the identity is a simple shape we call the corner. This became the foundation for everything else — the logo, UI curves, background patterns, and more. It’s a versatile device that allows us to create recognisably Measured visuals, even without the logo.

Typography and colour

Typography was a key focus. We initially approached it from a techy perspective, particularly as the Display variant of Inter (our brand typeface) had recently released, optimised for headlines and large type. But James suggested we look at more timeless and classic alternatives.

We took James’s advice on styling headlines: no Inter Display, and instead of going bolder as they get larger, we reduced the weight for a calmer and, dare we say, more premium feel.

We built a colour palette with a range of blues and other colours, giving us options to play with while prioritising accessibility. James encouraged us to lean into the new blues as the primary expression.

We carefully considered background patterns and other design elements, which all derive from the corner shape and principles of the identity.

Where next?

The new visual identity is systematic, intentional, and built to last. It’s professional, clean, and flexible enough to evolve with us as we grow. We’ve already applied it to our website and social presences, where it’s been pleasingly well-received.

It’s designed to be flexible, so we can apply it to everything from physical media to video and animation if and when we need. We’re excited to see how it evolves as we continue to grow and experiment.

We’re pleased to finally have a brand that feels like us, so thanks go to James for his excellent work. We’ll share more about how implemented the new identity soon.

Visual identity tips

To wrap up, here are few tips to consider if you’re embarking on a visual identity refresh for your brand. These are things that worked well for us.

Start with a tone exercise

Ask your team to describe your brand and what sets it apart from competitors. Words like calm and intentional emerged from our exercise, and became guiding principles for the design.

Write a strong brief

Spend time crafting a clear, detailed brief before bringing in a designer. This helps you get the most from their expertise and keeps the process focused.

Look beyond competitors

While it’s helpful to look at what your competitors are doing, don’t be afraid to draw inspiration from brands you admire in different industries. We looked at companies like Vercel and Stripe.

Collaborate across disciplines

Bringing together design and content early in the process was key for us. It helped us tackle the communication problem from multiple angles and create a cohesive result.

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:

   • CSS Modules
   • shadowDOM
   • CSS-in-JS

   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’d love to hear your thoughts. Get involved on Bluesky or LinkedIn.

Essential details

• Saturday, 29 March, 2024
• 8:30 am–3:00 pm
• The Barbican Centre, Frobisher Auditorium 1 (Map) — We recommend entering by Silk Street
• Ticket information

About the event

State of the Browser is a super event for anyone who works in the world of web. The talks are always engaging, and it’s a really lovely vibe in person (though you can attend online too).

This year’s speaker lineup is shaping up nicely. You can follow speaker announcements on London Web Standards’ social channels: Bluesky, LinkedIn, and Mastodon.

Find us on the day

We won’t be speaking, but will be around all day to talk about UI, branding and accessibility — or whatever else grabs you. (Weather chat is still most welcome.)

Once more, thanks to London Web Standards for letting us sponsor. We‘re pleased to be involved in a small way.

Here’s the ticket link once more.

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:

   1. Drafted by the outgoing team
   2. Iterated by the outgoing team based on feedback and observations
   3. 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.

We’d love to hear your thoughts. Get involved on Bluesky or LinkedIn.

Essential details

• Wednesday, October 2 to Friday, October 4, 2024
• Brighton Dome, Brighton, BN1 1UE (Map)
• Ticket information

When to find us

Chris, Scott and I will be there to chat about all things design system, and UI in general. We’ll be at the conference bit on Thursday and Friday, but not the workshop on Wednesday.

Tickets are still available, and the speaker line-up looks fantastic. The Brighton Dome is worth the price of admission alone. An easy event to recommend — hopefully we’ll see you there!

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.

We’d love to hear your thoughts. Get involved on Bluesky or LinkedIn.

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.

We’d love to hear your thoughts. Get involved on Bluesky or LinkedIn.

Good demos build trust in what you’re building, and the people building them. But because they’re so ingrained in our work cycles, they can become stale.

Here’s what we’ve learned works well over our years of practice. Hopefully this will help keep your demos interesting and useful to others. (Feedback welcome!)

What we mean by live demo

By live demo, we mean one that’s happening in the moment, not pre-recorded. But not necessarily in person. Online demos have become normal. They’re easiest for large, distributed organisations, which is why we advocate for remote-friendly tools.

We’re working on the assumption you’ll use your organisation’s preferred calls and screen-sharing app, whether that’s Teams, Zoom, Hangouts or whatever.

What, when and who?

We recommend breaking out of the cycle of demoing any old thing just because a sprint schedule says it’s time. If you have something interesting to show at the end of a sprint, great.

If you find yourself wondering what to demo, that’s a sign that the cadence can be optimised. Do away with demos that amount to status updates. These are useful, but don’t warrant getting everyone together. Write week notes instead.

Another benefit: you’ll break the pattern of different teams demoing at the same time. This can mean teams end up demoing to themselves.

What to demo

What should you demo? For us, there are three criteria:

1. Is it visual?
2. Is it interesting?
3. Will people understand it?

If the answer to all three is yes, demo it. Especially if you’re showing something that’s new to the organisation. Design systems are a great example.

When we say visual, we don’t mean pretty. We’ve found showing design tokens as text strings helps make them tangible.

If you’re not familiar with design tokens, you can think of them as small pieces of a brand’s design system that are likely to be used again and again, like the font on a button. They’re easier to see than imagine:

So long as it’s interesting in some way, demo it. It’s OK to show a small unit of work. This works well if it’s something people have been asking for. It shows you listen and sweat the details.

But, if you don’t have at least 15 minutes of stuff to show, it’s not worth the time and effort.

For example, code refactoring is important work, but doesn’t make a good demo. Neither do things you’ve built and thrown away. Unless they contribute to a broader narrative, nobody cares. Gauge demo-worthiness by interestingness, not value.

When to demo

Share things as soon as possible to get feedback early. Constructive feedback is like sunblock: better sooner than later.

Demo frequently. If a project is likely to run for a few months, weekly is great. On longer projects, we tend to demo every few weeks.

It’s OK to leave longer gaps over summer and winter festivities when people are less likely to be around, or as engaged. Trust your instincts around the organisation’s working culture.

Who to demo to

Invite everyone who may have interest in your project, however tangential. Prompt attendees to let other people know.

In a big organisation, you won’t know everyone with a vested interest. Casting the net wide at the early stages gives you the best chance of winning hearts and minds, and can prevent friction later on.

If you build a regular audience, you build a positive culture around your demo series. That’s good for visibility and trust.

Who should present

Try not to demo alone. Bring at least one pal. Wrap your demo inside a short presentation with a slide deck. This will help you figure out who does what and when.

The deck should tee up the demo, set context, and invite questions and feedback at the end. A non-demoing team member can do these bits.

Have a person who helped design or build the thing do the actual demo. They’re best placed to show the detail, explain the rationale of your approach, and field questions.

At any one time, the person presenting should focus only on that. The other person can assume a support role. They can note any questions in chat, keep an eye on time, and deal with any issues that come up, technical or human.

It can be helpful to invite experts who aren’t part of your team. They can field broader questions about your project’s place in the organisation. You might invite engineers or brand people if your work has a bearing on their strategies.

Designing your deck

Your slide deck should introduce and set the context of your demo. It should explain:

• What you’re demoing
• Its purpose
• Goals it contributes towards (this is persuasive and powerful)
• Why it’s relevant to the audience

Our decks also have slides that:

• Show the agenda
• Link to previous demo decks
• Signpost the start of the demo
• Signal changes in speaker
• Show a roadmap of what’s next
• Prompt audience questions
• Let people know where they can follow progress

You can’t control how your slides will be shared. Simple, concise slides are best, but each slide should have enough context to make sense to people who weren’t there.

Doing presentations has great advice for putting slide decks together. It’s optimised for “big” presentations, but there’s plenty you can apply to demos, including how to make your deck a useful stand-alone resource.

How much to prepare

It’s hard to know how much to prepare. A demo isn’t a high-pressure presentation like a sales pitch to a new client. But it does need to be clear and concise, so take as much time as you need to do that.

New teams and projects will mean more prep time, but it does get easier and faster. We can take a day or two to prepare to demo a new project. But we can get this down to a few hours as we find our groove.

Do a dry run

Do at least one practice run with everyone involved. If possible, invite a few people you trust to be the audience. Ask for frank feedback about what worked and what didn’t.

Get a feel for how long it will take and find ways to make it shorter. Cut flab. If you’re clocking in at over an hour, it’s too long. Make it as short as it can be but as long as it needs to be.

Have a contingency in case technology fails on the day. If you’re demoing live software, you’d ideally have backup screenshots or a pre-recorded screen capture if you have time.

The practical stuff

There are always practical considerations. A tricky one is cameras on vs. cameras off. As presenters, you should have cameras on.

If your work culture encourages it, you may like to suggest everyone attending has their camera on too. It’s easier to communicate, field questions, get feedback and gauge the vibe. But if the culture welcomes cameras off, do respect that.

You should also:

• Present from a quiet location
• Present from a well-lit location (but avoid having bright light directly behind that makes you hard to see)
• Use the best camera and microphone you have
• Avoid emphatically banging your desk (which wobbles your camera)

We choose to avoid blurring our backgrounds on calls when possible. That’s an aesthetic choice, and we know there are good reasons for people to mask their background. Do what’s best for you.

Doing the demo

Everyone presenting should join the call 10 minutes before start-time. If you’re demoing alone, ask a friend to join early. Test everything, including microphones, cameras and screen-shares.

If you’re using Microsoft Teams, it will announce to everyone that the meeting has started. You might like to drop a “no need to join yet” message into a channel.

Unless policy prevents, record the demo so people can catch up. If you’re presenting to a new organisation, check that this is OK. You may prefer not to record if the topic is sensitive. If you are recording, let everyone on the call know before you push the button.

The rest comes down to how you present and communicate. There’s a world of considerations to developing these skills. A few things we’d highlight:

• Pace is important — not too fast, not too slow
• You’ll improve with practice (demos are a reasonably low-jeopardy way of developing presenting skills)
• Doing presentations has great tips on the performance side of presenting

Fielding questions

Encourage questions, but on your terms. Decide in advance whether to allow them during the demo, or save them till the end. You may prefer to do them last if you’re presenting to:

• A new, unknown group
• A large group
• People you know may derail the demo (in a well-intended sort of way, of course)

Sticky wickets

It’s OK to pivot to questions at the end if things get tricky.

A big risk is someone senior dominating with questions and feedback, or talking over your demo. If that person is an important stakeholder, you might decide to accept this. The important criterion is their role in your project, not their seniority.

If it’s not an important stakeholder, it’s best to politely but firmly insist on questions at the end. This will help your demo go smoothly, which is foremost a benefit to your audience.

An important skill to develop is being chill in the face of conflict. No one wants conflict, but it does happen. Being the unflappable person in the room will only build trust. That doesn’t mean having all the answers, but it does mean thinking before responding rather than reacting.

It helps to have your project spiel down pat. If questioned, be ready to articulate what you’re doing and why. These questions could come up when unfamiliar project teams and leads come along.

Duck into chat

You can prompt people to drop questions in chat. This can be distracting, but may be less so than letting chat go un-moderated. If you’re not presenting in that moment, reply to questions in the chat.

If someone voices a question when they shouldn’t, support the presenter by policing the situation. It will help them keep the thread.

At close of play

Leave at least 10 minutes for questions at the end. Less than that isn’t enough, and sends the message you’re not interested in feedback.

Let everyone know follow-up questions are welcome and where to put them. It’s good if this is in an open channel, so everyone can benefit.

Following up like a pro

Put your helpful hat on as soon as the demo’s over. Copy-paste the chat history somewhere safe so you can follow up on unanswered questions, or ones you can now answer more fully. It’s a nice touch to re-share contributions and links shared by attendees too.

Share the slide decks with everyone straight after the demo — and not only with people who attended. Check your speaker notes first. Some may not be useful. Some may cause embarrassment.

If you have time, review the recording to check that spoken questions were answered well. You might like to re-share the spoken questions and answers in text format. Share the recording too.

Track follow-up conversations in chat and field any new questions that come up.

If your demo was one in a series, ask attendees to let other people know about future demos.

Not following up properly can undo effort you’ve put into demoing well. It shows you value people’s time, and their right to be informed.

It gets easier

There’s a lot to think about, but demos don’t have to be scary. If we’ve given the impression that demos take a lot of time, it’s because they probably will for the first few goes.

But it gets easier. With practice, you’ll hone skills, processes and tools. When there’s a hitch, remember that people probably won’t notice, and almost certainly won’t care. People are kind, patient and understanding.

Try to have fun. You won’t get everything right in the early stages. Every hitch is a chance to do it better next time.

We’d love to hear your thoughts. Get involved on Bluesky or LinkedIn.

We thought we’d expand on that here, in case it helps people understand us better. (And, selfishly, we might be glad we wrote this down one day.) So: here’s why we’re called Measured.

We take care in our work

Whether it’s our approach to technology, design, strategy, or ways of working and communicating, Measured encapsulates our careful, precise approach.

As mantras go, we don’t love move fast and break things. We prefer move fast and leave things better than you found them. We don’t want to break things, and we want the people we work with to know that. It’s better, more responsible and faster in the long run to not break things.

Measure twice, cut once is the vibe.

We’re pragmatists

We have professional opinions, and we share them when it’s helpful. But we’re pragmatists, not ideologues; helpers not disruptors.

In our experience, strong opinions lead to heated discussions, and heated discussions end in logjams. We listen more than we speak, and we find the middle way (again, fastest). We always flex to the client’s unique circumstances.

We quantify

We’re goal-focused. We prioritise outcomes over outputs, and we favour those that can and should be measured.

We’re not blinkered about it. We don’t view metrics in isolation, ahead of everything else. But we value objective and transparent measures of progress. It makes our work accountable, validates good approaches, and helps us correct course when needed.

In truth, we weren’t thinking about metrics when we came up with the name, but it works, even if it’s something of a retcon.

We’re craftspeople

Measure means the length of a line of text. So we started using measured and isMeasured in our code as property and class names. It indicates that a piece of text should have its line-length restricted for readability rather than filling the width of its container.

In other words, Measured is a small doff of the cap to the craft of what we do.

We’d love to hear your thoughts. Get involved on Bluesky.

Essential details

• Saturday, 14 September, 2024
• 9:30 am–5:00 pm
• Barbican Centre, London (Map)
• Ticket information

About the event

In case you’ve never been, State of the Browser is an excellent one-day event organised by the lovely and talented people at London Web Standards.

There are a variety of talks about things like web standards, accessibility, and the state of the modern web in general.

The talks are never not insightful, and it’s a great chance to catch up with web industry people. We highly recommend—hence this post.

Talk to us

The reason we’re sharing this is that we’ll be going and would love to catch up with you.

Possible topics of conversation:

• Weather
• What you’ve been working on
• Your UI and branding headaches
• Weather
• Design and UI systems generally
• Accessibility
• Coffee?
• Weather

But other than that, we’re pretty relaxed about conversational subject matter.

We don’t plan to speak at the event, but a big thanks to State of the Browser for letting us sponsor.

Grab a ticket, perhaps?

When we started Measured, we knew we’d want to write things about technical aspects of our work. Inevitably, that means publishing code snippets.

We built our website to comply with WCAG AA accessibility, so we needed our code snippets to comply too. That meant applying a colour scheme to snippets to comply with the WCAG requirements for contrast.

More than that, we actually needed two schemes because our website adapts to visitor system preferences for day and night modes.

When we went looking at colour schemes already out there, we ran into one of two issues:

1. They weren’t AA-compliant
2. They were visually jarring (and in a way that wouldn’t work alongside our existing brand colours)

So Scott set about creating them instead. We collectively decided to release them as open source in case people shared our need for AA-compliant Base16 schemes that, not to put too fine a point on it, also look quite nice.

They’re available on GitHub for anyone to use. The obvious use cases are for either writing or publishing code, but the underlying schemes could be used for any lightweight web project.

Notes on development

A few more points for anyone interested in a bit more detail:

We didn’t start from scratch. We used Solarized as the basis of the project. It didn’t meet AA criteria, but it did give us a good platform to build from. From there, we essentially adapted our brand colours to meet Base16 needs.

Once we’d decided to share the schemes, we were keen to contribute to the Base16 ecosystem. To that end, we submitted pull requests to a couple of GitHub projects with mixed success. But the schemes are now included at Tinted Theming.

We’ve assumed this project will potentially interest developers, so we haven’t included much hand-holding in the README. That said, we did want to make this work immediately useful, so the repo includes files to get the schemes working with widely-used tools. Specifically:

• CSS and extensions
• highlight.js
• iTerm2
• JetBrains
• Visual Studio Code

We don’t plan to do more work on this project, but we welcome contributions. There is scope to support more tooling, for example.

You can start using the Base16 Measured Scheme via the GitHub repo.