Maintaining and organising a pattern library

In this post Alla, one of our designers, discusses organising elements in our pattern library and the challenges of maintaining modular design.

For as long as we’ve had a pattern library we’ve been trying to work out the best way to organise the patterns in it. In this post I’m going to share some of the different methods we’ve tried and how they’ve worked out for our team.

Why is organising a pattern library important?

If you work in a small company, chances are that you don’t have a dedicated design system team. At FutureLearn it’s the responsibility of all designers and front end developers to maintain and evolve our pattern library. This means that the effectiveness of this process heavily depends on two things.

1. Whether people can find things in the pattern library.
Think for a moment about the process of adding a module to a pattern library. If you don’t have a “pattern library master” overseeing everything, the process might go like this:

• You look in the pattern library for a module that would meet your goal
• If you can’t find it right away, you create a new one

With multiple teams contributing to the system, you can eventually end up with modules that have similar function but look slightly different. Instead of evolving existing patterns, you add new ones. And the more things you add the harder things are to find.

2. Whether the modules are being used in a consistent way.
The overall design needs to remain coherent even when it’s made of disparate parts assembled together by different people. If one designer uses “sequence” to preview the steps and another uses the same control as a tabbed navigation in a different area of the site, you get a disjointed experience. To prevent this from happening there needs to be some kind of guidance or inspiration for where to use a specific pattern.

Of course what’s important is not how you organise things but that everyone does it in the same way. Even so, it is hard to stick to a certain way if it doesn’t quite work, no matter how determined your team is to make it work.

Here are three of the ways we’ve tried to organise our library at FutureLearn and what happened:

Supporting vs structural

We started off by following Atomic Design, but after a while atomic classification started to cause confusion in our team. For example, there was no agreement when a molecule is complex enough to become an organism and we ended up spending a long time debating the difference between molecules and organisms.

After running an internal workshop with designers and developers we discovered that people classified the modules in a variety of ways and ultimately ended up with different groupings.

However, there were clearly two distinct types: “helpers” (supporting modules that are typically part of something else and can be reused within various components) and “standalones” (well defined and relatively independent part or section of a page, self-contained units of content and functionality). Typically molecules were “helpers” and organisms were “standalones”.

Most importantly we decided that we wouldn’t lose sleep over it and instead we would be more flexible in deciding which group a module belongs to. Rather than involving the whole team in the debate, the designer and developer who introduced a new module ultimately would decide whether it was a molecule or an organism. The rest of the team would accept their decision, unless they had strong, well-grounded objections.

But after trying out this approach, we discovered that it didn’t really fix the problem. Deciding whether something was a helper or standalone was nearly as hard as working out the difference between a molecule and an organism. We didn’t have nearly as many debates but we still struggled finding things in the pattern library, as many of them seemed to be randomly placed in the Molecules and Organisms menus.

By hierarchical role on the page

Another method we tried was to think not only of modules themselves but the relationships between them. If we’re sticking with the atomic design metaphor this method would be like looking at the chemistry between the elements and seeing how some elements are attracted to each other more than others.

So we tried to work out simple rules for classifying the modules that would also offer some guidance on how to combine them together.

The idea was inspired by a series of personalised children’s books called “Lost My Name”. In the book a child wakes up one morning and realises that they have lost their name. They set off on a adventure to find it. During their journey they meet magical creatures, and each creature gives them one letter from their name. They keep collecting the letters, as they go, until at the end of that journey they discover that all the letters they’ve been collecting come together to spell out their own name. It’s a magical moment if you’re a 4 year old learning to read!

Thousands of those books are printed every day, and the story always fits perfectly well together, no matter how short, or long, or unusual a child’s name is. Their process is based on a few simple principles.

There are 28 story segments, one or two for each letter of the alphabet; 3 helper story segments, which are used in some stories; 1 bridge segment, that helps to connect the parts together; an intro, an outro, and a cover. These principles make sure that the product always works, and that the book is not just a collection of parts but a coherent story, that’s at the same time personal to every child.

We tried to apply similar rules to how we classify and organise our UI modules. In addition to questioning the function of the elements and giving them names, we also tried to work out what their role in the context of a page might be, and define simple rules associated with each of these roles.

When it comes to putting those modules together, we know, for example, that Intro modules can only appear at the top of the pages, and that Outros close the page. Or that there can only be one Hero module per page, but as many Standard segments as we need, and that Bridges always have to have a module before and after them.

The team was enthusiastic about the idea initially but, having tried it in practice, we found those rules quite restricting. While it might have worked well for a small project, it was hard to apply this approach consistently to a website of FutureLearn’s size.

What we’re trying now: by purpose

After trialling all these different methods we’re now trying to classify elements by purpose, for example promotional modules, modules focused on encouraging learner progress, modules around communication with the user, and also a few social modules.

It’s worth mentioning that at this point we have removed organisms completely. After two years of trying to make them work we decided that there’s no point in forcing it. All modules are now are either an atom or a molecule, categorised by purpose.

This approach fits far better with our function directed thinking, and it seems to be working for the team so far. But as always we’ll continue experimenting and improving to try and make it work better.

Want to know more about how we build and design FutureLearn?
Check out Making FutureLearn.