TrustYou Guest Experience Platform

Unifying a suite of products as one holistic platform

When digital products evolve organically without adhering to any information architecture guidelines their structure slowly degrades, as findability and navigation are compromised, slowly making them less of a holistic product and more of a collection of features. The later this is addressed the more difficult it is to fix, but luckily in the case of TrustYou’s products we eventually did recognize this issue and tackled it in a massive cross-team project that resulted in the industry’s first guest experience platform.


One of my first goals as a designer at TrustYou was to get a grasp on the state of our interfaces with the intention of modernizing and ultimately improving their consistency for the long term.

Original design: Many things could be and will be done better

At first I mostly focused on standardizing the visual and interaction design of smaller components, gradually working my way to more complex issues of layout and navigation by tidying up the main navigational blocks such as the tabs and navbar.

Tabs: First redesign with a more modern style

Because our interface was built on a non-fluid 960px grid, this left a reasonable amount of lateral space, so a couple of years later I began exploring ways to optimize the use of screen real estate by switching from horizontal tabs to a fixed vertical sidebar.

Sidebar: Making use of horizontal space with a vertical navigation

Not only did this sticky sidebar effectively improve navigation, but around the same time our company had also acquired the Checkmate messaging app which was already using a similar type of sidebar, making it the ideal time to unify the two under one design.

Checkmate: Very similar to our own vertical navigation

This didn’t come without challenges though, such as having to resolve two different inboxes—one for reviews, one for messages—or having to merge settings and other shared features. Figuring this out was no easy feat, especially because of all the technical implications, which is why I spent quite a bit of time whiteboarding solutions together with product and engineering.

Whiteboard sessions: Untangling dependencies for full a product unification

Despite our best efforts to restructure and reorganize everything at the time, the technical costs of a full merger were just too high and so we settled for only visually unifying the navigation, leaving the products otherwise separate but still switchable via a navbar dropdown.

Product switcher: Accessing alternative products via a dropdown

Even though this may have been a working solution, the usability was far from optimal and the experience felt jagged and disjointed. With different code bases and tech stacks, the two interfaces were still noticeably inconsistent under the surface.

Discrepancies: Almost the same but still very disjointed and jagged

Since we still couldn’t truly unify our products at a deeper (technical) level, we settled for reorganizing pages into modules which I then designed as collapsible menu items in the sidebar.

Product modules: Grouping pages based on product bundles

This design went live and was operational for many years until eventually our growing product suite just wasn’t fitting in with the existing structure anymore. Soon enough we found ourselves revisiting the topic of information architecture and navigation redesign, but this time with a clear intention of addressing the problem right at its core.

Objectives & key results

Around that time my team and I were also in the middle of establishing a new design system, so it was a good opportunity to address these topics of navigation as well. At the same time I didn’t want us to get sidetracked either, so in order to maintain a clear focus for my team I included the navigation redesign in our objectives and key results (OKRs) for the following quarter.

OKR: Design goal for Q3 with measurable milestones

Being intimately familiar with our products and the early decisions that went into our navigation, I took lead on this initiative and teamed up with product managers and engineering leadership, and started defining a plan for how to restructure and redesign our platform.

Information architecture

Before any design or development could happen I first made an inventory of all our content pages and documented them as an extensive sitemap on Confluence. This was then used to identify duplicated pages that could be merged vs other pages that had to be reorganized.

“Simplicity is complexity resolved.”

Constantin Brâncuși

To maintain transparency and keep a record of our decisions I also created several DACI pages in Confluence where all our work and findings could be documented, one for each important topic such as copywriting, visual design or settings merge.

Naming principles

As trivial as naming may seem, UX copy can either make or break a design. That’s why I defined these four guiding principles to help us write new copy for our menu items:

  • Reduce complexity. Use simple words that are as easy to understand and remember.
  • Keep it short. Try to use single word names whenever possible, except for compound words.
  • Stay consistent. Sections should be based on either verbs or nouns, ideally not a mix.
  • Avoid product names. We want to focus on solutions and actions, not product marketing.

Restructuring menus

To simplify things even further, we also decided to move away from collapsible modules in favor of a cleaner single-level (i.e. flat) structure. We still wanted to divide the menu up into labeled sections, but this way all items would still remain clickable at any given time.

Flat structure ideation: Exploring the idea of a flat menu structure

Working together with the product and marketing teams, we came up with two copy proposals, each of which was based on either verbs (as actions) or nouns (as topics). The next steps were to test these proposals to see which was more effective when users had to navigate their way around our platform.

Jobs to be done

To create a realistic test, I asked our product managers to identify the three most important jobs to be done (JTBD) that users were performing with their products, which I then aggregated into a shortlist of tasks and questions:

  1. You are curious what guests are writing online about your hotel’s new hygiene policies. Where would you click to find this information?
  2. Your guests are sending you questions and special requests for their room. Where would you click to see what they are asking?
  3. You want to start using WhatsApp to listen to guest requests. Where would you click to set this up?
  4. You now have contactless check-in and want to tell your guests before their arrival. Where would you click to broadcast a message to your guests?
  5. You want to ask guests about their experience at your hotel, so you decide to send them a survey. Where would you click to create this survey?
  6. You wonder how well your hotel is performing compared to other hotels from the same chain. Where would you click to check these stats?

It was important that questions were phrased in such a way that they weren’t using any copy from the UI, because these would then be used in a findability test to see if people knew where to click in order to perform each of the tasks.

Findability test

It’s important to note that at this stage we only wanted to test the efficacy of the copy and not that of the visual design, so I created a couple of oversimplified mockups that were similar to our existing UI except for the new flat menu structure.

Verbs vs nouns: Candidates for the copywriting findability test

The test was then set up as a two-variant first click test in UsabilityHub where **each participant was shown, at random, a mockup with one of the two menu proposals.

Findability test results: Two variations with an even split of test users

We had a total of 179 participants, out of which 20 were recruited anonymously via UsabilityHub, while the other 159 were existing TrustYou customers recruited from our web app via Userlane.

Interpreting the results

For each of the questions we got a heatmap overlayed on top of the mockup showing where users clicked when prompted. By analyzing the click distribution and heat maps, we were able to tell which was the most clicked menu item in each scenario, and how big of a difference there was between different menu items.

Heat map results: Interaction areas sorted by amount of clicks

If the difference was significant enough then the text was a good candidate (highlighted below in green), but if differences between multiple items were negligible, then chances were that the copy was still too confusing for that particular scenario (highlighted in yellow).

It’s worth noting that many clicks were also made randomly on the rest of the page (i.e. outside the sidebar), averaging at ~18% non-usable answers per question. This meant that after we discarded that as noise then the amount of clicks on actual menu items was in fact higher percetage-wise. Since the difference between the most clicked items still remained linear, we continued to compare data with the noise included, as provided by UsabilityHub.

Result breakdown: Interpreting test results for each version of the copy

Apart from this quantitative data we also had an open ended question at the end of the test to collect qualitative feedback from participants. By using all these findings we were able to write up a final noun-based proposal which could already be plugged into the visual design.

Visual design

To stay on track with the project timeline, both visual design and copywriting were done in parallel. This way by the time we had the final copy I would already be finished with the design itself and could just bring it all together.

Early ideas

Sometimes we get so caught up in the status quo that it’s difficult to even think outside the proverbial box anymore. We get conditioned by what we already know and rarely even consider radical alternatives. That’s why at some point during this project I tried nudging myself into an entirely different design direction just to reframe the problem and to gain new perspectives.

Topbar alternative: Experimenting with some less-conventional designs

Instead of the vertical sidebar I explored an alternative design that was more focused on content, with a less prominent navigation. Menu items were turned into topbar dropdowns, and breadcrumbs were added for extra navigation support.

The assumption was that once users got to a page they could focus on the task at hand (i.e. JTBD) and not on the navigation. The thing is that as good as it might’ve felt to look at a completely fresh design, this one didn’t solve the problems of actually getting to said page.

Design variations

After a few iterations and pair-designing sessions, the simpler flat navigation started to make all the more sense. It was just a matter of visually organizing the menu items themselves.

Whats more, apart from our hospitality platform we were also still supporting our other gastronomy platform which had to still remain accessible somehow. With that in mind, I began sketching out different ideas for handling such challenges in the UI.

Minibar ideation: Exploring the concept of spaces via a new minbar

One idea in particular seemed very promising which was to use a minibar—also known as navigation rail in Material Design—for switching between different spaces or areas of the platform. Together with the sidebar and topbar it had the potential to really help improve the navigational hierarchy.

Preference test options: Final candidates ready for a team decision

That idea along with a couple of other more conservative proposals made the final cut:

  1. Blue sidebar: Keep the style we already had, but restructure menus. User menu placed at the bottom of the sidebar.
  2. Minibar + sidebar: Introduce a minibar on the left side for high-level actions, then use a light background for the sidebar itself (like #3). User menu placed on top of the sidebar.
  3. Light sidebar: Same as #1, but without blue (less branding presence). User menu placed on the right of the topbar.

Much like with the copywriting, these were also all documented in detail on their own DACI page with pros, cons, risks, roll-out plan and estimated costs of implementation.

Preference test

The designs were then validated internally with a company-wide preference test conducted in UsabilityHub, giving everyone in the company a say in what design they preferred and why. Out of a total of 90 participants from offices all over the world, a majority of 44% of the votes went to the second proposal with the remaining ones split evenly between the other two.

Preference test results: Clear winner based on votes, test duration and written feedback

Interestingly enough, the winning design was chosen the fastest out of the three while the other two took much longer until people decided on a preference. Deciding on the third design (i.e. light sidebar) took on average one minute longer than the time of the other two combined.

Final design: Modern, accessible and scalable

With such a difference in the decision time combined with the qualitative feedback we received, a winning design was chosen and we switched our attention to more intricate parts of this platform unification project such as merging settings and handling access to locked features.

Access levels

Depending on the type of plan that users were on, it was possible for some features to not be available to them. The way we handled this in the old sidebar was to still show those menu items but in a disabled state and accompanied by a locked badge so as to encourage upsell.

Locked content: Old design
Locked content: New designs

While this may have worked reasonably in a nested structure where an entire module could be locked, it really didn’t work with a flat structure. This however was a blessing in diguise because it enabled us to do things in a more user-friendly way by simply removing any locked items entirely, thus reducing clutter and allowing for a less intrusive yet prominent upsell button.

Change management

As things started to gain momentum it became all the more clear that this redesign could only be launched with a big-bang release, which is usually not ideal in terms of user experience. To help mitigate potential negative effects we kept users in the loop with direct communication via email and in-app notifications, gradually preparing them for the upcoming changes.

User menu: New sidebar brings with it new menu possibilities

Once the redesign was live, there was also a transition period in which users could still switch back to the old design if they wanted to, even though we did inform them that the new navigation would eventually become permanent.

Design system

Along with a better user experience, this redesign also brought with it a series of new UI components and patterns, making them perfect additions to our newly established design system before handing them over to development.


Even though all three design proposals were somewhat in line with our existing style, they weren’t really following our standards to the letter. This was intentional so that we could move faster with more iterations, but once a final design was chosen the time came to adapt those new components to meet our standards for spacing, color, typography etc.

Design system: Documentation of all components related to navigation

To reduce perceived loading time we also introduced skeleton screens to our design system, which incidentally enhanced this redesign even more as it now also supported loading states.

Loading state: Using skeleton screens to reduce perceived loading time

All of these components ended up documented in Notion from where they were later referenced across Confluence pages and Jira tickets as the project entered its development stages.


Apart from solving current navigation and information architecture issues, my goal with this project was to also set in place standards for how to handle future functionalities as far as content hierarchy is concerned.

Layout anatomy: Minibar, sidebar, topbar, main area

Cascading from left to right and from top to bottom, this layout was though out in such a way that each area would only allow for certain types of access to different parts of the app:

  1. Minibar: High level access to platform agnostic pages (e.g. settings, help, platform switcher).
  2. Sidebar: Primary access to core pages, loaded in the main area for permanent change of context (e.g. inbox, reports).
  3. Topbar: Secondary access to on-the-fly content, loaded in drawers for temporary change of context (e.g. team chat, notifications).
  4. Main: Core area where users can focus on the task at hand.

Furthermore, even the main area itself had the potential for its own navigation pattern, especially for complex pages like reports where users could choose the level of data granularity.

“Shallow by default, deep by choice.”

Instead of having a massive page with an overwhelming amount of data, a better approach could be to start with a more simplified view showing only high-level data and then gradually drilling down to more and more details depending on the user’s preference and level of expertise.

Drill-down idea: Progressive disclosure to support less tech-savy users

We were already using progressive disclosure with tiles that expanded into cards when clicked, but by leveraging these kind of nested pages we had the possibility to create even more flexible layouts with resizable cards and fluid content.

Drill down proposal: Gradually revealing more and more content

This was of course outside the scope of this particular project, but it was nonetheless relevant for improving the user experience even further and as such it was still included in our design system to serve as guidance for future projects.


This highly complex project was a long time coming and I’m glad to have played my part in making it happen. I’ve learned a lot during this time, from project management and cross team collaboration to how important it is to have long term product vision and design direction.

At the same time I’m also well aware that this was not a panacea for all our usability problems, but I do strongly believe that it was the groundwork needed for TrustYou’s products to truly become a holistic guest experience platform, the first in the industry.

It was a massive undertaking that could not have been made possible without the right team, and even though I may have not been with the company anymore by the time it went live, I’m still grateful to have worked on it with all the talented people across design, engineering, product, customer support and marketing.