Helix Design System

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:

• Increased efficiency
• Better cross team collaboration
• Reduced onboarding time
• Aids innovation
• Profile raiser for the company

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

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!

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 MS 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.

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!

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.

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:

• Re-engage and focus the business around Helix.
• Produce the components required to build the foundation of the majority of our interfaces.
• Create an openly accessible space in which components and documentation can be accessed and interacted with.
• Define our way of working during and post Helix week.
• Remove the perceived ownership from UX and distribute accountability across the department.

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 the 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 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.

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.

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.

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.