ROY SHILOH

Product designer for complex AI products, clinical workflows, and technical B2B systems. Currently Head of Design at Berries, designing an AI-native clinical platform for mental-health professionals.

2024 —
Case study

Designing the core clinical workflow for an AI scribe and EMR used by mental-health professionals.

01 · Context

First designer, then Head of Design.

I joined Berries as its first product designer in 2024 and later stepped into the Head of Design role. I work directly with the founders, product, and engineering across the web product, the iOS/iPad app, the design system, and selected marketing surfaces.

Berries builds an AI-native clinical platform for mental-health professionals — an AI scribe that turns live sessions into structured documentation, connected to a lightweight EMR that covers notes, diagnoses, treatment plans, and an assistant.

02 · The problem

Documentation is the easy story. The clinical workflow around it is the hard one.

Before Berries, clinicians finished sessions and then rebuilt them from memory — typing notes late into the evening, reformatting the same content into insurance-ready documentation, and keeping context in their head between sessions with the same patient.

“Generate an AI note” is the trivial part. The real product problem is everything around it: moving cleanly from a live conversation into structured output without disrupting the therapeutic relationship, keeping the clinician in control of anything the AI produces, and making sure a note, a diagnosis, a treatment plan, and the assistant all share the same patient context without asking the clinician to stitch it together.

Safety is not a feature we bolt on. In mental health, the difference between “the AI wrote this” and “the clinician wrote this” is the difference between a helpful tool and a liability.

03 · My role
Team
Founders, product, 2 devs, myself as Head of Design.
Period
2024 — present.
I own
Product UX end-to-end, the shadcn-based design system, mobile app design, and the marketing surfaces I designed personally (site, PDFs, partner-facing material).
Before me
An early product built by the founders and engineering; no dedicated design function, no system.
Decision 01

How clinicians begin and manage a recording.

Problem
Sessions start unpredictably. A recording that fails silently, or a UI that pulls attention away from the patient, is worse than no scribe at all.
Options
A modal “start session” flow; a persistent recorder dock; auto-start on calendar match. Each pulls attention away from the conversation in a different way.
Decision
A persistent, low-attention session dock that stays put across the app. State is always visible; controls are one action away; nothing blocks the clinician’s primary view.
Result
Clinicians can move between patient context, prior notes, and the assistant while a session is running without ever losing the recording or wondering whether it’s live.

Persistent session state — the recording control never leaves the frame, so clinicians can move between documentation surfaces without losing the active patient or the live capture.

Fictional data
Decision 02

How AI-generated documentation is reviewed and completed safely.

Problem
A generated note that looks finished invites the clinician to sign without reading. A note that looks unfinished slows every session. In mental health, either is unacceptable.
Options
Auto-approve with an edit affordance; force line-by-line confirmation; a diff-like editor between draft and clinician edit. Each trades speed against safety differently.
Decision
The AI produces a structured draft; the clinician sees it as an editable working document, not a finished artifact. Nothing is signed until the clinician acts. AI suggestions in every downstream surface (diagnosis, plan, assistant) stay optional and reversible.
Result
Clinicians move faster than typing, but the note that gets signed is unambiguously their note. That framing is what makes the product usable in real practice.

Generated note as a working document — the clinician is the author, the AI is a first draft. No AI output ships downstream without an explicit clinician action.

Fictional data
Decision 03

How information moves between notes, diagnoses, plans, and the assistant.

Problem
A note, a diagnosis, a treatment plan, and an assistant are four separate surfaces. If each has its own idea of the patient, the clinician spends the session reconciling them.
Options
Shared sidebar; global patient header; each surface as a tab of a single “patient workspace.” Each shapes the mental model of the product differently.
Decision
One patient workspace. Notes, diagnosis, treatment plan, and the assistant are surfaces inside it — they read from the same context and write back to the same record. Navigating between them never loses the active patient.
Result
The clinician stops re-selecting a patient on every screen. The assistant answers with the patient it’s already looking at. New surfaces slot into the same shell instead of forking it.

Diagnosis surface — same patient context as the note and the plan; the clinician doesn't reselect.

Fictional data

Treatment plan — reads from and writes back to the same patient record.

Fictional data

Assistant — answers about the patient the clinician is already looking at.

Fictional data

Sessions index — the shell every workspace is entered from.

Fictional data
04 · Design system

A shadcn-based system that ships product and marketing from the same tokens.

I built the Berries system on a customized shadcn foundation. It was the right choice for a small team shipping fast: a familiar base for engineering, full control over primitives, and semantic tokens that carry across product surfaces and marketing without a second design layer.

The system covers color, type, spacing, and the component primitives that make up the clinical workspace. Marketing pages and PDFs consume the same tokens, so the brand and the product never drift.

05 · Mobile

iPad-first, because that's where the sessions happen.

The mobile app extends the workspace into the room the session happens in. It's the same design system, adapted for touch and for the specific moment where a clinician needs the fewest possible controls.

06 · Outcomes

Shipped to production, adopted by active practices.

Berries is in production and in use with active clinical practices. The iOS/iPad app has shipped. The design system measurably shortened the time between a decision and a shipped screen; new surfaces (assistant, plan, diagnosis) land inside the existing shell instead of forking it.

Specific metrics available on request.

07 · What I learned

Safety is a design property, not a disclosure line.

The hardest work on Berries was never generating the note. It was designing the boundary between AI output and clinician authorship, and holding that boundary visible in every surface — even when it made the UI slightly slower.

The second lesson: for a small team shipping into a regulated space, the design system is not a polish item. It is the fastest path from a founder decision to a screen a clinician can use.