Visual design, Research, and Design Systems work for a B2B tool that enables partners to manage their online reputation.
Reviews are Tripadvisor's bread and butter, it's the primary driver behind their revenue for both the consumer and business. No one clicks on a hotel or restaurant with poor reviews. Conversely, hoteliers and restauranteurs rely on Tripadvisor to manage reviews and guest satisfaction.
Tripadvisor has a suite of products on the B2B side for their internal clients. My role in this project was to validate a core experience in Reputation Pro, a consumer reviews management product.
I onboarded in the middle of a product overhaul. The B2B teams were completely updating their UI for the product suite. My first task was to redesign the Advanced Reviews Collection page (ARC for short), by applying the updated design system.
Advanced Review Collections focuses on how a property is performing in relation to reviews and requests for reviews. We discussed what story the data should be telling property managers ex: the ratio between sent to opens to clicks.
While building the design, I noticed there were multiple data view components. I had trouble identifying which component to use for the Overview section, and Email Campaigns. There wasn’t a rule that said X data should be expressed as a table vs Y data should be expressed as a whole number or percentage.
The larger issue here loomed around the fact that B2B was building and designing using B2C components. So if we wanted to propose a new pattern we had to go through the design systems team which (unfortunately) prioritized the B2C experience.
Due to the gatekeeping it became more efficient to oblige with consumer rules for the business product or ignore B2C rules and design our own way. However doing things our own way could cause development trouble, i.e. break things, in the future. This issue made me want to advocate heavier for a B2B design system, so I did.
At a high level this was the vision of evolving the DS.
I first sent out a survey to engineers and designers on both B2B and B2C to see what their perspective was. I asked questions like:
Their responses were polarized. B2B Engineers wanted the Design Systems team to act as more of a consultant since they didn’t have B2B context. Conversely, the Design Systems team felt that by and large there were enough components to support both teams. They did both agree that although there were many components to build off of, the Design System wasn’t as flexible as it could be. Lastly, both sides used TripDocs → More on that later.
The Design Systems team was using Slack to intake system contributions. However, there wasn’t a process to help a designer or engineer question their contribution. I created a conditional intake form that asked questions like:
Which team are you on? There were 3 teams B2B, B2C, and Native
How did the component originate? An example answer could be We found a unique pattern that the design system could not support.
How would you size the component? Going off the of T-shirt sizing system...
This contribution model was published internally for the primary use of Engineers, Designers, and PM's across all teams.
In short, Binny was created to centralize knowledge between product teams. He has Principles and Patterns, a need expressed internally, to help engineers and designers build intentionally. Plus components and Brand Design based on the asset overhaul created by the Marketing team.
Design Linting to nail the details. Figma had a plugin that could identify where there were any inconsistencies in a component or design. e.g. spacing errors, undefined text or color styles, or even an undefined border radius. This tool would keep designers honest and help engineers translate designs to code almost perfectly. The spacing errors alone could save dev time hundreds of hours and the company thousands of dollars, as their primary engineer contract hires were engaged to fix spacing issues in the code.
I marketed these ideas through Tripdocs, a tool used internally by 400 employees per month. The tool is primarily used by engineers which is who the ideas were geared towards supporting. I wrote a wiki with supporting links, ideas, and a how to use.
Going back to the design…
I was eager to validate this design and knew that one of the KPI’s for this project was to increase user activation of Advanced Review Collections. I compared features across competitors and realized why customers were using other products. For example Podium is great at integrations from google and Facebook to SMS they’re serious about connecting the hotel to the traveler. Reviews Tracker gave a more complete view of review data than competitors by allowing deeper analytics and helping hoteliers use that data to take strategic action.
The primary takeaways from the customer interviews and secondary research were:
Ultimately, if Reputation Pro wants to stay competitive then they would need to revise and update their feature set.
In the previous deign there were limited click-throughs and data presentation. But in the new design, each section is based in data and references sources for our users to operate from.
The suite of products has a lot of moving parts so it felt important to hone in on a direction that was supported by research. Although directional, the research and synthesis was highly valued by PM’s and Engineers who worked in this vertical.