OVERVIEW

Problem
ReviewTrackers' Local Listings tool helps businesses maintain accurate information across multiple directories by synchronizing details like hours of operation. However, it faces challenges due to an outdated and confusing interface, making it difficult for users to assess performance and resolve discrepancies, leading to inconsistent information across platforms.
Solution
Through stakeholder interviews, we were able to pin-point 3 main areas of improvement: make the tool more intuitive to navigate, give users a quick way to assess overall listing health, and give users an easy way to fix out of sync listings. In order to do this, we rearranged and modernized the site map and Local Listings table, we added a listings health metrics bar broken down by source to the top of the page, and we added an “actionability” fly-out panel.
My Role
UX Designer, Triad Design Lead
Timeline
Aug 2023 - Dec 2023
Team Members
Cecilia Xie (Me), Sarah Spiegle (PM), Jesse Hinchcliffe (PM), Steffeni Veren (Tech Lead), Saul Ocampo (FE dev), Charlie Billaeau (FE dev),Lindsay Eggers (BE Dev), Dominic Bales (BE Dev)
Tools
Figma, Fullstory
Design Process
1. Research
Stakeholder Interviews
Competitive Analysis
2. Design
Site Map
Sketching
Lo-Fi Wireframes
Iterations
Hi-Fi Wirefames
3. Retrospective
Future Steps
What I Learned
My Contribution
As a full-stack designer and lead designer for my team, I managed the entire design process from research and stakeholder interviews to prototyping and final implementation. I made crucial design decisions within my product triad, collaborating closely with product managers and developers to ensure our solutions were both user-centric and technically feasible.
Design Outcome

RESEARCH

Stakeholder Interviews
My  first step in this project was to conduct stakeholder interviews, which my product manager  and I conducted together after setting up meetings with our current users. We asked them what they disliked about our current listings tool and what could be improved.
After conducting these interviews we synthesized the results as a product  triad and came up with three main problems that we wanted to solve.
We were able to distill it down to three main  issues:

1) General lack of intuitiveness: this is an old legacy feature that was made when the company was short on designers so it was thrown together by front end developers and everything was just thrown onto a page with very little thought for the users’ end experience.  

2) Overall performance understanding: what is the current health of my listings? This was complicated because we didn’t necessarily want to highlight sources where we had low percentage effectiveness, but at the same time we weren’t highlighting areas we were effective in either.

3) What next? Users struggled to know which sources were out of sync and why, as well as how to fix those issues (could be an integration issue, could be a source where we’re trying to sync information but wouldn’t be able to update it, instances where we tried as many times as we could but stopped, etc.)
Competitive Analysis
My next step was to do a competitive analysis with our biggest competitor, Rep.com. One of the things that Rep.com had that I really liked was an entire page for listings health and a little bar graph to help easily visualize the data. During this process I also got together our team at work and walked them through my competitive analysis and asked them what they thought Rep did better than us and one of the most common answers was that people liked how many different ways rep had to display the same data in different ways.

DESIGN

Site Map
I’ve broken this case study down into a three pronged approach for ease of consumption, but in reality all these parts and pieces were moving in tandem to each other simultaneously. The first piece we’re going to tackle is the general intuitiveness and usability. In our user interviews, many people mentioned that the interface generally lacked intuitiveness. In the platform, we had a “Locations” page as well as the “Local Listings” tool and they both share the “Locations Details” page. Users found the “Local Listings <> Location” connection to be confusing, so users ended up bouncing back and forth between the two. Users also didn’t know about of a lot of newer features that had been released such as Holiday Hours and Photos Management, and these features were in turn underutilized because they were difficult to find.

I created a simple site map to solve for the confusion surrounding the “Local Listings” and “Locations” page connection. The most confusing thing here is that when a user would click into the “Locations Details” page from “Local Listings’, when they hit back it would still route them back to the “Locations” page even though they came in through “Local Listings”. Another thing that was confusing was that clicking both the location name and the edit button on the “Local Listings” table both brought you to the “Locations Details” page, so I advocated that clicking the location name should bring you to the “Locations Details” page but clicking the edit button should take you directly to the “Edit Location Details” page. This change was a fairly easy implementation and didn’t require any further design work.
Sketching
Next, I sketched out an idea to bring the sources to the top of the Local Listings table and have the data point types (name, address, phone, etc.) be the expandable columns because we heard in user interviews that users care more about the source than the specific data type (for example, some businesses will say, “I need to make sure all my GMB listings are in sync but I don’t care about Bing”, but rarely do we hear users saying “I only care if my phone is correct, but I don’t care about my hours”).
Iterations
Here is a direct comparison between the previous design with the sources hidden in the expandable drawer and then the new iteration where sources are brought out to the table header. We then took this mock to our Customer Success team for feedback and they actually said that users might find this to be too much information, so a few iterations later we ended up with this, which is still broken out by source across the top and users can click the arrows to scroll across all sources, but there is no longer an expandable row in order to reduce cognitive overhead for the users.
The next piece of improving intuitiveness was to give the Location Details Page and the Edit Locations Details Page a refresh. The Locations Details Page provides a clear example of legacy front-end development decision making sans a designer. Notably, there's an unusual layout quirk where new features were consistently added to a “halfway-down-the-page” navigation section, which is not found anywhere else in the platform and goes against our established design system best practices for navigation. This results in a visually confusing and outdated user experience.Additionally, when you click the "Edit Location" button at the top, it takes you to the Edit Locations Page. This interface displays all the form fields needed to update location information, but for some reason, the content remains below the fold, further complicating the user experience.


My goal was to modernize the interface by incorporating a card-based layout, while also improving the visibility of newly added features that users had previously reported as difficult to locate, such as holiday hours and Google Photos integration. I also explored an edit function that allowed for field-by-field adjustments rather than editing the entire card, drawing inspiration from Google My Business (GMB).
After several rounds of design critiques, we landed on this final approach: I opted for a stacked layout rather than a side-by-side format, aligning with our design system since a two-column view isn’t used anywhere else in the application. We also decided to apply a full-card edit approach instead of field-by-field editing. User behavior analysis in Fullstory showed that when users access this page, they often need to update multiple fields at once, so this adjustment significantly reduces the number of clicks required.
Metrics
Our next objective was to improve users' understanding of their metrics and overall performance. Users frequently struggle with assessing the current health of their listings. This challenge is compounded by the need to balance transparency about areas with low effectiveness, while also ensuring that high-performance areas are adequately highlighted. Additionally, the existing metric of "X out of Y locations out of sync" often presents a negative perception, as it typically shows a high percentage of discrepancies (e.g. 95% out of sync). Our goal was to address these issues and provide a more nuanced view of performance.

Initially, I proposed implementing a bar of informational cards above the table, shown below. However, this approach encountered challenges when real data was applied: high percentages of discrepancies negatively impacted visual appeal, and the cards did not effectively address users' specific needs.
To resolve the issue of high out-of-sync percentages, I proposed segmenting data points by type rather than by location. For instance, if a location’s data is largely in sync except for the phone number, it would previously appear as entirely out of sync. By categorizing data into individual points (e.g., 1 data point out of sync and 9 in sync), we provided a more nuanced view.
I then explored various ways to display these data points while prioritizing sources that are most important to users. The final solution integrates both improvements: it segments data points by type to reduce the perception of discrepancies and allows users to filter by relevant sources, boosting usability.
Actionability
One of the key challenges users face is understanding which sources are out of sync, why they’re out of sync, and most importantly, how to fix those issues. The integration issues can be complex—sometimes we're dealing with sources where synchronization might not be possible, or instances where the process has stopped altogether.

This is where our technical PM had to step in since my PM and I didn’t have a deep grasp of the complex backend processes. For instance, we work with a variety of integration types: OAuth, global token integrations, and access integrations. With Google and Facebook, we have OAuth integrations, meaning if we push an update, it’s likely to go through. But with platforms like Yelp and Bing, we have access integrations. Here, we need to request access, and once granted, it turns into a global token integration. This removes barriers but also adds responsibility—we have to ensure that business information doesn’t get mixed up, which could create liability issues. So, our Customer Success Managers manually verify account details to prevent mistakes.

Now, imagine being a user. You’ve asked ReviewTrackers to update your info, but it hasn’t happened yet. Our challenge is finding a way to keep you informed without overwhelming you with all the technical integration details I just shared.
For my initial approach, I experimented with adding statuses to various pieces of information on the Location Details page. However, this required users to click away from the table, which disrupted their flow. I then shifted to a flyout sliding panel, which felt like a much more seamless solution. From there, I focused on working through the individual use cases.
In addition to all the different integration use cases, we also had to consider white labeling, auto-sync, publishing enablement, and a few other things that didn’t even come up until we showed the 'final' mocks to our developers. To keep track, we created the below flowchart to manage all the use cases. But I definitely learned a valuable lesson: involve your developers early and often!
Flyout Iterations
In the first iteration, I pulled all the info from the Location Details page into the flyout and added error icons for anything out of sync. It didn’t look great—there was too much unnecessary information. The second iteration introduced card formats, which felt much cleaner and put more consideration into the information hierarchy. By the final iteration, every flyout had an action card at the top, guiding users on what to do next—whether it’s integrating their account, claiming their listings page, or manually updating their listing. Below that, the cards displayed out-of-sync data points, making manual updates much easier.
Hi-Fi Wireframes
For the final version, we’ve streamlined the main table to focus on the source. We also added a metrics bar at the top so users can quickly see the overall health of their listings. When you click an out-of-sync or pending icon, a flyout appears on the side, explaining what’s wrong with that location’s listing and how to fix it.

RETROSPECTIVE

Future Steps
This feature was launched shortly before my departure from the company, and while I had outlined next steps to ensure its success, I wasn’t able to see them through. My plan was to closely monitor its performance against the KPIs I set with my PM, tracking metrics like user engagement and task completion rates. I also intended to gather user feedback through interviews and usability testing to identify any areas for improvement. Although I wasn’t able to carry out these steps, they were designed to refine the feature and optimize its functionality in future iterations.
What I Learned
One key takeaway, which I already knew but was reinforced with this technically challenging project, is to check in with your developers at every step. They’ll catch things you might miss and offer valuable insights along the way. Additionally, I learned how to navigate a project with multiple integration types, each presenting its own set of technical complexities.

This project also taught me the nuances of redesigning a legacy feature—where limitations are much more pronounced compared to the flexibility of designing a greenfield project from scratch. It required a deeper level of problem-solving and collaboration to work within those constraints while still delivering a user-friendly solution.