How it was built, and why

The method

This vision was built over 10 days, mostly in a standalone prototype, with the deck and supporting documents alongside it. Roughly how it came together:

• I gathered the user research we already had from our customers, and the context our internal stakeholders carry, rather than running new studies.
• I analysed competitor interfaces, and the UI of adjacent products we can learn from: Grain, Fireflies, Otter, Notion, Google Docs, Confluence, Canva, Gamma and many more.
• I sketched initial user journeys and paper wireframes to find the shape of the workflow.
• I moved into initial Figma designs, then simple vibe-coded prototypes, before stepping up to a more complex Claude Code setup that could support what the project needed: a multi-screen, stateful, high-fidelity app.
• I built the prototype greenfield, deliberately not on today's splose, so the design was not constrained by the current app and could show a genuine future. It improved across unattended overnight runs that I reviewed each morning.
• I pressure-tested the prototype and deck by having eighteen AI leadership and team personas review it and provide feedback, surfacing the questions and objections each role would raise.

Throughout, I followed Canva's Vision Pieces framework, so the artefact does the job a vision piece is meant to do: credible and tangible over pixel-perfect, show more than tell, make the rationale visible.

The decisions

A selection of the calls, and why:

• Greenfield, not built on splose. To sell a real future, not a constrained clone of current state.
• Claude Code, not artifacts or Figma. A complex, multi-screen, stateful app needed real routing and reuse.
• A left navigation, and Create, Ask AI and search from anywhere. A top bar will not scale as we add to the product; the left rail frees the screen and gives those actions a permanent home.
• Helen, not a two-week newcomer. The vision is an end state for a working practitioner, and an established world shows it more richly. The "value from your first patient" point is told through Walter, a new client, and a rich, splose-populated template library.
• Capture as a full page, not a modal. It is the central act, and it flows into the editor.
• The note as an A4 document, not a form or simple text input (like some of our competitors). Clinicians trust and proofread something that looks like the record they sign, and prefer the customisation ability.

What I didn't do, and why

Naming these openly is the point, not hiding them.

• A mobile app. We know this is needed, but we still need to solve the web experience first.
• Additional AI features. Focused on this documentation workflow, not all the other AI things we could do, for now.
• A brand-new workspace experience. The story is told through an established practice on purpose; the empty-account moment is not built.
• Alternate ways to write a note. Starting a note from a previous one is included, but it needs much more thought, especially how AI should be involved. The focus here was generating a whole note from a capture.
• Capturing into an existing note. You can start a capture directly from a progress note, skipping the Create button, but how a capture adds to a note already in progress, rather than generating a fresh one, needs more consideration.
• A live model. Simulated by design, for safety and reliability.
• Properly solving standalone saved prompts and actions.
• Plenty more, which is exactly why I need your feedback, so we can iterate and add to this.