Problem

Desired outcome

The ultimate outcome for these projects is always two-fold. And I will always be the first one to admit that I have only been able to achieve it to a degree. The product must increase consistency across the experience of the user. And it must be able to be open enough for developers, designers, copywriters, and product owners to use, edit, and enrich.

Audience

For who are we building this?

The audience of this product is ultimately the customer. More consistency means less cognitive demands for our users. But the real users of this product will ultimately be front-end developers, product owners, copywriters, and designers.

Roles and responsibilities

My responsibilities

I had a diverse array of responsibilities. Because of the lack of a product owner, I would be tasked to write many of the tickets about the necessary improvements/editions of particular components in the design library. Occasionally the tickets would consist of larger initiatives like making design tokens (such as colours and fonts) WCAG 3 accessible. 

Aside from ticketing, I was also responsible for the following tasks:

1. Building components in whichever design tool (Sketch/Figma)
2. Researching about tooling integration with developers 
3. Organizing and publishing the library of components (Zeplin + Git)
4. Drafting and agreeing on guidelines for component creation

Scope and constraints

Limitations

Most of the improvements did not require an A/B test. They were mostly meant to eliminate unjustified inconsistencies (variations not supported by data). Or bring well-documented accessibility guidelines from institutions like W3C. In the rare occasion that an A/B test was required, this would usually be brought down to the individual teams so the change would have the backing of both a data scientist and a product owner.

Process

Step by step description

1. Component mapping

The first step to all this was to map what we currently have on the product. Colours, text fields, font families, sliders, toggles, sliders, popups, buttons, split buttons, galleries, etc. along with their variations. Making a preliminary list with visual examples was necessary to engage with stakeholders.

2. Allocating time and resources

After managing to compose a preliminary list. Together with a lead developer, I worked on making a presentation with key stakeholders in the company. The people who often complained that the product did not look alike in different parts of the experience were key to make this initiative a reality. When one can observe the problem one can think about possible solutions.

3. Composing the team

The lead developer and I worked on making a temporary team of developers and designers of each team. This was key to ensure that the project would be adopted by all the development teams in the company and hopefully become standard practice.

4. Selecting tools and infrastructure

We already had a pretty good idea of what tools we had from the design side. Generally, it came to two choices for creation (Sketch vs Figma) and two choices for publishing and administration (InVision vs Zeplin). In Maersk InVision was already licensed, and it was in wide use. In Findhotel Zeplin had widespread adoption, so it only made sense to use what was already available. In both cases, both companies counted with Sketch licenses.

From the development side; we wanted to have a work process that would be as automated as possible in the case of Findhotel.

6. Publishing

I’ve had mixed experiences with the publishing portion of the project. In the past, with InVision I would be able to target designers and their use of the style guide. But the results were not as satisfactory as I would like them to be. I believe that design always translates into code, so having a separate development silo, and a design silo leads to inconsistencies. For this reason, I have pursued a more direct approach with developers, to integrate elements 1:1 between Zeplin and whatever development publishing tool is on the other side (e.g. Storybook). This has achieved better results, and it follows a principle that has helped tremendously “Aim for a single source of truth”.
It is of little use to make a style guide if it will be looked at once and then forgotten. Designers and developers will keep iterating and making something new. So the system should enable a work process that encourages the improvement of the existing over making something new. This premise has been central to convince an array of stakeholders in the organization that this is a worthy investment.

7. Testing

After developers have implemented an unreleased version of the solution. I would often manually test the user scenarios that we agreed to be in a sprint. The scenario mapping and the scoping diagrams served well in this step to make sure that all scenarios are properly tested. Apart from the scenarios our team actively tested for the following criteria (when applicable).

• Device: Mobile vs Tablet vs Desktop
• Browsers: Chrome vs Safari vs Firefox vs Edge
• Stay length: Single night vs Multiple nights
• Room configuration: One room vs Multiple rooms
• Signed status: User signed in vs Not signed in
• Private deals: Room with private deals vs No private deals vs Mixed
• Availability: Available vs Sold out vs Price mismatch
• Tax display logic: No taxes included (US) vs Taxes included (NL)
• Price payment breakdown: Prices with pay at property taxes/fees vs Pay now only prices
• Price currency conversion: Provider currency converted prices vs Unconverted currency prices
• Language-based UI issues: English vs German (longer words)

8. Probing after release

This step is meant mainly to check how users interact with the solution in production. For this step, I made extensive use of FullStory. FullStory is a comprehensive tool that allows me to see the real user interactions on the website as well as segment users by particular actions or demographics.

If I detected an issue, bug or idea for the future, I would document it. Occasionally bugs slip away, as well as strange interface manifestations in specific browsers. This was a very useful tool to spot the issue, and then document it for further work.

Conclussion

Results

Today the design system lives as a library that is directly used in all the products in the portfolio of Findhotel. It has not (in my opinion) achieved the style guide status, because it is mainly a library of components. But it is well on its path to becoming one as we invest more time into it. This is in contrast with what I managed to achieve in Maersk or Coolblue where the style guide is mainly targeted to designers and had little to no developer involvement. The products in both cases remain at the expense of the individual designers in the team. It is up to the designer in a team to use and evolve the components, and apply them well. Unfortunately, this is too much responsibility, and engagement with front-end developers is key.
The design system in FindHotel has already been used to make a mass update in all of our products to bring colour accessibility to our customers according to W3C. Aside from that, we have managed to standardize dozens of components, and eliminate duplicates. Unfortunately, we have not collected data on the speed of development, but it is our aim to back up the design system efforts with actual data for the business part of the organization.

Example of pages created with the Findhotel’s design system

Search page (mobile)

Confirmation email 

Room selection page when a hotel is sold out

Example of pages created with the Floorplanner’s design system

Profile editor for pro users

Marketing page that displays the main features of each plan