Healthcare Reputation Management Tool 0-1

DATA DEPENDENCIES

We had a listing management product that handled clients’ listings, including third-party integrations, account linking, data mapping, and listing lifecycle management. By leveraging the existing data from that product, we were able to seamlessly power the reviews feature in this new product.

As the designer for both products, I worked closely with engineers on the online reputation team, helping them understand data dependencies, groupings, and inquiry logic. I also facilitated collaboration between engineers across the two teams.

DESIGN

RESEARCH

Initially, I was only able to interview one client about their existing review solicitation process. Their process was very specific to the tools they used and the limitations they faced. To design despite the research constraints, I mapped out their flow, listed my observations, assumptions, and noted remaining questions that I got to further validate by secondary research and informal discussions with other clients, as opportunities arose.

DEFINE

After an iterative process of research and ideation, I summarized user’s JTBDs and came to the following user flow for the review boost feature:

DATA DEPENDENCIES

Configuring review boosts required matching data from EHR databases with third-party online listings to send review invitations after new visits were recorded in the EHR. This was previously a manual, daily task for the users. By leveraging the data foundations of our other products, we were able to greatly streamline the process and automate it on the backend.

At the time, another team had just started building standardized APIs for EHR integrations. I conducted extensive research into the information hierarchy of EHR databases and collaborated closely with engineers to identify what data we could leverage, how to map it to listings, and how to use it to simplify the user experience.

DESIGN

With the flow in place, I collaborated with my PM to define the scope for each step and designed a solution that specifically addresses the needs and pain points of health systems.

Highlight 1: Volume Split

Patients receive review invitations for either their provider or the location they visited. Health systems previously had to manually split review volume between locations and providers by visit types, then constantly monitor and adjust to achieve the desired outcome. My design lets users set a desired volume distribution, which is then managed fully automatically on the backend, significantly reducing their workload.

Highlight 2: EHR Integrations

I worked closely with PMs and engineering teams to understand the complex data integration and matching logic, ensuring these processes were all handled properly on the backend. This allowed me to streamline the process and enable users to only focus on their main jobs to be done.

Highlight 3: Visit Type Filters

Health systems use visit types to decide which patients receive review invitations. Visit types can be really confusing, often similar for providers under the same specialty but could be different for each provider. My design abstracts this to the location level for efficiency in configuring boosts, with hints to inform users of any edge cases.

Highlight 4: Flexible Delivery Settings

User can configure both SMS and email in order to maximize the boost volume while being fully compliant with the TCPA regulations. Users have the flexibility to either use globally configured templates, or customize for each boost.

Highlight 5: Summary & Review

The summary page allows users to review and confirm all the settings they’ve configured, before starting to send out messages to the patients. The users also have the option to save it as a draft for future activation.

OUTCOME

This feature significantly streamlined the review invitation configuration process, boosting user efficiency. It immediately caught the attention of an enterprise-level client, who requested a trial to replace their existing manual workflow.

RESEARCH

Without many opportunities for direct user research, I conducted a lot of secondary research, including identifying the benefits and risks, understanding industry best practices, analyzing actual responses, listing down my questions and assumptions, etc.

KNOWNS

• Responses for positive and negative reviews are different.
• Responses, especially for negative reviews, often follow a pattern with several fixed components.

UNKNOWNS & ASSUMPTIONS

• I didn’t know if users always use complete response templates. By analyzing our competitors’ products, I assumed some users would create templates for different parts of a response and combine them as needed.
• I didn’t get to know how many templates users usually have. I assumed that while some users have a few templates, some might have a lot, especially if they create templates for each part of a response.

DESIGN

With all the knowns, unknowns, and assumptions, I decided to create a canned response feature with a labeling system that’s flexible enough to accommodate different types of use cases.

PROTOTYPES

I also created prototypes to show different use cases (full template | modular template), and introduced typing interactions to make it easier for user to search through the templates.

SCOPE ADJUSTMENT

While the design and prototypes were in place, as we started to sign contracts and learn about the immediate needs of our initial clients, I learnt that our initial clients only have a few response templates. My PM and I decided to ship a minimal version first, and save the rest of the design for future iterations.

RESEARCH

I did some secondary research, competitive research and client research to understand what service recovery is about, how it usually works, and the specific processes that our clients have.

INSIGHTS

During discovery, I learnt that our clients have really different processes for service recovery. Some used a ticketing system to track the end-to-end process, while others simply hand off to other teams through emails with screenshots. I also discovered that service recovery is a process that could involve multiple stakeholders beyond marketing, which was the main target user group for our product.

SCOPING

Although we really wanted to help make the whole service recovery flow effective for health systems, my PM and I decided to stay focused on what marketing users need, and have a minimal version for quick validation.

TASK ANALYSIS

With that in mind, I listed down and grouped all the common tasks that marketing users need to perform, and incorporated these tasks into our existing review response flow to make a lightweight version of the service recovery feature.

USABILITY TEST

I conducted this usability test before I started designing the service recovery feature. I anticipated that we would need to add more user actions to the review card, so I wanted to gather some user feedback while I had more time, to help guide any quick iterations we may need in the future. I ran an unmoderated usability study on dscout, where participants interacted with three different prototypes, each with four actions on the review card.

Two key insights informed my design of the service recovery feature:

1. The ‘X’ icon to dismiss the review was confusing to some users.
2. Although users liked all three prototypes, they particularly appreciated the third one, where all actions were on the same level, especially since the escalate action wasn’t hidden.

DESIGN

USER NEEDS

While the client were generally satisfied with responding to reviews, selecting which reviews to address was still challenging. Their team structure required some users to have admin access to all reviews but only respond to reviews under certain markets, locations, etc.

The relationships between markets, locations, providers, and their listings are complex. I started by identifying the major use cases my design should prioritize based on the user needs:

1. View all reviews for a market
2. View all reviews across multiple locations, including both location listings and all provider listings
3. View all reviews for specific location or provider listings

DESIGN ITERATIONS

I went through rounds of design, prototyping and usability tests with colleagues and our client.

MENTAL MODEL

The data relationship between markets, locations and providers are complex, and they are interrelated. The usability tests with the client helped me realize that my assumption of the their mental model was not accurate. I assumed that they would be clear on the difference between location as a grouping vs. location as a listing. However, they were actually confused by that concept.

FINAL DESIGN

INTERVIEWS

With the rise of generative AI technology, our team started to explore the idea of fully automating responses with AI, not only because it aligned with our strategy of reducing response time, but it was also the hot topic in all sales conversations. Despite the excitement, I felt it was such a broad and ambiguous idea, and I was a little concerned about how helpful the feature would be to our relatively “conservative” healthcare clients.

With so many unknowns, I decided to hold off on diving into design, and instead collaborated with my PM to conduct some quick interviews with clients. We aimed to understand:

❓ What automated responses mean to them.

❓ How helpful they think automated responses could be.

❓ Any concerns they have with automated responses.

❓ Their expected level of control over the responses.

❓ Any guardrails they think would help make the feature truly helpful.

INTERVIEW RESULTS

We interviewed three clients and gathered additional information from others. The insights we gained was invaluable:

✅ Automating for reviews with no comments

All users liked the idea of automating responses for reviews with no comments.

❌ Automating for reviews with comments

While some users do automate responses to positive reviews, most prefer to read all reviews before responding, even to positive ones.

✅ Suggested responses

All users liked the idea of AI suggested responses, as they improve efficiency without taking away any control.

DESIGN

Based on the insights, we prioritized using generative AI to suggest responses for all reviews with comments. The design was kept very lightweight and straightforward, as the magic happens through the AI model that powers this feature.

COLLABORATING WITH THE AI TEAM

The key to the success of this feature was a close collaboration between our team and the AI Labs team, through clear communication, transparent feedback sharing, regular sync-up meetings, etc. Drawing from previous interviews, we gathered many insights that guided the model's development. I worked with my PM to consolidate our research findings into guidelines for model training. We also documented possible model inputs, training ideas we brainstormed, and experiments we conducted with ChatGPT on a FigJam board for clear communication.

MORE WORK ON MY TEAM

My work extended beyond just design. While the AI Labs team focused on model development, I collaborated closely with my PM and Engineering Manager to refine the data requirements, product guardrails, and success metrics.

OUTCOME

With the collective effort of our team and the AI Labs team, we completed a demo prototype that attracted a lot of prospects, while steadily progressing toward a fully functional feature.