06 / Selected workHealthtech · Decision support

DoctorAnywhere

Help agents find a suitable specialist—and see why.

Provider choice relied on experienced agents remembering information spread across several tools. I designed an explainable recommendation layer that brought five matching signals into the existing booking flow while leaving the final choice with the agent.

Product DesignService DesignDecision Support
My role
Lead Product Designer — problem framing, research, recommendation logic, interaction design and validation
Scope
Discovery → validation
Focus
Recommendation · Explainable UX · Healthtech
Evidence status
This case shows a validated design direction and workflow evidence. No post-launch business outcome is claimed because production measurement was not available.
LiveCrest specialist recommendation experience shown across desktop and mobile with smart matching, trusted doctors and faster decisions
Validated scope—not post-launch impact
5matching signals unified
1embedded decision surface
Human-ledfinal provider choice
01 · Project overview

My role, the team and how success was defined

A short project brief before the detailed story: the setting, my responsibility, the people involved and the outcome we were working towards.

01Product context
The recommendation capability extended the medical-concierge platform after the core case workflow had been structured and digitised.
02My ownership
I framed the decision problem, mapped matching signals, defined explainability requirements and designed the embedded recommendation-to-booking flow.
03Core collaborators
Concierge agents, operational and clinical stakeholders, Product and Engineering shaped the rules, exceptions and feasible workflow.
04Success definition
Help agents compare suitable providers more consistently and confidently without creating a black box or another tool to manage.
02 · Problem

What was happening—and why it mattered

Specialty, location, availability, language and coverage were reviewed in different places. Under time pressure, that made decisions slower and more dependent on individual memory. A black-box ranking or a separate tool would have introduced new risks.

  • Provider selection relied on tacit knowledge held by individual agents.
  • Specialty, location, availability, language and insurance lived in different places.
  • Inconsistent matches created re-referrals and slower confirmations.
  • A separate tool would have added friction to an already complex workflow.

Decision support should improve confidence without taking accountability away from the person making the choice.

03 · Discovery evidence

Evidence that changed how I understood the problem

Behavioural, operational and qualitative evidence did different jobs. Together, they helped define what the team needed to solve before choosing a direction.

01Frontline decision-making

Experienced agents carried provider knowledge in memory, making speed and consistency dependent on who handled the case.

Design implication

The interface needed to externalise useful judgement without pretending every case had one automatic answer.

02Scattered matching data

Specialty, location, availability, language and coverage were reviewed across separate information sources.

Design implication

The highest-value product move was to unify the comparison at the moment of choice.

03Workflow observation

Agents were already operating inside a case flow under time pressure; switching to a standalone recommendation tool would add friction.

Design implication

Decision support needed to sit inside the existing case and lead directly into booking.

04 · Service system

What customers saw depended on what happened behind it

The blueprint connects the customer journey, product behaviour and operational responsibilities across the same sequence.

StageCustomerFrontstageBackstage
1 · Interpret need

The patient’s referral, preferences and constraints define the request.

The request is clarified before provider options are presented.

The agent confirms specialty, urgency, coverage and preference context.

2 · Screen options

Only relevant providers should remain in consideration.

Unsuitable options are filtered from the comparison.

Rules apply specialty, coverage, location, language and availability signals.

3 · Compare

Trade-offs become easier to discuss and understand.

A ranked view exposes the most relevant options and why they fit.

Signal-level rationale supports, rather than replaces, agent judgement.

4 · Decide

A suitable provider is selected with clear reasoning.

The agent can review, override and explain the recommendation.

The final choice and exception reasoning remain accountable.

5 · Book

The selected option progresses into appointment coordination.

The recommendation connects directly to booking actions.

The existing case and ticket workflow continues without a separate hand-off.

Scroll horizontally on smaller screens to follow the complete service.

05 · Decision trail

The choices that shaped the work

The artefacts mattered when they helped the team choose. These are the questions, evidence and decisions behind the final direction.

01
Question

Should the system choose the provider?

Evidence

Patient preferences, clinical context and operational exceptions could not be reduced to one deterministic answer.

Decision

Rank and explain suitable options while keeping the final decision with the agent.

02
Question

How much rationale should be visible?

Evidence

A score alone would be difficult to trust, explain or override responsibly.

Decision

Expose the matching signals behind each recommendation at the comparison point.

03
Question

Where should the feature live?

Evidence

Agents already had a complex case workflow and could not absorb another destination or tool.

Decision

Embed recommendations inside the case flow with a direct continuation into booking.

06 · Two connected lenses

One problem, viewed through service and product

The operating service and the interface formed one system. Each lens addressed a different part of the same problem.

Service Design

Shaping the ecosystem, hand-offs and operating model.

  • Identified where provider choice sat in the wider referral service
  • Mapped the signals and operational constraints behind a good match
  • Preserved human judgement for exceptions and complex patient needs
  • Reduced hand-offs by placing guidance in the existing agent journey

Product Design

Turning service decisions into clear, usable product behaviour.

  • Designed a ranked provider view using relevant matching signals
  • Made recommendation rationale visible and explainable
  • Connected the recommendation directly to booking actions
  • Kept agents in control instead of presenting a black-box answer
07 · Process

How the work moved from uncertainty to a decision

01

Frame the judgement, not just the search

The work began with the decision agents were making: which provider is suitable for this patient, under these constraints? That clarified which signals mattered and where guidance could help.

02

Put the comparison in one place

Specialty fit, location, availability, language and coverage were brought into a ranked view so agents could compare options without switching tools.

03

Make the recommendation accountable

Each option showed the signals behind the match. Agents could assess the rationale, handle exceptions and remain responsible for the final choice.

04

Fit the feature into the existing case flow

Recommendations sat beside the case context and continued directly into booking, avoiding another destination for agents to manage.

08 · Design evolution

From conversational skeleton to recommendation experience

I used low-fidelity flows to test the order of questions and decision points before visual design. The high-fidelity experience then translated that logic into a branded, guided journey from patient intake to a confident specialist selection.

01 · Low-fi exploration

Test the conversation before styling the interface

The first sketches modelled the concierge as a progressive conversation. Each response unlocked the next relevant question, keeping the interaction focused while showing how specialty, hospital and preferred dates would shape the recommendation.

Four hand-drawn low-fidelity screens showing a health concierge collecting a patient name, specialty, hospital preference and preferred date range
Early conversational wireframes used quick replies and staged questions to test the intake sequence before committing to detailed interface design.
  • Ask one contextual question at a time instead of presenting a long intake form.
  • Use quick-select options for hospital and preferred dates to reduce typing and ambiguity.
  • Keep previous answers visible in the conversation so the agent and patient retain context.
02 · High-fi delivery

Make patient intent, availability and provider choice actionable

The final direction combined conversational intake with focused task surfaces. Patients could upload a referral, choose up to two preferred time windows and compare recommended specialists without leaving the concierge journey.

Three high-fidelity Great Eastern concierge screens showing referral upload, preferred date and time selection, and recommended specialist cards
High-fidelity screens connected referral evidence, availability preferences and specialist comparison into one continuous recommendation-to-booking flow.
  • Keep referral upload inside the conversation so clinical context travels with the request.
  • Let patients provide more than one availability window to improve the chance of a workable match.
  • Present comparable doctor cards with specialty, experience, language and a direct selection action.
09 · Constraints and trade-offs

The constraints that shaped the work

These constraints affected the direction, the order of work and the compromises made with the wider team.

01

Provider data can be incomplete or change

The tension

A recommendation is only as dependable as its availability, coverage and provider information.

My response

The interface showed the signals being used and required agent review rather than presenting more certainty than the data supported.

02

Explainability mattered in a high-stakes decision

The tension

A score without rationale would be hard to trust, explain or override responsibly.

My response

Every recommendation showed why it matched, allowing the agent to compare options and use judgement where the rules were incomplete.

03

Decision support could add workflow load

The tension

Extra screens or another tool could consume the time saved by ranking providers.

My response

The feature reused case context and connected the selected provider directly to the next booking action.

10 · Evidence

What the evidence shows

5matching signals unified
1ranked decision surface
0extra tools required
Humanfinal judgement retained

This case presents validated design direction and workflow evidence. I do not claim a post-launch business metric until production measurement is available.

11 · Outcome

What changed

01

A memory-dependent decision became a guided comparison.

02

The rationale for each recommendation remained visible.

03

Agents could compare provider options with less cognitive load.

04

The capability extended the concierge platform without creating a separate tool.

12 · Reflection

What I learned and would do next

Strongest contribution

I designed the recommendation as accountable decision support: useful ranking, visible rationale and human control in the same interaction.

What I learned

In a sensitive service, explainability is not supporting copy. It is part of the interaction and the basis for trust and exception handling.

What I would do next

I would measure time to match, overrides, re-referrals, booking completion and the reasons agents reject a recommendation.

Next case study · IMDA design assessment

A cross-agency plan for setting up a business