Overview

Like any other organisation with multiple digital channels, we started to notice that our web applications where becoming disjointed and were lacking the necessary cohesion across the entire ecosystem.

It’s because of this that I decided to approach the key steakholders within the company and presented them with a possible solution, one that would maintain consistency across the board and make our entire suite of products more maintainable across all our teams.

It’s with this, that the idea of the Fernwood Design System was born.


Getting the buy-in

As our projects grew, so did our codebase, so did our interfaces, so did our user flows.

It’s because of this and my passion for both design and code, that I could see we needed a way to reel all these projects into a uniform approach.

The thing is, at times it may be challenging for the business to really understand the problems that lie below the deep waters of our code bases. It’s fair to say that one could just explain the issues at hand, but… wouldn’t it be better to show these instead?

I had done some research and found a great way of doing just that.

If I was to review all our projects and create an interface inventory then we could at least begin to actually see the numerous variations we had for simply one of our components (e.g. navigation). So with that said, that is exactly what I did.

After presenting this interface inventory (amongst others), there was no doubt that this was something that required attention, especially considering we had more projects in the pipeline that could leverage this design system.


Creating the foundation

I started by creating an exhaustive design system directly in the browser, then structured our pattern library using reusable variables and mixins to keep things simple using flexible modules defined by their parts and not their location.

The core foundation would be categorised into 5 key areas:

  1. Introduction
  2. Brand
  3. Code
  4. Copy
  5. Website

Each page would have it’s own corresponding sections which would provide a guide or reference to the corresponding team.

For example, within the Copy section, our communications team would be able to contribute to the design system by outlining how they would structure their content based on the required scenario.

The same approach could be used for all other categories, whether it be the Code section for our developers to understand how our component and modules worked and what kind of HTML structure would be needed to create these as shown in the guide itself.

The key emphasis was to make it as easy as possible for teams to contribute and understand what was being added to the design system.


Creating our components

By having our component HTML and CSS structure included within the design system it allowed for teams within the company to be able to use and maintain consistency across our projects.

Some of the components created included:

  • Grid
  • Navigation
  • Buttons
  • Inputs


Future

The Fernwood Design System was launched internally to key team members within the Engineering and Marketing teams.

As it stands the various components and sections are being used to update content across our projects as well as refactor our code base to create a maintainable and reusable library of patterns.

Our ultimate goal is to continue contributing to the project and make the Fernwood Design System the source of truth for the present and for the future.