Skip main navigation
We use cookies to give you a better experience, if that’s ok you can close this message and carry on browsing. For more info read our cookies policy.
We use cookies to give you a better experience. Carry on browsing if you're happy with this, or read our cookies policy for more information.

Pattern Library
Introduction

As the FutureLearn platform grows and evolves, it’s important that the design patterns and visual style are upheld to deliver a defined and cohesive experience. In order to achieve this, we need to have a single point of reference for all the patterns we use, so that everyone internally can refer to them. We also need a shared vocabulary of UI elements and code, to allow teams to communicate with each other in the most efficient way.

We created this pattern library with several goals in mind:

  • to document the patterns we use, using the agreed shared vocabulary
  • to ensure a consistent use of patterns and UI elements
  • to provide guidance on correct usage of the patterns
  • to encourage re-use of code, reducing redundancy to a minimum

The library directly reflects the FutureLearn platform and uses the same underlying CSS and markup to display the elements and rules that make up the interface. It is a “living document” and should be updated when the code underlying the feature changes or when a new pattern is introduced.

Approach

We use the Atomic Design methodology, however in the two years of experimenting with it, we have adapted it heavily it to suit our project, our design process, and our team culture.

The main difference with Atomic Design is that our approach to defining modules and naming them is function directed, rather than presentational. It is based on evolving a shared design language collaboratively and empowering all designers and front end developers on the team to contribute to the system.

All modules are either an atom or a molecule, categorised by purpose. Having organisms used to cause a lot of confusion in the team, which is why they were removed.

Guidelines for adding patterns

The Pattern Library is for FutureLearn designers and developers. This means that you are your own target audience and writing for your future self.

Document modules as simply as possible. The three most important parts in documenting a module are:

  • Name
  • Description
  • Example (visual and code)

Try to keep descriptions short and to the point. The process of writing a description for the pattern library consists of answering three questions:

  • What is this?
  • What is it for?
  • How does it achieve its purpose?

The first two questions can typically be answered in one sentence. For example:

“Formula is a list of steps or ingredients to follow, which shows the learner how they can achieve something, e.g. a programme or a certificate”.

Next, you’d describe how this module achieves this. What are the distinguishing features in its design that make it effective? For example:

“A formula is presented with symbols and labels. The symbols are at the core of its function and labels support the meaning of the symbols. Presenting information as a formula helps make it more recognisable by creating associations with imagery as well as words.”