I helped a booming startup in the hotel industry switch to a mobile-first approach of their product. Check how hotels can make custom mobile apps for their guests.
DigitalGuest helps hotels in delivering the best experiences for their guests. The product they build is an evolving platform that incorporates feedback and new requests of hotels. This rapid development has led to a crowded user interface and fragmented look and feel. During the design of my first new feature, I realized that establishing a design system would speed up the design + development process, while also keeping a more consistent user experience.
I initiated this project by myself and throughout several meetings to get others on-board, the goal to establish a rigid design system was set. After a few months of design and alignment meetings with development, our own design system was a fact.
Below you can see the looks of the old design, before the new design system was in place. Under that you can find a comparison of the two versions.
My role in this design process was of the facilitator of the process and designer of the design system itself. Below circles represent the time and energy spend in the ‘Planning’, ‘Building’ and ‘Implementing’ phases.
A design system is a solution, but what was the problem that sparked the initial thoughts around establishing a design system?
The design looked outdated and consisted of different “versions”
Being a new designer in the company, gave me the opportunity to look at the current product with fresh eyes. This helped to identify that several “versions” of designs were used throughout the project; some older ones, some newer ones, which resulted in a fragmented experience.
There was no space for new features
While starting designing on a few projects, I noticed there was no clear design + development process in place yet. There was no library existing in both Figma + code, where designers and development could take components from, and no clear process in turning finished designs into code.
The development process was not defined
While starting designing on a few projects, I noticed there was no clear design + development process in place yet. There was no library existing in both Figma + code, where designers and development could take components from, and no clear process in turning finished designs into code.
After researching the area of design systems, having internal discussions and looking at how other designers handled design alignment in their companies, we concluded that handling our design more systematically would be the way forward. The benefits of this approach were:
A Design System enables a more aligned experience
Building all the future features from a constrained set of components and restyling old features using these same components result in a fully aligned product; all the screens look consistent and there’s no “Design Debt” (Brad Frost coined this term, pointing towards different ‘versions’ of designs throughout time).
A Design System decreases the time to build new features
Of course, it takes time and resources to set up such a system, but having a component library living in code drastically reduces time to prototype and crank out new features. In the future, we know that all the components have been tested rigorously so simply said, designing and developing will be a matter of putting these together in a new order.
A Design System allows for gradually restyling the UI over time
One of the problems we try to tackle is “Design Debt”, having multiple outdated versions of designs in the same product. Having a Design System in place enables us to ‘tweak’ the designs on the go, which will impact all the components across all screens. If our rounded buttons get out of fashion, we simply make them rectangular in Figma + Code and all the buttons throughout the product will be adjusted accordingly. These simple tweaks prevent that a certain feature becomes outdated, as the whole product is built using the same system.
The most important step prior to building the Design System is to get other stakeholders on board, like the development team and upper management. With quite some new features in the pipeline that have a seemingly bigger impact on our value proposition, we needed a strong argumentation for why a Design System should skip the queue. This ‘stakeholdering’ happened throughout several discussions, with above argumentation as a red treat.
The following step was to define whether we should design and code a new system from scratch, or if we should ‘build on the shoulders of giants’; meaning to start with an existing system and tweak it to make it our own. Although we found some reasons to start from zero, the arguments for tweaking an existing system overshadowed them in our case:
The first step of the building phase was to decide which existing system to build further on. After researching large and small existing systems, our choice was to go for Ant Design by Alibaba. This system has many pre-built components in the front-end Javascript framework Vue.js that we could use, including the possibility to tweak them to align them visually with our brand. Reasons for choosing Ant was the great documentation and adaptability of the system. Also, this system didn’t have such a strong visual style, like Google’s Material Design, so it would be easier to differentiate ourselves visually.
The following step in building the system was defining which “ingredients” it should contain and how they are structured. In short, a system comprises of standards and components. A well-known structure we adopted is ‘Atomic Design’, in which the smallest and most basic components are called the ‘Atoms’; the building blocks of the system. Putting the Atoms together and you get molecules, and so the composition of different components increases in complexity. Atomic Design would help us shift the paradigm from thinking in “pages” to a system of inter-dependent components.
As base elements, we defined the rules for Typography, Colors, Margins, Shadows, Border-Radius an Icons. Some of these elements came from the existing design we had, others were tweaked as this seemed the perfect moment to refresh the design.
After the base elements, I designed the ‘Atoms’, which are the smallest components such as buttons, checkboxes, labels and switches. The second step was combining these elements into ‘Molecules’, which are the input fields, tooltips, breadcrumbs etc. Putting a few Molecules together, and you get the third step; ‘Organisms’, which can be a date-picker or menu-bar for example. The fourth step is making ‘Templates’, which form the structure of a page without the real content. Only in the fifth step, the “Pages” come to live, which are the actual interfaces a user sees, with real content.
As the Design System should be used by the entire design and development team, clear documentation is required to make sure everybody knows how to use it properly. For all the base components, a clear description was written and checked with other designers and developers to make sure everybody is aligned on how to use them.
Such Figma file looks nice, but a Design System only comes to life when applied to a real project and transformed into code. The first feature I designed for the company was a ‘NPS Feedback’- feature, so I used the newly designed System to test it. Applying all the buttons and inputs to the first test showed that certain aspects, such as margins, corner-radius, and colours needed to be tweaked until it started to work across different pages. This tweaking of the Design System was an ongoing task, that we still do to this day; it should be seen as a living document that’s constantly evolving and improving over time.
The transition from a Figma file to code is the last step in the process of building a Design System. Here my responsibilities faded away and the front-end developers took over to code the components. Several meetings were needed to adjust the Figma designs, as certain design choices were not technically feasible within code. An example was the colour-picker I designed, which went beyond the capabilities of the package we used, so that needed to be adjusted. This tweaking and adapting lead to the final implementation of the Design System.
The new Design System is now being used in all the new features we build and also to restyle older features. It changed our workflow of both design and development. From a design perspective, it helps to speed up the process of developing new features a lot; because all the components are in place and part of the new workflow, I completely skip the wireframing stage. This is simply not needed anymore and would only slow the process down. Now I prototype using real components resulting in quicker and higher fidelity prototypes.
From a development perspective, it changed the workflow as there is more alignment of the components. Also, there are less design/development alignment meetings needed, as we know that the components in the System are tested, approved and agreed upon.
A selection of Service Design, UX and UI projects.
