Leading the Vanilla design system

After a busy year of working on our Vanilla CSS framework, I wanted to reflect upon what I have learned, and share my thoughts on leading the design for a growing design system.

How it all began

Whilst working as a visual designer across our suite of Cloud and Web products, I became aware of all the different styles used in each product. Which gave me an overview of how we were slowly becoming inconsistent in design.

I was then offered the opportunity to lead the design for existing and new components, and oversee explorations and design solutions of undefined problems in our range of products.

We’re all unicorns

Collaboration between designers and developers is essential in creating a sustainable and robust design system. We are a small team of two, but our work has become the building blocks to all our products.

Allowing designers and developers to work better together, we continue to improve communication between teams and organize components for easier use in complex interfaces. Especially applying Vanilla to our Cloud applications which I’ll talk about in more detail shortly.

Seamless site migrations

We currently have 47 websites from marketing to cloud applications under our suite of products here at Canonical, the Vanilla squad are working through migrating these sites to our latest release.

We’ve completed 60% of the migration and are making good headway. Once complete, our codebase will be unified across our sites making it easier for our front-end developers to jump between projects. And from a design perspective we will have a consistent look and feel.

Below are a few examples of marketing and product marketing sites.

Getting the design system into our Cloud apps

Originally Vanilla was built as a tool to quickly and seamlessly build websites using our out-of-the-box components. Due to the growth of company products and visibility of Vanilla, teams are now requesting Vanilla to be added into their projects. Which is amazing!

At the beginning of this year we began to migrate our Cloud applications including Snappy, a command line tool for writing and publishing your software as a snap. MAAS, an automation tool for provisioning your physical servers and Juju, a tool to configure, scale and deploy your software.

This has been crucial for the development of Vanilla as it’s made us aware of components that do and don’t work, improving our process with weekly Design and Product reviews to catch any requirements for new features or future changes we need to be aware of.

Changing or updating a component in one place can affect many sites in a bad way, so it’s made us be more aware when proposals and requests are made.

Whoop-whoop! That’s the sound of the component police!

With any design system there needs to be an approval process to stop adapted components featuring in our websites or cloud products, to do this we introduced a bi-weekly Vanilla working group for both designers and developers to attend.

The goal of this meeting is to discuss new and existing components, look at GitHub proposals and discuss any questions from the team. This meeting has proven a success in allowing every member of the Web and Design team to be involved with the framework and have sight of new and upcoming features. Winning!

I’m learning as I go

It’s been a fast and exciting year working on Vanilla, and I’ve learnt a lot, from working in Code to appreciating design in a different way.

I will continue to improve the design of components and our documentation, and most importantly increase the adoption of Vanilla. Not just internally at Canonical but also for a wider audience in the outside world.

We don’t plan on ever calling Vanilla complete, and there’s still a huge amount of work ahead of us. It will evolve as our suite of products develop, but at least now we know the foundation is strong.

Future 2.0 release

Our latest release of Vanilla 1.8 is our most stable release to date, landing some great features including redesign of our Documentation site, reducing the file size of the framework with mixins in CSS, newly added Ubuntu Thin font, added the parker stylesheet analysis tool to the project’s tests to name a few…

A majority of our key marketing sites and Cloud applications have migrated to v1.8 and are functioning well. With that in mind we’re taking a step back to focus more on performance and improving our documentation.

A list of high-level items we plan to add our upcoming 6 month roadmap cycle for our next release:

• Simplify the Code base: Spacing variables, BEM nesting and Modular scale
• Add example templates when building components
• Reduce file size of the framework
• Deprecate duplicates/unused components
• Document do’s and don’t usage for components
• React v2.0 upgrade

Use Vanilla in your projects

View our documentation to find out different ways of adding Vanilla framework into your projects.