Matt Zarandi logo

Helix Design System

My journey in creating a design system at Daniel Wellington.

This project has been captured in a diary-like format that goes into detail as to how I worked to create a design system at Daniel Wellington, step by step. There are a lot of fantastic articles out there that I turned to in my journey but I was always left wanting more real ‘take home’ ideas. If you're on a journey to creating or maturing a design system, I’m sharing my experience in the hope some are provided. However, if you've simply arrived here through curiosity, I hope you enjoy the read! Please reach out with any questions via email or Twitter.

Intro

Implementing a design system at Daniel Wellington was a project I kickstarted within the first three months of joining the company. At the time in mid 2018, there were multiple product teams creating customer facing products in Stockholm, with more in China and Poland. Consistency was lacking, design and tech debt growing by the day and no single source of truth. There was no question one was needed but we were a small, newly formed team in a fast growing business, early in our journey of maturing UX. How could we begin to operate a design system with all the other challenges we needed to address?

The process of building our system had three distinct phases:

  1. Getting our house in order and documenting the current state through a UI kit.
  2. Placing this in a company wide accessible space with basic documentation.
  3. Moving the system into production with comprehensive documentation.

Generating Support

Before I could even get to step one the first task was to get company-wide buy-in, arguably the most important step. The design system would only get off the ground if everyone understood what one was, the business value it would bring, how it would benefit them and ultimately the customer impact. If misunderstood there was a risk it could be seen in a negative light in restricting creativity and autonomy.

This was undertaken through departmental presentations not only within the technology department but also in areas such as brand and marketing. Using the brand team as an example, they set our colour palette, tone of voice, typography, etc. I would need their input and buy-in just as much as that of developers.

Finally, I took a bottom-up approach. By initially focussing on those who would use the system in their day to day, I hoped to create an army of advocates that would support a latter move for investment into production.

The presentations themselves covered a broad range of topics but the justification behind the initiative was weighted in these 5 areas:

Below is a rough timeline highlighting the key moments throughout the journey, which I'll be covering in detail.

A timeline of the Helix journey
A timeline highlighting the key moments in the journey of getting Helix from idea to production.

Documenting the Current State

First things first, collectively we needed to understand ourselves at a basic level before we could even begin to start documentation. What was the correct ‘brand blue’ colour? Why do we have three types of product card? Why do we have this navigation pattern at all? All of these questions and more needed answering.

From the start, I looked to involve all those that needed to buy in to what we were doing. Through hosting multiple workshops we aligned on our definitive styles, consolidated patterns, components that crossed over, and completely removed those that were just a bad idea to begin with! This task was undertaken with representatives from multiple departments to make sure we made a collective decision. In addition, as a UX team, we also set our design principles to act as a north star in our decision making for this exercise and beyond.

Once we had achieved our goal, it was time to start creating our design system which we decided to call ‘Helix’.

Creating Helix Version 1

Version 1 was not about getting something in production, but instead to visually document the outcomes of the previous workshops. Essentially this meant building out our Sketch symbols and housing them somewhere for all to see. We used Abstract for this as it would also allow us to distribute the symbols from a single source and record any conversation around them.

At this point, the system was very light and only made up of fundamental components found in every interface within the company. For instance buttons, typography and field boxes all made the cut, but we weren’t looking at complex components. To get buy-in from everyone, we channeled our efforts on the items relevant to every product team, that wouldn’t require a lot of effort to get in production. Referring back to a complex component such as navigation, this would also require more work to consolidate for every product and we wanted to get something out there quick.

Keen to show progress, our first version was produced on the side by the UX team within two months. Following this, a presentation was delivered to our colleagues to first communicate that we now had somewhere to go in order to get basic questions answered, but also show how the design system was already creating value. Here the UX team demoed the effort we would have to go to in order to create a basic form in Sketch and how long this would now take using Helix version 1. The narrative we reiterated from our first presentation is that the efficiencies would allow us to get something in front of a user faster and by doing so, we would ultimately spend more time focussed on solving problems.

Helix was born!

Screenshot of Helix version one
One of the first versions of Helix showing the elements section.
Helix viewed within Abstract
We used Abstract to store Helix which allowed us to distribute our Sketch symbols from a single source, allow anyone in the company to view what Helix contained and enable transparent conversation to take place.

With Helix being in its early stages and the concept of a design system being new to the company, at this point, I opted to run Helix with a guardian approach. With only a couple of people within UX able to contribute to the system at this point, it ensured we maintained a certain level of quality and consistency whilst others got up to speed.

Guardian model
The guardian approach taken in operating Helix. Only certain people may contribute to it but everyone may use it.

Maturing Helix

At Daniel Wellington, we’re very lucky in that we have developers who actively look to bridge the gap between engineering and design. The conversation is always flowing between the two areas and the respect for one another always present. It is, therefore, no surprise that we ended up receiving a lot of engagement with Helix from the off. It was here, however, that we immediately came across our first challenges as developers started to employ Helix.

Operation

The first area that needed addressing was documentation of feedback in relation to unforeseen edge cases for a developers area (e.g. What happens if the user does X or Y, specific to my product?), or ideas of improvement. A single point of reference was required as currently, this was happening in Abstract, MS Teams or face-to-face. Equally, we wanted a feedback loop so colleagues knew we were actively doing something about it. For this, we decided to create a backlog and kanban board in Jira as this is where developers are active daily and a familiar environment.

Secondly, we needed a method of reaching all developers in one place to discuss these suggestions and also communicate progress on their development. We did this in two ways. Firstly through creating a Helix teams channel for simple items and secondly through piggybacking onto an existing front-end developer lunchtime meetup in which we took larger discussions. We then used these forums to communicate release notes for any update to Helix.

Documentation

In our first launch of Helix, the UX team had created basic documentation of our components with our core developer audience in mind. How an accordion appears when active or inactive, or how a button appears in every state, was clearly displayed. We used terminology developers used themselves and thought we had everything covered.

However, we soon realised that we needed more. Our documentation lacked any form of guidance on which type of component to use in a given scenario and why. This created confusion not only within our development and content teams but even the UX team itself!

To fix this, we began to add developer and designer guidance where needed in order to answer the common questions. Before these were released into the wild, we’d also test the documentation on the audience for which it is intended to ensure it was understandable. We did this through Abstract so the conversation was transparent for anyone to get involved and to allow people to take it in their own time.

Helix button documentation within Abstract
An example of guidance documentation covering how, when and which type of button to use.

Exploring Moving Helix into production

We were now approaching one year since we originally kicked off our design system. Helix was employed in every design and in turn, existed in most of our products. We’d seen successes through the consistency of interfaces across our various products, efficiencies in workflows and usage by teams without design support. We’d even seen areas of past friction with our content and brand teams disappear. For instance, having helped set the typographic styles available within the system, they would only employ these in their designs which in turn reduced the development work required to implement their campaign creatives. Wins all round!

Four products showing the consistency achieved through Helix
Screenshots of four Daniel Wellington products implemented by different product teams, in different locations, highlighting the impact on consistency seen through the adoption of Helix.

The benefits we had hoped to see were evident to all who engaged with Helix but it would always fail to deliver on its true value until we put it into production. This would, as with most design systems, be the area that was most challenging not only in the fact it would cost money, but also in the fact that no one had any real experience. Having only created code based style guides in previous roles, I had never got to this point and neither had the other designers and developers in the company.

Throughout the year, senior management were continually engaged with on the progress of Helix and had seen first hand the difference it was making. One in particular, Daniel Näsmann (Global Development Manager), opened the door in the push for production through an invite to discuss the matter with the development team leads. Through this, we agreed that I would take two half day workshops with the company’s front-end development team, including those based outside our Stockholm HQ, to explore how we could go about converting our components into code.

During the first workshop, we focussed on the basics to achieve an outcome of a foundation to put components into production. It was also decided that at this point we would only offer full support to our products built on React of which most of our proudcts use. Luckily, with the UX team already having done a lot of work on the design system with the developers, it was already very familiar. This allowed us to quickly dive into the focus of the workshop without much groundwork. Due to this, by the end of the second workshop, we had two shared components and styles in production.

Whilst what entered production may not seem like a lot, bigger outcomes had been achieved. We had aligned on a way of working, developed an understanding of the level of effort to produce a reusable component, and it was clear that we had the expertise to deliver our greater desired goal.

Side Project to Product

During the three months that passed between the workshops and the next major milestone, the level of engagement with Helix was everything I’d hoped for. At this point, we were still operating Helix as a side project yet now the front-end developers were starting to really get active with it. Every so often I’d hear “Hey Matt, we added a new component to the Helix library!” which was amazing yet also incredibly terrifying. Amazing as we now had true momentum behind it but terrifying as it was growing faster than myself and the rest of the UX team could keep up with.

Up until now, the design system had only ever had UX driving it as a side project. Whilst we would try to carve out regular time for it, once something got to a ‘good enough’ level, it would always be sidelined if the core workstreams got too hectic. I also noticed that the only reason there were more components being added proactively was that developers were working on them on the side when they had time, or in their own time. Going forward, this would be unsustainable.

It was time to utilise the fruits of the workshops, start the final push to moving Helix into a product and stop treating it as a side project. This was arguably the biggest challenge I faced with Helix to date. Whilst everyone was absolutely clear on the value it brings, up until now, it wasn’t noticeably costing anything. If it were to be treated as a product and still remain without a dedicated team, it would require resources from the existing product teams which in turn could hurt velocity. Support was strong amongst designers, developers and team leads, with senior management happy to go with the consensus, but some work was still required to bring Product Owners on board. To do this I focussed on two areas of direct benefit with one being a current hot topic in the company, accessibility.

Helix was designed from the start with accessibility in mind to the WCAG AA standard. In production, non Helix aligned components did not adhere to this standard both in design and code. Having recently faced legal challenges due to not being compliant, and clear development work required in order to achieve it, this was the perfect opportunity. Adopt Helix and in turn, every one of our products that employed Helix would become compliant.

The second area of focus was that used throughout the journey to date, the expected increase in efficiency. The faster we can get our ideas in front of real customers, the quicker we can learn, drive key metrics they were targeted against and enhance the experience for customers.

Through firstly winning the support and backing from the Product Owner Team Lead, a collective presentation took place, followed by individual fireside chats, which eventually led to the full backing from Product Owners.

Achieving C-Level Buy In

Here I have to admit that I am very lucky to work for a company that was receptive to the idea of creating a design system from day one. That said, moving the system into production would now require significant investment and further justification was required. As my approach was not to pitch for a dedicated team (I’ll come back to this in the next section) but instead look to prioritise development and maintenance of Helix within our existing product teams, this would remove capacity for other work.

In order to achieve buy in I focussed on the following:

  1. Highlighted success stories seen within the company through its current existence.
  2. Illustrated how its adoption (number of components in use) will ultimately contribute to more profit and revenue. This is the key metric stressed that will in turn signify whether we have been successful or not (see image below).
  3. Reiterated the five key benefits a design system brings to an organisation.

During this process, an idea was pitched in order to prove the true in-production value of Helix which was given the green light. This was to run a ‘Helix Week’, in which predominantly front-end developers and UX designers could step away from their respective teams and produce a production-ready Helix 2.0. It was impossible to be able to understand how effective Helix would be in the areas of value communicated without moving it into production. This enabled us to do just that within a short, finite space of time, which was widely agreed upon as a sensible next step.

This part of the journey in creating our design system may seem relatively easy looking in from the outside. Admittedly, yes, it certainly was easier than I imagine most people find this process but there is an important reason as to why. Through taking the bottom-up approach previously mentioned, everyone was already very aware of the support throughout the company which made this step more of a formality.

Image to show the more components used, the more business benefits gained
Measuring the number of components in use was communicated as our key metric of success. Why? The more we reuse components, the more time we have to create and reduce time spent fixing debt. This in turn leads to signigicant operational efficiences that will enable higher revenues and potentially greater profit.

Creating Helix Version 2: Helix Week

Why pitch the idea of a focus week? Other than the aforementioned reasons, it had also been one year since Helix was first introduced as an idea. During this time the level of focus it had received varied from month-to-month as it competed with various other priorities, a result of treating it as a side project and not a product. We also had some people leave us during this journey and new people join. I felt that in order to stamp Helix firmly back on the map and elevate it higher than it had ever been, it needed a reboot. I’m a big believer that creating hype around an initiative is a great way to raise people's curiosity, create FOMO and urge to get involved.

The goals of this week were as follows:

For Helix week to be a success, a substantial amount of planning was going to be required to maximise its success. However, there was one small problem, I didn’t exactly know how we were going to answer most of the problems we faced. What exactly would we build? How would we do a code review? How would our development team in China handle this? To answer these and start hitting home that Helix week was happening, it was time for a formal kick off.

The kick-off involved key stakeholders and representatives from teams including Product Ownership, Team Leadership, Front-end Development, UX and Architecture. The goal was to recap where we were today, share the concept of running a Helix focussed week and together, identify what needed to be done in order to make this happen from all points of view. Through involving representatives from each function within the department, it allowed a sense of shared ownership to be created for the first time. If someone identified a challenge in their area, it would be highly likely that they would know the next step and be able to take lead on it. Equally, it would be more likely that they would be able to own it and thus, create a sense of ownership. Up until now, UX had always been seen as the owner of the design system and this was a great mechanism to start shifting that sentiment.

With multiple challenges identified and accountability on who will own their resolution, we left the workshop with a clear set of actions and a timeline for delivery against them. At this point, it was now 6 weeks until Helix week began and news of what was going to happen was shared with a departmental update. From this point forward we aimed to be even more transparent and open in every action taken, in order to gather as much involvement from colleagues as possible.

To do this we communicated developments in two ways:

  1. An open MS Teams channel in which all conversations regarding Helix week took place. This took advantage of a space where people were already conversing around the design system.
  2. Created a simple, physical kanban board housing every task and lived in the central communal area of the department. This board also served another purpose. By having it open to all and running a weekly standup to discuss progress of tasks, this would ensure people would action what was assigned to them in good time, rather than leaving it to the last minute!
Helix stand up
Weekly Helix stand up in which representatives from all relevant departmental teams huddled around a kanban board to discuss progress of tasks.

Helix Week

In December 2019 and as part of our global monthly meeting, I shared with the department the format of the upcoming Helix focus week, the goals and that I would be getting back up on stage at the very same time the following week to share the results. It was important that everyone not only knew the week was happening but also why the office was going to look a little different when they came to work on Monday morning.

Continuing on the theme of transparency in our approach, a Helix operations hub was created in a communal space on our tech floor. By design, anyone could stop by and see what was happening, ask questions and get involved. The goal of this was to not only create as much opportunity to generate as much interest as possible. Situated close to the coffee machine and entrance, it was impossible to miss it.

In our Helix hub, three mob-programming pods were created in which developers and UX designers worked together to build Helix. What they would work on and how they would work had previously been decided through a series of workshops, prior to the week kicking off. Defining the definition of done, aligning on component naming (see below) and tech refinements, to name just a few, meant that everyone joining on day one knew exactly what they were there to do. There was no ambiguity, just the simple goal of getting 10 prioritised components into a shared repository, with documentation, for use by all product teams.

A helix pod showing UX designers and developers working together
The first of our pods with UX designers and developers working together on a component.
Another helix pod showing developers working together and the kanban board used to transparently track progress.
One of the Helix pods set up in a communal space on our tech floor. The kanban board seen earlier was used throughout to keep progress visible.

The high level of preparation proved to be one of the biggest success factors for Helix week. In just 4 days the component count was at 17 and the week had arguably been of greater success than I could have hoped. In a wrap-up presentation to the entire department, the team shared the success through a walkthrough and demo and let everyone know that Daniel Wellington now had its very own, in production, design system!

Over a year’s worth of work had led to this huge milestone and it’s at this point, I have to give an incredible shout out to everyone who worked on Helix from the original audit, right through to today. Without everyone believing in the value it could bring and providing trust in myself and the team, none of it would have been possible.

Helix Message Box component within Storybook
The end result! A screenshot of Helix showing the message box component documentation page which provides guidance on the four types available. Selecting the 'show message box' button provides an interactive example. We used Storybook, a free, open source tool, to house Helix.
Helix Icons within Storybook
A screenshot of all icons available within Helix within a 'playground'. In this instance, it enables a person to toggle and select 'knobs' in order to view all approved variants in whcih an icon can be used. Every component included in Helix provides this functionality as it is a powerful way to communicate the features of any given component, in addition to documentation.

Component Naming Workshop

A slight side-track here, however, I wanted to briefly expand on this workshop as I thoroughly recommend running one no matter what stage you’re at in your design system journey, if you haven’t done so already. Speaking the same language is just one of many ways a design system aids product development. Agreeing on what we actually see as a component and what that component should be called, ensures everyone is on the page from a fundamental level. Through running a workshop in which, in our case, members from technology, marketing and brand were present, allowed us to set that foundation. The result? Not only alignment across departments that ensures we reference a component in a meeting that is referenced the same in our codebase, but another first-hand experience for everyone involved that enforces the need for a design system.

I’ll be writing an article in due course as to how I ran this workshop that was inspired by an InVision design systems workshop I attended.

One team working together to identify and name components.
The first part of the workshop involves each team identifying what they see as a component and naming them.
All teams coming together to collectively agree on components and their names.
In the second part, all teams come together to discuss what components they've identified and collectively agree on their names. This allows other perspectives to be heard, highlights differences and shows first-hand the importance of aligning.

Operating Helix Post Helix Week

During Helix week, UX designers, product owners, team leads, architects and more, joined in to ensure its success and to also plan for the future. Whilst a focus week proved to be a great way of working in the short term, in the long term, something more sustainable was required.

Collectively we decided to operate a form of federated model in which all product teams took shared ownership of the design system.

Image showing the federated model of operation
The federated approach taken in operating Helix following its move to production. All can contribute and all can benefit.

If a product team is building something that has a component identified that would be of use to other teams now, or in the future, they will add it to Helix as part of their natural product development flow. In theory, each team contributes to Helix as much as they benefit from it. Overall, this sees an increase in efficiency at a departmental level.

As mentioned when looking to gain C-level buy-in, I wasn’t looking to pitch for a dedicated team and instead floated the above model. Whilst many other companies you will read about operate with a dedicated design system team, for Daniel Wellington’s needs today (and in most cases), this would be overkill and an unnecessary expense. It is also for this reason we are not looking to open source Helix at this time, due to the additional workload it creates. Finally, through operating with the model above it means that more people have the opportunity to contribute to Helix which in turn allows its value to spread further and enforce the collective sense of shared ownership. Right now, both of these are the key to ensuring its long-term success.

Whilst for now (Jan 2020) this works well for us, I’ve no doubt we’ll iterate on it and change things in the not too distant future. The Helix journey has been one of taking baby steps and not a sprint. This way of working has led to the success seen so far and one I’d recommend others try to adopt if trying to implement a design system from scratch, in an established environment. As previously stated, for a design system to be truly successful, it needs to enter production and for that to happen, the buy-in is needed at all levels. Due to the level of change brought about through its transformative nature, it is something that will receive less resistance and ultimately more adoption, if people are given the time to experience the positive effects it can bring first-hand.

Final Words

For the next few months, the focus will be on getting components into production, iterating on our storybook documentation and documenting successes to share back with the business. I'll update this article as further progress and development is made with Helix.

I hope this article provides a deep insight into how I went about creating a design system at Daniel Wellington. I’ll be updating this page as more progress is made but if you have any questions in the meantime, I’d be happy to answer them! Please reach out to me via email or Twitter.

Next project Speed & Performance Optimisation arrow right icon