Own your process, build things bespoke

At the time of writing this, the News UK design team had just released version 2.0.0 of NewsKit (We're now on ), the design system used by our web products. Like many enterprises, we realised that we were often designing and building the same solution multiple times to cover all of our product portfolios.

In the words of NewsKit product manager, Ellis Capon:

‘Auditing the sites and seeing how much was shared led to a simple question, “Why don’t we build one, agnostic, themeable, high-quality component that will satisfy all of the requirements?”. And so the NewsKit Design System was born.’

An overhaul of processes#

Compared to other creative technologies, such as film or games development, it feels like digital product design is sorely lacking when it comes to automated processes and pipelines.

While we’ve shifted design software over the years from Illustrator to Sketch to Figma, the core sticking point across all these methods is the same: we’re still drawing vector metaphors of front-end interfaces and expecting development teams to figure out how to build it.

Sure, there are new design tools, development tools, and tools that are hybrids of the two such as WebFlow and Framer, and new kid on the block, Modulz that promise “no code, production-ready components”, though I remain dubious as to their efficacy. I guess “Well umm technically there is still some code, and they’re production-ready but only under these strict circumstances” is less catchy for marketing teams to sell.

The product design industry has a lot to learn from our cousins in the film and computer games industries. Our pipelines can be so much more than passing a vector file with some lines on it to a developer, and we can drastically reduce the number of repetitive tasks we do on a day to day basis.

Product design and development is a reactive practice. Although we’re rarely held to stringent deadlines like films and games, speed to market and the ability to pivot when we get new insight on customer behaviour is vital.

We can all sing the praises of iterative, human-centred, data-driven design — but how often are we iterating? How often are we getting insights from users? How quickly can we turn around a new iteration for fresh insight

Less manual labour — or more?#

NewsKit set out with the precedent to be a best-in-class design system, but with the rise of open-source monoliths, and the everything-as-a-service trend, it’s becoming increasingly easier to build, develop and maintain an enterprise-level design system. With that, it’s becoming increasingly harder to hold a competitive edge.

At a glance, the cost of paying for a handful of tools and services is drastically cheaper than the cost of a dedicated team, actively building and maintaining your design system. ROI is hard to estimate when we compare the two, so instinct tends to lead us toward the cheaper option.

This off-the-shelf method for system design allows teams to quickly get their foot in the door, pick a design tool, pay for some plugins, and plumb it all together. There’s a wealth of plugins already out there, with their own maintainers, available for free or at a relatively low cost.

However, you have to steer your design systems and processes to work within the space provided by those tools and plugins. The majority of your operation costs now come down to human hours, in making these tools interact with each other.

If you were to draw a flowchart of your end to end process, how many manual inputs are there, and how often are you repeating them? What can you do to minimise the amount of manual work you’re doing?

Suppose there was minimal manual input, and each step in the pipeline flowed neatly into the next. Make a style guide, point it to some components, and tada, Design System. This is great, you’re up and running, and all of the maintenance is someone else’s problem.

Except the entire system is fragile. There’s an entire chain of dependencies that you have little to no control over — all it takes is for one link in the chain to change, and the entire system collapses.

A good design system is as responsive as it is robust#

Let’s look at some hypotheticals.

You acquire a company, and your design team doubles overnight. The company directive is for the new team to adopt your design system. Is your system capable of that?

Your company decides to change its design tools. How quickly can you get back up and running?

The design tool you use releases a new version, making breaking changes to a fundamental part of your workflow. What do you do?

You go bespoke#

At NewsUK we knew we needed to be able to adapt to change. Owning multiple brands, each with their unique personalities and rich histories, our design system had to respond to new ideas, but also respect our well-established heritage. To reduce maintenance — and keep titles working at the same pace (or faster) — we knew we had to have one centralised team responsible for the day-to-day operations in running a design system.

There was no readily available solution on the market that allowed us to have one centralised design system, yet still have the flexibility to keep unique brands.

Like many design systems, NewsKit is built on design tokens — transferable and mutable pieces of style data that when combined, define a brand’s style. The idea is that you can swap out a set of tokens at the foundational layer, and everything looks different, but the functionality of your components remains the same. We store our design tokens in JSON files, which are ingested as part of our build process to render themes on the front end.

Initially, teams were having to handwrite these JSON files containing their theme data to pass on to developers, a process that was taking days or weeks, due to the amount of back and forth we’d have by accidental errors. It’s easy to overlook an issue in 600 lines of JSON, and designers couldn’t validate it without passing it on to a developer to build the theme.

Despite the long process of writing tokens, the idea worked for us in principle, and soon I had developed Sketch-To-NewsKit, avoiding any more handwriting of JSON. (Though we soon migrated from Sketch to Figma during the first Covid lockdown).

Great, but…#

Exceptions kept arising with this method of theming. One title didn’t want their CTA buttons to be their brand colour. For a company that sells stories, typesetting was of utmost importance, and impossible to codify. There was no one-size-fits-all solution to typographical hierarchy. ‘Can we do ____ with the system?’ was often met with a disappointing ‘No.’

To overcome some of these issues, we had the idea to use style presets — groups of tokens that can be pieced together to define how components look and feel. These exist in a config layer, between design foundations defined in tokenized themes, and components. Presets overwrite the default look of a component. What was once a restrictive system, suddenly became very flexible.

Whilst great in concept, and working seamlessly at the code level, there’s no easy way to effectively handle this in our design tool of choice, Figma. We’d had some success using Tom Lowry’s Themer plugin, swapping tokens like-for-like but we couldn’t control style presets. Maintaining themes was also somewhat difficult, juggling API keys between teams raised security concerns, and on the whole, was rather cumbersome.

We started with each design team managing their themes and style presets in Figma files we call web galleries. By duplicating the main base theme all of our systems are derived from, titles could then make changes to the styles to change how components looked. However, this meant that any time we made a foundational change to the parent system, we’d manually have to go in and update each team’s web gallery to be in line with the parent system — changes weren’t propagating down the tree.

We’re now looking into a custom solution, where each team pulls from a central library in Figma and can stylise it to meet their brand look — without separating from the main library. Design tokens and style presets are inferred from our Figma styles, and published to a GitHub repository for our development teams to ingest into the design system. We can then use these same design tokens, and style preset rules to theme our components in Figma.

Our custom NewsKit Theme Swapper plugin

Owning the process#

We have the ability to try out these changes to our system, due to owning the whole process — we’re not hindered by having to work within the confines and expectations of a certain tool.

We pilot these ideas in sandboxes and discuss them in a working group. Inspiration often comes from plugins by other developers. But rather than shoehorn our way of working to meet the needs of a plugin, we adapt open source tools and develop solutions to fit our needs.

To be clear, I’m by no means disregarding the work of plugin developers, toolmakers and design solutions. I’m a part-time plugin developer myself and hope that designers find my plugins useful. If these solutions work for you, great! But will they keep working for you, or have you built yourself into a corner? Whilst it may be hard to initially justify the return on investment, you could forecast mitigated risk. Adding a dependency, and bringing in another party always increases the risk. Can you afford that risk?

Final thoughts#

I think the case justification for bespoke solutions comes down to scale, ultimately. Answer these questions and act from there:

• How big is your team?

• How much maintenance have you got going on currently, and would a custom solution aid you in reducing the amount of maintenance required?

• What does a custom solution unlock for you, that you can’t achieve already?