Solving Fifty Shades of Blue

There was a stage a few years ago when our Intercom product featured roughly 50 shades of blue. Some of them were intentionally contrasting, of course, but many were just the product of different designers choosing subtly different shades at different times.

Now, 50 distinct shades of any color is rarely advisable, and if they are spread across every corner of a product, it is particularly ill-judged.

Those shades of blue were just one instance of inconsistency that can inevitably develop when a product, and the size of the team building the product, scales fast.

We had a seemingly simple vision of a solution to address issues such as this – a comprehensive pattern library to act as a central repository for all our knowledge, processes, principles and resources. The aim was a single source of truth for designers and engineers across the company for reference and inspiration in the course of their work. It would allow us to harmonise not just the colors we used but also common user interface elements such as buttons, cards, tables and so on.

Like any software project, the work of building a library like this is never done.

One of our co-founders, David Barrett, had been maintaining a library of common elements since 2013, and his work served as the foundational inspiration for the pattern library, though we developed it more from a design perspective. The aim was to make it easier to build things, faster to design things, and above all, help to guarantee consistency.

But we knew that as simple as the vision was, the reality would be surprisingly complex – and above all would require ongoing iteration. Like any software project, the work of building a library like this is never done.

If you are embarking on a similar endeavour, here are some of the lessons we learned in the year since we built it that you should bear in mind.

One year later

With a lot of effort and hard work, we put together a website that we called “Build” – it contains our design principles, writing and tone guidelines, as well as a pattern library containing re-usable components and Intercom-specific objects.

But while we accurately predicted how demanding it would be to create, we didn’t quite anticipate how it would be used and and how it would evolve.

We adhere to the Jobs-to-be-Done strategy in designing Intercom – taking time to understand exactly what people’s needs are. However, we discovered that predicting exactly how our colleagues go about their work and what their needs are is surprisingly difficult – as it turns out, the design library was a better fit for some of us than for others.

It also helped shape our team’s mindset towards design system thinking.

That was because designers use patterns in varying ways – some designers lean towards strict adherence to the patterns, or even expand on them by introducing new varieties and styles, while others require more flexibility so they can diverge from the established patterns.

On the other hand, it significantly improved designers’ workflows as they are able to compose their designs much faster because of the shared Sketch file, making common assets available to the team. It also helped shape our team’s mindset towards design system thinking, which in turn improved the coherence of our product. Previously it was much more likely that two designers might design the same thing in two different ways, but that became much less likely with the central library as a reference point.

We discovered that in practice, our design system was based on a vision that didn’t entirely reflect how we actually currently work – the idea of a central repository makes a lot of sense, but making it a part of everyone’s workflow is a distinct and separate challenge.

In particular, having been built very much from the Design team’s perspective, the Engineering team found it rather less useful than we hoped: because of technical limitations, we weren’t able to include living dynamic examples for all components as well as code snippets for them.

Unexpected consequences

But the Build site did spectacularly succeed in an entirely unexpected way – it was embraced by new colleagues as an in-depth guide while onboarding. They found it to be an invaluable guide as they acquainted themselves with Intercom. The documentation proved itself extremely useful as a reference to answer both design- and engineering-related questions newcomers might have.

We have begun to think of it as a product and the other designers and engineers as our customers.

If given the chance to go back to the drawing board, I would focus on both the Design and Engineering jobs equally. I would also establish clear strategies and rules of the system at the very start – for instance, do we strictly adhere to these patterns, do we share the responsibility of updating and maintaining the library. Determining these guidelines from the beginning would help drive decisions as we developed the library.

Above all, what this showed was that we hadn’t quite predicted the right jobs to be done – for either new colleagues or people who were already very familiar with our principles and values.
This doesn’t mean the work involved was wasted (quite the contrary!), but with this insight, we can continue to adapt the library with a focus on helping people with the tasks they require. Ultimately, we have begun to think of it as a product and the other designers and engineers as our customers, and based on this ran research surveys and gathered feedback on how to improve it further.

Pearls of wisdom

To summarise our experiences in three nuggets of advice, I would first of all recommend that you formulate a clear strategy so there is a shared understanding how your library should be used. Think about how much customization and local changes are allowed, so designers can find the best fit that matches the needs of the solution they are designing for. Take this decision into account in code as well, so customizations won’t break anything.

Secondly, don’t be afraid to think outside the box for what your design system might become – just because you built it to be part of the current team’s workflow, say, doesn’t mean it can’t also be a perfect onboarding tool. Allow it to morph and evolve as it develops.

Finally, and I can’t stress this enough as it is really crucial for success: ensure you maintain the library so it reflects the latest state of your product. You can’t just build it and be done – it must be a permanent living document, because only if it is constantly relevant will the work be worthwhile and the results trusted. As I said above, just like software, a library like this must be constantly iterated on to stay alive. Otherwise, the number of different shades of blue in your product could be the least of your problems.