SAI
A clinical documentation platform built around the visit: ambient capture, a note in the physician's own voice, real-time clinical insight, and a straight path into the clinic's EHR. One product across mobile and web, shaped for physicians and nurses alike.
- My Role
- Product Designer
- Client
- Scrivas – Miami, FL
- Timeline
- Dec 2025 – Jul 2026
- Tools
The Brief
Scrivas is a clinical documentation company in Miami with 14 years in the field, founded and run by a practising physician.
They came to us to digitise their documentation process end to end: one place where a visit is captured, written up, reviewed, and sent to the clinic's EHR.
Nothing like it existed in their stack, so we started from zero: no legacy screens, no usage data, no patterns to inherit. The client stayed in the loop at every phase, including one-to-one calls with the CEO, the fastest source of truth we had.
The starting point
Scrivas came with material: their process, their market, their view of the users. I treated it as a starting point, not as answers, and ran my own discovery based on my experience and best UX practices.
Main Objectives
- Capture a full visit without breaking eye contact with the patient
- Make the AI in the room feel safe to the patient, not intrusive
- Deliver the finished note to the clinic's EHR with no second round of data entry
- Keep the physician free to create and edit visits on their own terms
Competitive landscape
A real, competitive category: almost entirely American, exactly our market. Most products sit behind clinic contracts, so I worked hands-on with a few and mapped the rest through documentation and recorded demos.
Target Users
- Physicians and nurses, who run the visit
- Clinic owners managing staff and branches
- Super admins across organisations
The recurring questions
Recurring surveys and interviews with the clinic's staff became a simple, repeatable research loop. Each round moved the conclusions forward, and kept returning to the same four questions:
How does a physician start recording in a single tap?
What does a clear interface for ambulatory work look like for its users?
How do we make reviewing and editing the generated note effortless?
How does the live assistant help without adding cognitive load?
Mapping the system
All roles see different versions of one product, built on one set of connected objects: visits, patients, templates, teams. I wrote out every workflow per role, then built the information architecture on top.
What we learned
Capture on the phone, paperwork at the desk
Every signal pointed to the phone: the most frequent request was a recording that starts in one tap. So mobile runs the visit, the web handles the work after it, and both still do everything.
The patient is in the room too
Being recorded by AI is a fair concern for the person being treated. So consent is spoken out loud, as part of the conversation, not a legal formality bolted onto the screen.
The EHR is the base, and we build alongside it
A note that lives outside the EHR is a second job waiting to be done. So: two-way sync, an export path never tied to one provider, and a database of our own.
The product should not dictate the order of work
A visit may start before the patient exists in the system and finish hours later. Everything stays editable, with one exception: a note cannot reach the EHR until a patient is linked.
Wireframes
Every screen of the product went through mid-fidelity greyscale wireframes before any visual decisions. We walked them with the client one by one, confirming the information architecture, the components and the content each role would see.
Design system
Platforms and roles do not hold together without shared foundations. I built the system myself, from colour variables and type scale to the component set the team shipped against. Light and dark themes were part of it from the start.
Two platforms, one product
Mobile is built around the visit itself, capturing the conversation as it happens. The web opens on the workspace: visits, patients, templates, teams, EHR status. Physicians and nurses work inside the same interface; the role decides what surfaces first, not a separate product. Both platforms do everything. What changes is the order they put it in.
Quick Start
Starting is the moment that decides whether the tool gets used at all. One tap on the home screen and the recording is already running: no patient to pick first, no form to fill in. The visit can be attached to a patient later, from the desk, once the consultation is over.
Voice Edit
Corrections are spoken, not typed. The physician talks to one section, and only that section is regenerated while the rest of the note stays exactly as it was. This took about three of the eight minutes saved per visit, and it is the part competitors did not have.
Responsive screens
The web side is not a desktop-only product. Physicians open it from a phone between rooms and from a tablet at the desk, so the screens were laid out at tablet and mobile widths as well, not as a shrunken copy of the desktop but as their own arrangement of the same components. Holding all three widths keeps the design system honest: a component that only works at one width is not a component.
What we measured
Three measurements, each run twice: once on a clickable prototype before development started, and again on the live product. The same six physicians both times, the same written scenarios: how long the work took, how many people finished it unaided, and where the eye actually went on the screen. The first round earned its keep straight away. Almost every physician raised the same problem: components on the creation screen were hard to read. The interface was reworked before the second round, a change that cost a week at prototype stage and would have cost far more after the code was written.
Time on task
How long the same scenario took, before and after. Two of the three got faster, roughly eight minutes off a single visit. The third did not move: building a template out of six structured fields took 39 minutes on the prototype and 38 in production, which is noise, and both sit above the industry average of about thirty minutes.
Heatmaps
Predicted-attention maps run across the key screens at 1440×984, on the old layout and on the reworked one, to see where the eye goes before a single physician is asked to look. In the old screens attention pooled in text. The recording indicator, the one element that tells the physician and the patient that SAI is listening, held just 7% of it. After the rework it holds 20%, and the primary actions on both screens gained six points of visibility each. Predicted attention, not live eye-tracking: directional evidence, checked against the task rounds.
Completion rate
How many of the six finished each task unaided. Round one is where the gaps showed: three of six on voice editing, four on section editing. Those numbers are what justified the rework, and the second round came back six of six on every task.
Worth stating plainly: these physicians had used comparable tools before, took part in the product's development, and every session began with a written brief. Six of six says the flow held for experienced users, not that it would hold for someone seeing it for the first time.
Iteration
Both screens show the same part of the product: the generated note and the sections inside it. The one on the right came out of the first round of interface testing with practising physicians. Their feedback reshaped how a section is acted on, and moved the controls to where the work actually happens.
What I would keep, and what I would change
Testing at prototype stage
The consent flow
The scope of validation
One expert user is not a user base
Like what you've seen?
This case is a small slice of what I can do. If you are looking for a product designer, or your product could use the same depth, from first research to shipped and tested screens, get in touch.