Front end web development is constantly evolving. Websites are more complex than they have ever been. Dealing with steadily increasing complexity has pushed website creators to rethink how best to build and maintain websites.

One popular solution is to break down a website’s constituent components into ‘lego blocks'. Simple, reusable, self-contained chunks of UI that can be assembled in numerous ways to create a 'whole' website.

Taking the idea a step further, these building blocks can live independently from the actual website. An internally facing product where building blocks can be designed, built, tested, maintained and documented.

Such a product goes by a variety names - a Pattern Library, UI Toolkit, Living Style Guide, UI Toolkit, and so on. At Madgex we call ours a Front-End Toolkit.

Why are Toolkits needed?


As a website reaches a certain size and complexity a consistent user experience becomes harder to achieve.

Say for example a new form is added to a website. How should it look and behave? If the developers don’t have a form pattern to reference they may end up creating something that doesn’t fit with the other forms on the site, leading to an inconsistent user experience.

Toolkits solve the problem by becoming the single source of truth about how UI elements should look and behave.


Documentation is usually something that's put off. Let's face it, it can be tedious and dull to write. Toolkits overcome this because they're a self-documenting resource. They help to generate code, and as a happy side effect they also act as documentation for that code.

Toolkits aid collaboration between designers and developers, and also help with the on-boarding of new starters. A new designer or developer who is not familiar with the design language or technical implementation of a website can quickly get up to speed by familiarising themselves with the toolkit.


One of the most exciting things about toolkits is it’s possible to build chunks of UI in one place and then use them wherever they’re needed. This allows developers and designers to iterate in one place.

Take the example of a design team wanting to update the style of buttons across all websites. If the websites are using the CSS from the toolkit, all that needs to be done is to update the code in the toolkit. The live websites would then automatically receive the modified style.

Making websites easier to maintain has obvious benefits for a design team, but in addition, the benefits also trickle down to the users. When a website is easier to maintain, users receive updates, UX improvements and bug fixes more frequently.

What is Madgex doing in this area?

The design team at Madgex created a toolkit to help us build the Course Board product. Although it started life as the Course Board toolkit, we quickly realised it would be useful for any other products we create. So we split it into a ‘core’ and ‘product specific’ toolkit.

The core toolkit documents and generates production-ready code for use across all new products and websites. The product-specific toolkits then plug the gap when certain product-level UI patterns are needed.

Splitting up and sharing the toolkit in this way gives us the opportunity not only to create consistent, easily maintainable individual sites, but also a consistent and unified suite of products.

The future

Assets like CSS, images and JavaScript can be easily pulled in from a CDN and used cross-website, even cross-product. HTML is different. It’s difficult to reuse HTML because it’s delivered from the back-end and its contents change depending on the situation it finds itself.

An important rule in software engineering is that duplication is best avoided as it can lead to inconsistencies. Currently, duplication of the HTML in the toolkits is unavoidable because the only way to get the HTML from the toolkits into the websites is to copy and paste it. If we could use the HTML in the toolkits to power the products, that would be a huge boon.

Over time we’ve experimented with various open source projects to help us build our toolkits. Our current choice is Fabricator. It does a great job of documenting toolkit components and generating production-ready assets, but currently doesn’t address the problem of sharing HTML.

The holy grail of using the HTML from toolkit building blocks in our products may be achieved with a new crop of tooling, notably Fractal.

Fractal is made by the Brighton-based web design agency Clearleft. It aims to address the problem of sharing HTML with live websites by making it easy to use a templating engine that suits one’s own needs.

There are some technology hurdles to overcome, but we’re extremely excited with the progress made so far. We’re already starting to see the benefits of using a toolkit. Quicker development, easier maintenance and a more consistent user experience - not just great for developers, but great for our clients and their users too.

Other articles you may like...