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 enhances hotel-guest journeys and needed a total redesign of their product. They sell software to hotels, who can build custom web-apps (known as “Digital Guestbooks”) for their guests. The old design was focused on desktop, but it was clear that hotel guests only viewed the ‘Guestbook’ on their phones; so I pushed for a new version of the product focused on mobile. The challenge was to constrain the hotels in a way that the app always looks nice, while still giving them freedom to customise.
The outcome is a (desktop) editor for hotels – in which they can build a customized web-app (mobile) for their guests. Every hotel can make a custom looking app that fits their own visual style. Another outcome is a design system that aligns the visual consistency and improves development efficiency of new features.
This is the desktop editor in which hotels can build their own app for their guests. We call it a ‘digital guestbook’, but as you can see in the following designs, it can do much more than just a guestbook…
.png)
.png)
On the left you can find the old design when I started working at DigitalGuest. After a few months of setting up a design systems and applying it to the old design, you can see the outcomes of the new design on the right.
One of the features that Hotels can offer, is a voucher for their guests. They can specify what the voucher contains and how it looks. Guests can redeem the voucher by swiping it in front of bar of restaurant personnel.
Another feature is ‘digital room-service’, which allows guests to order whatever they like from their phone. Think about lunch being ready in your room right before you arrive, or a late-night snack when you are too tired to go to a store.
In the guestbook, guests can find all the information from the hotel, like check-out times, information about the area, events etc.
Many hotels have beautiful interior or nature around they want to show in their app. With carousels, they can show any kind of image that fits their visual brand and style.
Another feature is the quick navigation, which allows guests to quickly access certain handy features; like calling the taxi service or checking the weather on the location of the hotel.
To show all these features in the highest level of fidelity, several clickable prototypes were made that helped in communicating the features to stakeholders and developers.
My role in this design process was the UX/UI designer. I led the design, from structuring the information architecture, improving the user flow to the final user interface design. Below is an overview of the steps that I was responsible for in the process; after that, the developers took over to realize the designs in code.
The project consisted of two different software: a desktop ‘Editor’ for hotels, in which they can make a mobile ‘Guestbook’ for their guests. Both the hotels and guests have different jobs to be done, needs and goals that need to be taken into consideration.
After scoping the project, I often start with a Customer Journey to understand the chronological steps a user might go through. Starting like this helps to empathize with the user and staying focused on their needs. This customer journey is zoomed-in on the phase where a hotel starts with ‘building’ – part of making a guestbook. The initial payment and sign-up are already handled beforehand.
Making a sitemap with the different screens and menu items helps to understand the flow of the application. It also helps to check if the hierarchy of the menu items makes sense, if the features are grouped properly and are easy to navigate through.
Drafting a UX Flow helps to show the different states of certain features and different routes a user can take to go through the application.
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
After receiving the task to design a new feature, I came to the conclusion that there was no space in the current product for integrating new features. The navigation was full and the screens were crowded already, so it seemed clear that a new overhaul was needed in order to prepare the product for additional features in future.
The development process was not defined
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.
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.
As we just finished a design system, there was no benefit to start designing with wireframes; it would take more time to start with wireframes and converting them to real UI components than just starting with the UI components immediately.
The old design was made for guests to view on a desktop, while the new design should be mainly for mobile. In this stage, the challenge was to design for mobile-first, while also keeping a relatively good view experience for desktop.
The existing design system was built for the hotel’s ‘desktop editor’, so the design system needed to be tweaked to be usable on mobile devices as well. This led to a ‘sub – design system’ for the mobile-first guest’s app.
It was difficult to get feedback from our customers as they are often big hotel chains. Therefore, we used a user testing tool called Maze to build different user tests that helped to get quick feedback from our internal team of 13 people. Although this is not an ideal situation, as we would prefer to get feedback from our actual users, this feedback did help to test the usability of the new features to a certain extend.
To communicate the final designs with stakeholders and developers, several interactive prototypes were built in Figma. This helped to communicate the flow of several features and the micro-interactions that are not visible in static designs exports.
Although a developer was present in a weekly update meeting to discuss the technical validity of the designs, I left extensive developer notes to help him during the development process. Each component contained each own “Devnote”, with a description of the design.
A selection of Service Design, UX and UI projects.
