Scribe
Providing accurate summaries professionals can rely on, so they can be fully present and have meaningful conversations with their clients
Scribe is a summarisation tool that helps practitioners immerse themselves fully in conversations by removing the distraction of documentation. Acting as an invisible assistant, it captures, transforms, and summarises dialogue into structured notes that surface key insights for reflection and action, while reducing the time spent on documentation.
As the product gained traction across healthcare and social service agencies, I led design research to understand documentation needs across roles. By working closely with stakeholders, we prioritised features that delivered the greatest impact — helping practitioners save time, reduce cognitive load, and produce more usable summaries. Just as importantly, we made deliberate decisions on what not to build, ensuring Scribe remained simple, focused, and genuinely helpful in daily practice.
Turning Conversations into Structured Documentation
30-Second Summary
For professionals like social workers and healthcare practitioners, documentation is a critical (but often burdensome) part of the job. It is especially challenging when they are expected to capture accurate, detailed notes while navigating emotionally intense or complex conversations with clients or patients.
In Singapore, this challenge is compounded by the way people naturally switch between languages and use Singlish — a reality that existing transcription or summarisation tools aren’t built to handle. Most struggle with accuracy, making them unsuitable for local practice.
Problem Discovery
Born out of Hack for Public Good in 2024, Scribe was built to ease the mental load of documentation, helping medical social workers stay present in emotionally demanding conversations without compromising the quality of interaction, while still ensuring accurate records are captured for their casework.
Scribe was designed to...
How Scribe Works
Step 1: A typical Scribe session begins with the user starting a recording on their mobile device before a client or patient interaction.
Step 2: After the conversation, the user accesses the Scribe web platform on their computer, where the recorded session is automatically available.
Step 3: The user selects the session and generates a summary by providing a short description and crafting summary headers.
Step 4: The user views the generated summary, and can either regenerate another if needed or copy it out to their documentation system.
My Role
I joined the Scribe team in March 2025, shortly after its initial pilot in a few public hospitals, as it was beginning to scale for wider adoption. Working with another designer, three engineers and an operations specialist, I helped shape the next wave of improvements as the team focused on refining the product and expanding its reach across social services, healthcare, and broader public sector teams.
What We Heard from Our Users
We wanted to understand not just how Scribe was being used in routine practice, but also how users were experiencing it — what made their work easier, and what was still lacking. To do this, we shadowed practitioners, conducted interviews, and had ongoing check-ins with teams across healthcare and social care. While many users appreciated how Scribe eased their documentation workload, others raised challenges with parts of the experience, along with requests for more features to better support their documentation needs.
To Build or Not to Build
With so many ideas surfaced, we knew we couldn't (and shouldn't) build everything. Adding too many features risked making the product harder to use, especially if users ended up spending more time navigating the interface than actually completing their documentation. That would go against Scribe’s core goal: to reduce effort, not add to it.
To stay true to that goal, we dug into each pain point and feature request, speaking with social workers, counsellors and psychologists to understand what they really needed from Scribe. This was not just about content, but also how well the output aligned with their documentation needs and styles. These insights helped us prioritise the features that would deliver the most value without compromising simplicity.
User Requests We Assessed Against Product Goals
Each feature request was evaluated based on three criteria:
Frequency of request – How common was the need across user groups?
Alignment with core purpose – Does it support our goal of simplifying documentation for them?
Usability impact – Would it improve or complicate the user experience?
What We Ended Up Building
Design solution
We introduced a summary detail setting that allows users to choose between “Standard” and “Detailed” summaries to match the needs of each session, without adding complexity to the interface.
The problem
Scribe was initially designed to be easy to use without requiring users to write raw prompts. However, we noticed that the more experienced users were already crafting informal prompts within existing fields. Without a structured way to do this, some users missed out on that flexibility, and the workaround was unintuitive.
Instant Conversation Overview
Summary Detail Controls
Custom Instructions Field
Dim Mode
The problem
Some users shared that the visible recording interface made clients more self-conscious during sensitive conversations, affecting the comfort and openness of the session. While transparency around recording is important, the interface needed to be less visually intrusive to support more natural interactions.
Design solution
We introduced a Dim Screen mode to darken the recording interface. This option keeps the recording status clear to the practitioner while reducing distraction for clients. It helps the practitioner stay engaged during emotionally intense or sensitive sessions, without compromising clarity or informed consent.
Design solution
We introduced an expandable "Add custom instructions" field in the Generate Summary modal. This allows users to optionally provide custom instructions to influence the summary output. To help less savvy users get started, the field includes placeholder text with a lightweight example reflecting a common need — such as quoting clients verbatim.
The process
User interviews revealed that while the more experienced users were already crafting informal prompts in the current fields, others didn’t realise prompting was possible. At the same time, some were satisfied using the existing fields to generate the summaries they needed. This pointed to a need for an optional prompt field that wouldn’t overwhelm the interface.
The problem
Some sessions require brief notes, while more complex ones, such as those involving suicide ideation or family violence, require more detail. Many users shared that Scribe’s summaries were often too short, leaving out key information and requiring extra time to edit.
The process
Summary length was initially constrained by token limits in the underlying LLM model, which helped reduce hallucinations but also restricted detail. I worked with an engineer on the team to test backend prompt variations, allowing summary length to be customised without compromising on accuracy.
Outcome
In the week after release, 60% of summaries were generated using the Detailed option, suggesting strong demand for richer summaries.
Outcome
After launch, the percentage of sessions with a manually generated summary dropped from 75.9% to 61.2%, suggesting the overview meaningfully reduced effort for many users.
Design solution
From this insight, we realised users didn’t need Scribe to generate headers — they just needed help recalling the conversation. To support this, we introduced an auto-generated Instant Overview that surfaces key topics, observations, decisions, and follow-up actions. This aids memory while preserving user control over how their documentation is framed.
The process
We tested two concepts: auto-suggested headers, and a short conversation outline within the “Generate Summary” modal. Users found suggested headers unhelpful due to wide variation in how they typically craft their headers. The outline proved more useful for aiding recall.
The problem
Scribe relies on user-provided headers to generate summaries, but after long or emotionally intense sessions, users often struggled to remember enough detail to craft them. In these moments, recall became a barrier — leading some users to ask if Scribe could suggest headers for them.
Future plans
With the feature newly launched, we will be gathering qualitative feedback on how users are interacting with the prompt field. This will help us understand common use cases and uncover opportunities to improve guidance or expand prompt functionality in future iterations.
What We Explored (But Didn't Ship)
Match My Writing Style
The problem
Some users wanted the summaries to better reflect their personal writing style. Over time, they felt Scribe’s outputs started to sound repetitive and lacked their own professional voice. As a result, they often found themselves editing the summaries to match their usual tone and phrasing.
The process
We explored two possible concepts. The first was to allow users to upload a sample case note under their profile, so Scribe could apply a consistent writing style across all sessions. The second was to give users the option to provide a sample in the Generate Summary modal, offering more flexibility to tailor summaries for specific use cases.
Our findings
Appetite for the feature was low. Most users felt uploading samples wasn’t worth the effort and preferred refining summaries themselves — seeing it as a valuable part of reflection and clinical reasoning.
Supervisors also raised concerns: if Scribe could closely mimic a user's writing, it would be harder to assess their staff’s actual work. Some worried this level of automation could hinder the development of professional judgment and writing skills, especially for junior practitioners.
Our decision
We decided not to move forward with this feature, as it risked crossing the line between support and over-automation — potentially making professionals more passive in a process many see as core to their craft. A few senior social workers shared that documentation isn’t just admin work; it’s how they reflect, think, and take ownership of their practice. The team felt that Scribe should support that process, not replace it.
Concept 1: Upload sample under profile
Concept 2: Upload sample within the Generate Summary modal
Impact and What's Next
Though many of these features were only recently released, early feedback has been positive. Many shared how the instant overviews made a real difference in helping them quickly recall key points from their conversations. They also appreciated the flexibility to control the level of detail in the summary output, which saved them time and made the summaries more usable, with fewer edits needed.
Moving forward, we’ll continue monitoring metrics on summary usefulness and documentation time savings, alongside regular check-ins to understand how the new features are being received. We’re also beginning early user and technical exploration into potential features like drawing context from past conversations and AI-augmented editing to assess their value and viability.
Estimated total documentation time saved with Scribe
Average % documentation time saved per session
Usefulness of summary
61.9%
16,853 hours
3.86 / 5
2,756
Active users
Afterthoughts 💬
Scribe reminded me that restraint is part of good design. As we expand Scribe to support more user groups, it is tempting to address every need with a new feature. But layering on too much complexity could turn a helpful tool into a burdensome one, ultimately leading to user drop-off.
Our deep research helped us distinguish common needs from edge cases that didn’t justify the added complexity. This informed our product vision and ensured the roadmap served the majority of users while keeping Scribe focused and easy to use. We also recognised the importance of keeping Scribe as a supportive tool, without displacing or weakening the professional judgement and practice wisdom of its users. It is meant to reinforce the human expertise behind every piece of documentation, not replace it.