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.
Background
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
- You are curious what guests are writing online about your hotel’s new hygiene policies. Where would you click to find this information?
- Your guests are sending you questions and special requests for their room. Where would you click to see what they are asking?
- You want to start using WhatsApp to listen to guest requests. Where would you click to set this up?
- 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?
- 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?
- 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.
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.
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.
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.
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.
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.
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.
That idea along with a couple of other more conservative proposals made the final cut:
- Blue sidebar: Keep the style we already had, but restructure menus. User menu placed at the bottom of the sidebar.
- 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.
- 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.
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.
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.
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.
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.
Components
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.
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.
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.
Patterns
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.
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:
- Minibar: High level access to platform agnostic pages (e.g. settings, help, platform switcher).
- Sidebar: Primary access to core pages, loaded in the main area for permanent change of context (e.g. inbox, reports).
- Topbar: Secondary access to on-the-fly content, loaded in drawers for temporary change of context (e.g. team chat, notifications).
- 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.
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.
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.
Conclusion
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.