4 Steps in our Design System Journey

How we transitioned from working on separate style guides to a unified Design System creating alignment between design and development.

Now that 2020 is here, it’s a great time to look back and recall the journey we took in setting up a Design System that spanned most of 2019 for de Bijenkorf digital e-commerce. But before I describe our 2019, it’s interesting to understand where we were before the year began.

Gaining management buy-in

Before 2019 even began, designers and developers before us had already made a start in setting up the tools each team needed to work in an agile company with multiple scrum teams. It was clear that a lot of effort had already been made so that work could flow with so many people involved.

Designers had some simple UI components (like buttons, links, and icons) in a shared Sketch style guide library that could be version controlled in Abstract but it wasn’t regularly updated by designers so it quickly became out of date. New designers would typically create their designs using the live website as a starting point and then handing over to development using tools like Marvel, thus lacking a way of aligning consistency in design across the scrum teams. Here’s an idea of what this Sketch file included:

A snapshot of the designer style guide in Sketch.

Developers had a shared CSS framework called “core-assets” and even took it a step further with an online style guide where they shared code and documentation on how to develop components. This online style guide was a developer led initiative created as a means to aggregate and document existing components. Developers created the guide hoping to collaborate with designers on this shared source of truth. In theory, an excellent idea and sounds a lot like a “Design System”, but in practice, it was difficult for designers to access for editing purposes which resulted in limited adoption.

Here’s an idea of what it looked like:

A snapshot of the developer style guide.

It felt like we had an excellent foundation but after various designers and various redesigns across multiple scrum teams, our website began showing classic symptoms of being designed by more than 5 designers: inconsistent design.

This is where our request began when approaching management to get time to work on a Design System. The strongest illustration we had showing inconsistencies was the 4 different versions of product details that a customer might see when shopping:

Inconsistent product details in the wishlist, mini basket, basket, and order summary.

With this example of an inconsistent experience we provided for our customers, it was a slam dunk in getting management (and the teams) on board with the idea to spend time working on the Design System “again”. The fact that we had worked hard on all the tools already in place, didn’t mean that we would scrap all of the work, but something was missing that allowed our teams to collaborate efficiently.

After winning management approval, the work began, so flash forward to the start of 2019.

Steps we followed

We knew we had a problem and we now had time to solve it. What a great start to 2019! We got started right away in setting up a Design System team that consisted of members from each of our scrum teams, both designers and developers, making it efficient that every team was represented and decisions could be communicated immediately. We were then able to get started with the goal of improving the tools and creating synergy between our teams.

Step 1: Atomic structure and UI Audit

We decided it would be best to hop onto the atomic design bandwagon as it translated well from design to development. First step was to translate what we already had into the new atomic structure. This required multiple alignment sessions between developers and designers to guarantee consistent naming conventions of already existing components in our two tool kits: the Sketch UI library and the online style guide.

It was at this time that we began taking an inventory of typography, colors, and various UI components (especially any instance of a “product”) already in use on the website. This was basically a mini audit of key UI components so that we could begin redefining these elements as a working start to the project, already making small wins cleaning up some inconsistency.

Example collection of inventories designers had completed.

While designers were busy doing their homework, developers were able to get started on cleaning up duplication of code and components. We also began documenting and prioritising any design inconsistencies together. As we knew that the product detail was our “hero” component, developers could also get started implementing one reusable component. Reuse and share stuff — this was our new mentality.

Step 2: Explore and test other tools

We started the exploration process first by creating a list of what we needed in any new tool, keeping in mind that we didn’t want to deviate too much from our current tools if possible (unless of course something amazing came along).

Our tool “must haves” included:

  • Code view needs to be easily accessible and visible
  • Documentation tools
  • Versioning possibilities
  • Design tool needs to work with web, android, iOS
  • Plugs into Sketch (or imports/exports from Sketch)

Nice to haves:

  • Easily shareable / publishable
  • Works with tools we have now (react, storybook, sketch, abstract, marvel, etc)
  • …and a holy grail of nice to have: design able to directly sync with development so changes are live immediately (at least in CSS)

With our list in hand, we went through researching and testing various tools to help sync design with development. Some of the tools we explored included: Airbnb “painting with code” Sketch plugin, Figma, Invision DSM, Frontify, and Zeroheight.

In the end, we decided to go with Zeroheight as it worked seamlessly with the tools we had already set up, fulfilled the above requirements, and required little extra investment of time. So we had our tool, time to get rolling.

Step 3: Begin building our Design System with 1 test “product”

We decided to test our new tool in the best way possible: by using it! And of course, the best initial proof of concept was no other than our initial design challenge that led us here in the first place: product detail.

We began by creating new assets in our Sketch library, merging the various designs into various stages of the purchase customer journey while creating consistent atomic elements. We ended up with “Before Purchase”, “Basket”, and “After Purchase” designs of the product detail.

Our new product detail in our Sketch library.

With the assets now available in our Sketch library, the final step was to simply upload the designs to Zeroheight with additional usage guidelines for designers and developers.

Three states of a product detail: before, during (basket), and after purchase documented in Zeroheight.

Once the designs were in Zeroheight, developers could begin using these new definitions in order to align into one product detail with simply different states.

The next step was to continue with the rest of the product detail views we had discovered and document these as well using the same atomic elements.

The various other states of product detail documented in Zeroheight.

The final part of this step was for development to include storybook links to live components in Zeroheight thus making it the single source of truth for our two teams. Sounds pretty nifty, right? It definitely is, but I won’t go into too much detail here about how this source of truth functions as I’m saving that for another post.

Step 4: Share and iterate.

This last step is where we are today. With the tools in place, it’s now up to our teams to continue making the Design System part of their process. This may end up actually being the most difficult and challenging step in setting up our Design System but I have faith in our teams to adapt and iterate where needed. We never consider the project fully “done” as we work to implement changes based on actual usage and feedback so that the tool isn’t something created by one team but a shared system owned by everyone.

The future looks bright

Even though we accomplished a lot in setting up a new process and tools in 2019, we are not done and continue to meet regularly in order to maintain consistent alignment between our teams. With the new mindset of “reuse and share” firmly part of our culture and way of working, it’s now up to each team to ensure that the Design System continues to be part of the workflow. We are looking forward to an exciting year as we watch our Design System evolve and begin producing value for our teams.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store