Sometimes there is a need to experiment with something new, trying a different 'flavour' or perhaps even modifying something that exists, and you want a quick way to visualise it. You might want to mock up the idea in a familiar design tool, choosing components to work with like you would chocolates from a box, instead of spending time in the code trying to hack it.

Why do we even need a Sketch library?

Nucleus is a fully codified design system, and ultimately it provides an efficient way to get designers to build prototypes with the coded components. That is great, but sometimes there is a need to experiment with a new design concept or create things that don't yet exist.

That is where the Nucleus Sketch Library comes in. Sketch is our current default design tool. But it could be imported, easily to Figma etc. And it complements the rest of the Nucleus Design System code-driven tools such as Storybook and Nucleus Playground.

Nucleus design system is flexible and can work with different tools.

So what is wrong with the old Sketch library?

Nucleus has evolved considerably over the last couple of years. Before v3.0, the Sketch library of components had become out-of-date and less aligned with the coded counterparts. There were also mismatches with some foundational items like typography.

The viewports it catered for were many, so there was a greater risk of using the wrong version within a design. Because of this, it was also pretty hefty in terms of file size, and speed was becoming compromised.

Our approach

Modifying an older version of the library to update everything would be a massive undertaking. It made us ask, how might we make this more efficient? What do the users really need from the library? Do we need to have a design for every permutation of browser width? How can we make it more useful, usable and desirable?

The results of research and discussion with those that might use the library helped us shape the direction we should take:

Simplify the number of viewports. Designers typically needed examples with just two widths, Mobile and Laptop. Due to being the most commonly used viewports according to our data, we chose these specific widths.

Library menu shows relative viewport and component symbol to insert.

Code aligned components. The Sketch library components needed to reflect the most recent designs and match as close as possible to the 'real' coded counterparts for accuracy.

Flexible behaviour. If a designer wants to add longer text as an override, the component should adapt with similar behaviour to the coded version.

Due to the interdependencies of the existing Sketch components, it was better to start from scratch for v3.0, even if this meant a 'breaking change'. The older library could still work in parallel for viewing older designs until it becomes superseded.

What were the steps taken to achieve the vision?

Start with the foundations

We started with a blank Sketch file. Step one was to consider the organisation. We started with the foundations, set the colour palette variables based on brand and accessible colours using naming and hexadecimal values. Including system colours (for info/success/warning etc.), gradients and some opacity variations.

Setting of the colour variables.

Next, we added the typography styles and applied them to all text, allowing centralised control over any future changes. As we had already decided on just either a mobile or laptop viewport, this saved us from the need to create any more than two variations.

Our web components scale fonts accordingly to the size of the viewport, but in Sketch, we needed to define set sizes. It was also an opportunity to add the new Mark Pro font, earlier introduced to the brand for marketing campaigns.

We grouped these logically for both viewport sizes with H1-H6, Paragraph, Link, Action, and Inputter elements such as Labels and Data. Then displayed the size, line-height, margin-bottom and character sizes next to each in rounded px values from those computed by the browser (Sketch uses px values instead of rem, so based on the route being 16px = 1rem).

Creating typography styles mean consistency throughout a design.

Then we looked at adding the things you can't see – the spacers. We had extensively researched these and overhauled every component to use them. Used to ensure consistent spacing of elements within components, it was a good idea to include them as an overlay (hidden by default). That aids quick understanding and assessment of the component's construction.

Reusable building blocks - just like Lego

We then focussed on creating the ns-image, ns-illustration, and ns-icon components in Sketch, as these appear nested in many others. The purpose of this library is to have all our building blocks created as symbols first. Then we can reuse instances of them again and again but retain the centralised version, which can be updated, so changes would automatically apply throughout, saving many hours if we were to update each instance manually.

Once we had all these in place, we took each coded component in the Nucleus Storybook, assessed the code for precise construction and created a Sketch component as identical as possible.

Alignment between coded component and counterpart in Sketch library.

For each item we created, we also considered how it should behave. When adding or removing content, the relationships of size and positioning should be constrained or automatically extended to accommodate it. In the previous version, this tool was under-utilised but is a time-saving way to override the component's default content without breaking its form.

Carefully constructed nomenclature enabled us to create a comprehensive menu system. It mirrors the structure we have in Storybook of the coded components. By using the same naming convention, it removes any doubt. It can be considered an improvement from the previous version.

Distribution and next steps

We demonstrated the way things work to the Nucleus team first and then as a Spotlight in our weekly Drop-In Clinique (every Thursday at 2.00 pm) to the community, mainly consumers of Nucleus for British Gas. The feedback we received was very positive, and it felt like we had succeeded in solving the issue. So we released the file through GitHub (as v3.0 - as it was a breaking change) along with release notes.

Release notes, versioning and Sketch file on GitHub.

We advised those who had work in progress using the older Sketch library to continue with it until they had a new task suitable for adopting the latest version. It could be downloaded and installed immediately as the Sketch program can simultaneously run multiple libraries. However, we don't recommend mixing two libraries in one design for obvious reasons.

There has also been some recent interest in using Figma for this type of work, and as a proof of concept, we imported the freshly built Sketch library into Figma. It took just a few quick and minor adjustments for Figma's nuances for it to be ready and working. That helps us understand that the Nucleus 'component designs' library could be program agnostic. It can be easily adapted to suit whatever program the consumer is using.

Our approach resulted in a much lighter file size – down to 12MB from about 70MB, mainly due to the simplification of viewports reducing duplication. It makes it easier to maintain, and the components are all up to date and code aligned, and they are performant when modifying content. It means that designers can experiment or work with them and know they will tie in very closely with the real thing, helping to bridge the gap often seen between the concept and production and empowering the consumers to create high-fidelity designs rapidly.

nucleus.design