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.

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.

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”).

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.

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.

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!

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.

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.

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.

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.