Time to assemble: Bringing our component library to life

It makes a lot of sense to build out a component library, especially if you’re working on multiple products in a business that’s moving at pace. I doubt I need to sell this concept to you, but in this article, I’ll share our story so far.

There are the obvious benefits, like consistency in design and build, but the good stuff doesn’t stop there. Thinking in ‘components’ brings order, and when faced with things like retrofitting user experience improvements to software that has been around for a while, it’s a welcome discipline for making progress and future planning.

Made by humans, for humans

Moving to style guide driven design and development has reminded us to ask ‘why are you here?’ and ‘what is your purpose?’ to the things we are designing, and while that makes the system sound like intimidating border control officials, the throttle is incredibly useful to ensure we design and build the right thing.

We’ve become even more sensitive to patterns and repetition so that we can use these to our advantage, but also mindful that we pay attention to content and tone to ensure the experience we produce has soul and personality. By missing that key ingredient, we’d risk being boring and lifeless.

Our component library journey actually started some time ago. We adopted the Atomic Design system for our marketing website a few years ago and when we took on our last redesign we opted to move from Wordpress to React. While the learning curve was steep at first, it was an important step to take as we knew we were likely to roll this technology out to our new software in the future.

In his book Atomic Habits, James Clear talks about making a 1% improvement in anything requires time before you see any noticeable benefits. If you assume that the benefits will be immediate, there is a period that he refers to as the ‘valley of disappointment’, and this can be a risky time for your component library.

A pivotal moment came when our Storybook was first demonstrated by the team. I was excited. Really excited. Our components came to life.

This was an important phase for our product, tech and design strategy — and after launching the new site and making some refinements to our process we wanted to take stock, stand back, breathe and sense check our decisions. This was after all a fundamental part of our technical and design strategy.

We asked for some help from the good folk at Clearleft, and they sent their team of designers and developers to come and work with us for a few weeks to see where we were at. They helped us make tweaks to improve performance and process, and after some fist bumps from Clearleft, we continued our component library journey moving from our website to our software.

This is probably a good point to explain our client/public facing ‘products’ and their respective technology.

Our vision has always been to offer accounting, help and business support to freelancers, contractors and small businesses no matter how those businesses are formed. We also want to inspire those that are thinking about bringing their business idea to life or making the leap to freelancing/contracting by giving them free tools, tips and advice so that they start off in the best possible way. Delivering much of this support and content through a single user interface that dynamically renders itself depending on the type of user account is our goal.

But hold your horses there for a moment. That vision is all well and good but with a feat like this, how on earth do we know we are using the right strategy with the right tactics? We set our technology and product direction based on a few factors which includes (but isn’t limited to), market conditions, competitor analysis and client feedback. We’re constantly learning so taking the opportunity to review our technology, architecture, service model and content strategy also guides us too.

We agreed that making our software user interface more dynamic, responsive and extendable is absolutely the way to go for us, but we want to get this good stuff out to our clients as soon as we can so we know we know what we have to deliver at each stage.

Even more reason, then, for adopting SGDD and design and turning our monolithic code base into microservices to ensure we do this in the best possible way and structure our design thinking.

Think dimmer switch not rocker switch

By creating a new beta environment and releasing updates in thoughtful stages while keeping that feedback loop with our clients (who are interested in trying our new, unfinished software) well and truly alight, we can iterate as we go without creating a huge headache for our 10,000 + clients in a live production environment.

Let me explain what I mean when I say ‘thoughtful stages’. We learnt a few things during our first pass with the component library. We learnt that it was possible to deliver a seamless experience and consistent design while using different technology behind the scenes — giving us time to update as we go without the UX being too jarring. The software that we provide to our clients (the ones setup as limited companies) is built using the Seam framework. It’s bespoke software that has been engineered specifically for our clients and has been developed over the last 10 years.

Switching out the front and back end isn’t an overnight job, so in the new world, we’ve decided to make a few big fundamental changes to logging in and the main navigation (as well as help and support) to begin with and then focus on particular areas of the software in stages.

This means that for a while, we’ll have a mix of old and new worlds in terms of front-end, back-end and design, but over time, more of the user interface will be updated so that eventually it will be a completely new experience which we can then make available for all of clients.

Reconnaissance mission

As mentioned earlier, thinking in components brings efficiency — eventually. The design and front-end teams spent some time dismantling the existing UI of our free and paid-for software with the purpose of looking for obvious component candidates and gotchas.

Ben, our Lead Front End Developer and Ollie, our Product Designer took a deep dive into our software and it quickly became clear that line items and filters were the two most ubiquitous elements, so starting with these, with the context of expenses (a well used feature), made a lot sense. Building a line item and filter component would be used across lots of other features so it would be a huge leap forward.

We learnt a bunch of things on our first pass of building a component library. It’s really important to put careful thought into the fundamentals like typography, colour and iconography etc. We’ve been splitting these out as design tokens that sit outside of the library as we don’t consider them components, nor do we see them changing a great deal.

Looking for opportunities

There were a couple of things we wanted to spend more time on during the website redesign, and one of those was accessibility around colour contrast. We wanted to address this at a component level so we’re now working on a way to offer an increased contrast view to those that want it.

Previously we carried over our brand font into our software, but it really wasn’t suited to numerical info, so we’ve taken the opportunity to change it in our new software. Before doing so, Conor, one of our Product Designers, built a handy tool that enabled us to quickly try different font variations and combinations so that we were happy information would clearly display for our clients.

We also looked at our design workflow and took the opportunity to refine it. We’re not a huge design team here at Crunch and we all now work in the same office, spread across product teams, but we wanted to make sure we were designing with the same assets.

We made the switch from Adobe XD to Sketch as our prototyping tool as we preferred the shared library, and while we investigated version controlling with Abstract, it’s not something we’ve adopted yet until we start to grow in numbers. During the current UI dissection, we all collaborated into a Real Time board and that proved a really useful way to break things down into one place..

Marginal gains

Moving to style guide driven design and development and building a component library requires lots of small changes in almost everything you do. I very much doubt there is a blueprint (that would be boring) — in fact, this should always be tailored for you, but these small changes all add up.

When the Team Sky cycling team was announced in 2009, managed by Dave Brailsford, they looked at every element in tiny detail knowing that it was the marginal gains that would lead them to victory. There was a rumour that Dave brought in a surgeon to show the team how to wash their hands so that they avoided passing on bugs and infections that could impede the riders.

I suppose in some ways it’s the marginal gains that determine the success of a component library — the benefit won’t be seen overnight but it will come and the shift in thinking and approach will offer considerable advantages and opportunities — so be ready to spot them.


Written by Mark Cossey, Head of Brand & Digital Experience at Crunch.

Find out more about the Technology team at Crunch and our current opportunities here.