How the design was shaped: weekly review with the clinical team
Every week I showed the latest build in a sprint review, and the product stayed testable throughout. There were two ways to try it: a web widget that mirrors how the assistant appears on the website, and a playground for running cases and leaving feedback on individual messages. A feedback form let clinicians report two kinds of problems separately: interface issues, and bedside-manner or response-quality issues. They have different fixes and different owners, so I kept them apart.
What the reviews changed:
The opening. The widget's first message and the input prompt were reworded after feedback. The “Connect me to the clinic” starter was removed and an “I have something else” starter was added, so the first step stays on describing the problem, not on leaving the chat.
Severity wording. A review caught an Urgent Care label sitting above a “Go to the ER Now” message, which tells the parent two different things. The wording was corrected so each level of care is named distinctly.
When triage starts. The assistant should enter the triage flow only when there is an actual child health concern, so greetings and general questions are not handled as symptoms.
Layout and mobile. The widget's position after an AI message, mobile view refinements, selecting between conversation threads, and a feedback button on mobile were all adjusted in later releases.
Waiting. Some responses took more than 45 seconds in testing, which raised the importance of the thinking state described below.
Decision 1: Start where the parent is, with no forms in the way
The assistant opens with one clear sentence about who it is and what it does: a triage assistant that helps assess the child's symptoms and guide the parent to the right level of care. Under it sit one-tap starters for the most common concerns (Fever, Cold, Nausea, Vomiting, Injury). A parent who knows what is wrong can start in one tap, and a parent who does not can simply describe the problem in their own words in the input below.
The first reply acknowledges the parent before asking anything (I understand your concern, let's figure this out together). The tone is part of the product: in health, a reassuring first line lowers the temperature of the whole conversation.
What I chose not to do: open with a login, an intake form or a long list of questions. Registration and structured details can come after the parent has felt helped.
Decision 2: One question at a time, in plain language
Triage is structured information gathering, but a stressed parent cannot hold twelve questions in their head. The assistant asks one short question at a time and builds on the answers: first the child's age, then when the symptom began, then what else the parent has noticed. Age comes early because in children it shapes how seriously nearly every symptom should be read.
When the parent might not remember to mention something relevant, the assistant offers a short list of examples to jog their memory (a cough or runny nose, vomiting or diarrhea, unusual sleepiness or irritability). A list works here because the parent only needs to recognize an item, not recall it.
What I chose not to do: present a symptom checklist or a multi-page questionnaire. A conversation lets the assistant skip what does not apply, and it asks less of the parent.
Decision 3: Make it usable with one hand
Parents often type badly, or cannot type, while holding a child. The input area therefore offers three ways to respond: type, record a voice message, or attach something with the plus control. Voice is a full state, not an afterthought. While recording, the parent sees a live waveform, a timer, a delete control and a send control. Once sent, the message stays in the conversation as a playable waveform, so the parent can see exactly what was sent, and the assistant continues the conversation from it.
Decision 4: Keep the safety boundaries on screen at all times
Two things are always visible, in every state and on every surface:
A small, plain line under the input: the AI can make mistakes, and for medical emergencies the parent should call 911.
A phone control in the header, so a parent who wants a person can reach one in a single tap.
The assistant also has its own avatar and a sparkle marker, so it is always clear that the other side of the conversation is an AI and not a staff member.
What I chose not to do: bury the disclaimer in a link or a first-time pop-up, or let the assistant appear to be a human. In a health product, the cost of a parent misunderstanding what they are talking to is too high.
Decision 5: Show that it is working
A pause in a medical conversation feels longer than it is. I designed a dedicated thinking state: the assistant's avatar appears with a quiet Thinking indicator while a response is prepared, so the parent knows the message was received. The assistant's identity, a round Hello smiley with a sparkle, was developed as a small family of animations. I explored several treatments of the sparkle, varying its color and motion, so that waiting reads as the assistant paying attention, not as the product freezing.
Decision 6: One conversation, three surfaces
A parent might arrive from a phone, a laptop or the Hello Pediatrics website, so the same conversation works in three forms:
Docked widget on the website. The chat sits beside the homepage, so the Book Appointment call to action stays visible. The assistant supports the booking path and does not replace it.
Mobile widget. The same conversation in a single narrow column, with the starters and input designed for thumbs.
Full-screen chat. For longer conversations, a larger layout with a conversation history, search, a frequently asked questions entry and room for attached files. It opens with a plain prompt: What can I help you with today?
The parts that carry meaning (the avatar, the starters, the disclaimer, the voice and thinking states) stay the same across all three, so nothing has to be relearned.
Decision 7: Design the supervisor's side as a queue, not an inbox
The AI-Chat Supervisor Hub is where a person stays in the loop. It opens on a list of conversations with a count, so the supervisor knows the size of the job. Each row shows the family, how long ago the message arrived, a waiting status and an unread count, and the list can be refreshed and searched.
Within a conversation, the AI's proposed response appears as a clearly labeled draft: AI Triage Agent, Draft. The supervisor has two honest choices:
Approve and Send when the AI's response goes out as it is.
Update and Send when the supervisor edits or replaces it with a custom response.
The button changes label depending on what the human actually did. That keeps the action truthful and also records something valuable for the team: how often the AI's proposal needs to be changed. A refresh control lets the supervisor ask the AI to generate its response again.
One small rule in the design carries a lot of weight: the waiting state stays on until the family has actually been answered, even after a supervisor has opened and read the messages. Viewed is not the same as handled, and a worried parent should never be left waiting because a conversation looked attended to.
What I chose not to do: let the AI message the family with no review step, or show the supervisor a plain chat inbox where draft and sent messages look alike.
Decision 8: Design the exits, not only the answer
A triage conversation is only useful if it ends in a next step. Phase II added the routes out of the chat: scheduling an appointment, a telehealth visit, and a call to the family's own pediatrician's office for routine visits. Each exit is shown as a visible step so the parent understands what is happening. In this release those included a simulated “connecting to a doctor” state for telehealth, and a case where no same-day slot is found with the family's own practice and the parent is offered a visit with Hello Pediatrics instead. The clinical team set the rule that telehealth is provided by Hello Pediatrics, not by the family's practice.
What I chose not to do: model the full complexity of every practice's office hours. We agreed to keep scheduling stable and simplified and to polish a handful of reliable cases, so that what a parent sees works every time.
Result
I will be precise: I am not claiming clinical outcomes or usage figures, and the accuracy numbers below belong to the whole team's evaluation work, not to design alone.
What the work produced:
A parent-facing assistant that starts in one tap, asks one question at a time, supports typing, voice and attachments, and always shows its limits and a way to reach a person.
A consistent conversation across a docked website widget, a mobile widget and a full-screen view.
A supervisor hub that treats AI output as a draft, with a queue, waiting states, and two clearly different ways to send.
An assistant identity and a thinking animation that make waiting feel attentive.
What the process showed:
Finalized UI designs on 3 March and the website widget on 17 March were the planned milestones; by 28 April the team was on release v0.2.4, with the use cases validated by the client team and a demo video page added.
The release went out by invite link instead of open public access, and friends-and-family testing started once obvious blockers were fixed, so real feedback arrived before wider exposure.
The team's evaluation work set a target of raising baseline accuracy from about 60 percent toward 85 to 90 percent, by letting the judge accept more than one clinically acceptable recommendation. I do not have the final figure, and it reflects the whole team's work, not design alone.
How I would measure it:
The share of visitors who send a first message after the assistant opens.
How many questions it takes to reach a recommendation, and where parents drop out of the conversation.
The share of AI drafts approved as they are versus updated by a supervisor, by symptom type.
Time from a parent's message to a supervisor's reply.
How often parents use the phone control, and how often they book after a recommendation.
What I would do differently
Two gaps stand out. First, the queue shows who has waited longest but not who is most urgent. I would add an urgency signal, so a supervisor can see a worrying case before an older routine one. Second, the supervisor currently reads the whole conversation to understand the case. I would add a short structured summary at the top (age, main symptom, onset, other symptoms) so a review takes seconds, not minutes. ER routing was tightened during the project, and I would keep testing the first message of every conversation for emergency language, so the most serious cases are never met with routine questions first.
Reflection
In a health product, the job of the interface is not to make the AI look impressive. It is to lower the effort for a frightened person, be honest about what the AI is, and keep a human within reach on both sides of the conversation. The decisions that mattered most here were the quiet ones: a calming first line, one question at a time, a disclaimer that never disappears, and a button that says what the supervisor actually did.
