Skip to content
Nucleus Docs

Vanilla first

guidelines

What is vanilla first?

It’s a mindset, an undercurrent supporting our process.

It’s a mindset, an undercurrent supporting the process.

When it comes to ice cream; vanilla is a stand-out success. It may not have the complexity of mint choc chip, or the extravagance of Ferrero Rocher, but its simplicity is what makes it so extraordinary.

Its modest nature makes vanilla so popular; it can complement other flavours and satisfy multiple needs. Customise vanilla and you begin to gratify fewer needs.

Applying this analogy to creating solutions - a vanilla component should solve a problem with the simplest solution. Every iteration of a feature or component should use this approach first.

Why it is used

When building a design system it is important to ensure that it’s as future-proof as possible.

This means that it should be able to accommodate any changes to the brand, styles, or the introduction of additional brands, while still providing solutions that address the needs they are intending to solve.

The components are designed to solve common problems and can be reused and grown over time to tackle variations of that problem.variations of that problem.

How to think vanilla first

Peel back the layers to reveal the heart of the solution.

Feedback

First and foremost, it’s vital to engage in continuous open conversation. It’s the essence of engaging in all the expertise and experience we have in the community.

Research

First, identify the problem! This is done through the Proposal RFC (request for comments) process, everyone is encouraged to comment and get involved.

Once the big picture is understood of the problem, begin finding the common themes. Is there a pattern emerging? Define the scope in the simplest, most generic form explaining this problem.

It’s natural to look at what other design systems have done, and that’s great. It’s good to build upon other people’s learnings and research. However, this must be taken with a pinch of salt. A design’s main ingredient is its context. What works well for one, may not, and most likely not, work for others. To build upon another’s research, there should be an effort to conduct research independently.

Design

Think of the minimum viable solution to solve the problem. Distil it a bit further and use that as a starting point. Refer to the Nucleus principles to inform thinking.

It’s important to decipher the requests from colleagues. Consider the input from every source and perform independent research.

A request for change may be received that starts out its life as, “I need the moon on a stick”. Someone else may say that they too “Need the moon on a stick”. The similarities are obvious at first glance, but there is doubt as to what phase of the moon each request is referring to. How long is the stick? Does the stick have a handle?

Spread the net as wide as possible to understand the core problem. Shake off all of the influence from designers promoting their solution, ask for relevant research and undertake independent research.

Step away from any bespoke design influences from brand by removing typography, colour spacing etc. and understand the foundations of the solution.

Grab a piece of paper and a pen or pencil and list the essential requirements acquired by the research.

Development

As for designers, the same applies to engineers. Step away from our design system and the brand influence. Try things outside the system in a sandbox and work out what can be done with nothing more than the semantics.

To produce a robust solution, a good starting point is to identify if a native element or a combination of elements will satisfy the requirements. To find documentation and examples of native HTML elements and APIs read the MDN docs.

Understand which of these are fundamental to the solution, which are supporting and which are optional.

Ensure to continue the discussion with everyone who has contributed as it’s important to not overlook anything.

Accessibility is, of course, essential to get right. Take some time to understand the correct way to present this to a screen reader in a high-contrast environment.

Follow these key points:

  • Context - Understand all contexts in which this solution will belong.

  • Elements and APIs - Pick the right native elements and javascript APIs.

  • Semantics - Ensure it’ll fit semantically within all contexts.

  • Accessible - Accessibility trumps everything.

  • Familiar - If it’s a duck, make sure it looks like a duck and quacks like a duck. 🦆

  • Browser compatible - Gracefully degrade or make a note of any expected behaviour.

  • High contrast - When it’s displayed in high contrast ensure it performs well.

  • Brand - Apply the branding and detailed design once the foundation is understood.

  • Test - Test within every environment which emulates all the contexts discovered earlier.

  • Polish - Take this opportunity to refine and perfect every aspect of this solution.

Checklist

If someone is feeling stuck and wants to know if their solution is vanilla, they should see if they can answer the following questions:

  • Are they solving one problem at a time?
  • Is the solution accessible?
  • Does it build upon native elements or APIs?
  • Is it the simplest solution to the problem?
  • Can it be built upon in the future with no breaking changes?
  • Is it adaptable?
  • Can it be reused for other problems, and if so can it be built out to be more general?

Last updated: