As a part of the new digitalization strategy, the existing online booking system will be redone from scratch. It needs to be seamlessly integrated into the IT landscape that is currently being newly built.

Given the challenges of a low conversion rate, outdated technology stack, lack of a mobile version, and generally a look & feel that does not reflect the brand values, the decision to develop a new online booking system has been made.

Our objective is to develop a booking platform that prioritizes user-flow optimization to deliver a streamlined and intuitive experience, where the demographics of the users are defined as the customers booking a tour but also the clients internal staff having touch-points with the booking system. An effective discovery phase will lay the foundation to define vision, scope, and timeline for the project.

In a collaborative effort with the client, I conducted a comprehensive analysis and documentation of the existing application's functionality. The aim was to identify the major pain points users experience during and after the current online booking, as well as to explore the potential opportunities that a new system could offer. These findings were then evaluated based on their ability to enhance the user experience, streamline internal processes, as well as their technical complexity and business implications. This data-driven approach enabled us to establish a clear strategy, priority task list, and scope for the project that is also technically feasible given the time frame.

To support the developing of a solid strategy, vision, and eventual scope of the project, I introduced a ranking chart with all functionalities and support tasks according to their user- and business-value, as well as their technical complexity.

Visualising data and finding is a crucial tool to assure that all stakeholders are aligned. A graphic that was essential in developing a strategy was the comparison of business value versus technical complexity.

Due to the nature of group travel with individualistic choices, the amount of information that needs to be processed is high. The chosen information architecture and flow balances guiding the users and leaving enough freedom to not patronize them.

To provide the user with all the necessary information and choices at the right time without overwhelming them, a pattern has been chosen where the main flow of the booking provides the user only with the most necessary information in a summarised form, while providing all information and choices in the corresponding sub-pages and flows.

The main flow has been separated in 3 + 1 overview sections, while the first three are needed for the booking and the last section is the summary of a completed booking including steps such as travel preparations, contacts, etc.

My preferred method to explore the design space is to create various pen & paper wireframes, a mood board and reference ideas from competitors, innovators etc. Due to copyright, I did not include the mood board and reference sheet.
It is important to keep the client up-to-date and have regular meetings for exchanges, alignments, and technical feasibility assurance. Therefore, a weekly meeting with the PO team and on-demand meetings with the senior software architect have been set up to discuss the direction, possible approaches, solutions, and visual designs. These meetings have been crucial to also keep the project on track and plan for upcoming tasks for the PO tea, developers, and designer.

Two distinct user tests have been conducted to verify the design choices as well as improve the overall usability of the application.
Both usability tests have been conducted as moderated in-person tests at the clients' location, with the first test prototype running on an iPhone which screen has been recorded. Recording only the voice of the participant was a situational choice. In-person testing gave us various benefits, of which one was the possibility to observe and analyse their true reactions to the tasks given in real time.
The analysis of the first test showed that the concept and UI of the mobile version works well, whereupon we decided for the second test to focus on the desktop application, which will include the improvements from the first test.
The participants were organized by the client and chosen according to the defined demographics from the marketing team, from which we gratefully received valuable insight.

One of the challenges was to create a component system that could be used across multiple applications that are in use or being built. Significant effort has been put into aligning the various projects to have a shared component library for development and design, while introducing a single point of truth for the component styles. To achieve this, we revised the current Tokens Studio for Figma concept to support multi-project, multi-brand development and also introduced Storybook for its multitude of benefits.

The booking system is being developed as a standalone React web application, seamlessly integrated into the client’s modernised systems. We placed significant emphasis on building on top of the existing Figma and React component library to increase development velocity and keep a consistent design throughout their various applications. Due to the time constraints in development, the components have been built with a mobile first concept, while still being 1:1 reusable in the desktop application with only the interaction being adapted to desktop specific input.

The team sets strongly on a single source of truth for the design, which can easily be adapted to possible changes. Therefore, Tokens Studio for Figma has been introduced into the development cycle and its concept revised for the new project. The tokens, which at its core is a collection of tokens in JSON format, are stored and versioned in GitLab.
In Figma, we created a token for every local style (colour, paddings, border radius, typography, etc.) that is directly linked to the main Figma components which update their instances through Figma's native functions.
On the development side, the JSON from GitLab is converted into front-end usable JSON. As example, PX are converted to REM, font-weights to numbers, etc. Development is not using the defined tokens directly, but a pre-built composition per component that aligns in structure with the React-component built by the developers. The creation of those pre-built token compositions happen in collaboration between development and design.

To speed up development and increase the chances of releasing version 1.0 before the high season of travel bookings, the desktop version was designed with a focus on reusing the mobile components as much as possible, balancing usability and success of finishing development in time.

Information has been grouped to the natural flow of booking a tour. However, as information visibility is limited on mobile, the grouping is more fine granular than on desktop.

Similar to a mobile settings menu, selecting values happens on a subpage. The deepest level from the main page is set to a maximum of two to avoid customers getting lost.

The second main step in the booking process is being informed about all the legalities and having to accept them before being able to proceed.

The last step of the booking process is one of the most important. It needs to summarise all the previous information, give the customer the possibility to easily edit possible mistakes, and provide the customer with enough confidence and focus to submit the booking.
All the editable sections correspond to the previous subpages, which can be reused in this section.

Upon finishing the booking, the customer is presented with all the necessary information, as well as the three most important ways, as defined through research, forward to continue their journey.

Due to the demographics, instead of showing any error code, a text with an apology for any inconvenience is presented, as well as the direct lines to the service centre, which can either confirm, finish, or in the worst case redo the booking manually. If the error happens outside the service times, which is very likely, further possible contact possibilities are presented.

Having engineers involved in the early stages of any project is crucial, yet even more so when it is being built on legacy systems. User flows that would work well for green field projects might technically not be feasible on legacy systems, even with abstractions. It is important to find a balance between being user-centred, technical feasible, and having actual business value. An important part of a product designer's job is to ensure that all involved parties are included in the process and understand the concept & requirements of what is being built.

Customer facing departments, like service centres, can be a treasure trove during the discovery phase, from user insights to analysing internal processes and bottlenecks. Quite often, employees developed their own processes or found workarounds to be more efficient and effective. Gathering and analysing those inputs carries substantial business value, and also increases the satisfaction among employees for being heard and having their part in a product they're heavily involved with.