Jano Health / Product design
A doctor's interface for chronic care.
A mobile product that helps doctors see what needs attention, recover patient context quickly, and act without adding to their cognitive load.
- Role
- Product Design Owner
- Scope
- Strategy, interaction design, system, prototype
- Status
- In user validation
Chronic care happens everywhere.
Chronic care does not happen in one place. A patient's care journey crosses the hospital, home, care team, calls, WhatsApp, paper records, lab reports, and follow-ups.
At the hospital front stage, doctors work through short consultations with scattered records and limited time. At the backstage, operations teams manage paperwork, audits, and coordination with limited clinical context. At home, symptoms, external tests, and patient messages can remain invisible until the next visit.
01 / 04
Jano's ambition is to connect these moments. The Doctor App was a focused entry point into that larger vision: connect communication, integrate clinical data, and support continuous care.
Doctors were repeatedly reconstructing the patient's story.
I worked with Sudarshan, Jano's co-founder, and Monisha, a design researcher, to understand the system through the people delivering care. Interviews with nephrology specialists before V1 pointed to the same underlying problem.
- 01
Compare current and past values
- 02
Piece together notes and reports
- 03
Track whether instructions became action
- 04
Coordinate urgent care across several teams
- 05
Duplicate documentation across systems
- 06
Keep fast communication tied to the clinical record
A later follow-up with a doctor reinforced the need for a coherent patient history, useful trends, clear documentation, and timely communication. That research led to four principles.
Start with what needs attention.
Do not make doctors search through a feature menu.
Preserve the care story.
Link visits, reports, messages, prescriptions, and treatment changes.
Make the next action easy.
Reduce steps without removing clinical control.
Keep AI quiet and accountable.
Surface context and speed up work without opaque clinical decisions.
From the patient record to the doctor's day.
I planned the product in two steps. V1 established the core patient record. V2 expanded that foundation into a broader Doctor App. V1 was the deliberate focused prototype that could be tested before the team committed to the full experience.
V1
The patient profile
V1 centered on a patient record. It brought together a finite needs-attention queue, quick access to prescriptions, notes, reports, and communication, plus a longitudinal timeline.
The information hierarchy was intentional: patient identity and current context first, then items that need review, fast clinical actions, and finally the longer history needed to make sense of a decision. The timeline was a structured record of a care relationship, not an activity feed.
v1 prototype
V2
The doctor's day
V2 expanded the product from a patient-level record to a doctor-level decision surface. The landing experience gives doctors an immediate view of their day across hospitals: appointments, referrals, inpatient and outpatient work, and unread patient conversations that need attention.
The goal was not to make doctors navigate a larger database. It was to help them move from “What should I handle next?” to the right patient and action with as little friction as possible.
v2 prototypeLoading live prototype
AI is an interaction layer, not a destination.
Ask Jano lets doctors ask questions in the context of their day or a patient record. Responses can lead to a relevant patient, report, note, prescription, or schedule. It should shorten the path to context and action, not hide uncertainty, make unreviewed clinical decisions, or ask doctors to trust a black box.
A system, not only screens.
Static Figma handoff was not enough for a product this connected. I built a working React prototype and component library with Claude Code, using atomic design to turn the experience into a reusable system. Design tokens established the visual and interaction language; reusable components formed clinical workflows such as patient cards, timeline events, message rows, appointment cards, and the AI dock.
Product value met market reality.
The prototype received positive informal feedback from doctors and at medical-conference demos, but formal validation is still underway. The larger constraint was commercial: doctors were the daily users, but hospitals were the buyers. Integrating legacy systems required leadership alignment, procurement, finance approval, and a longer enterprise sales cycle than the team had anticipated.
That learning is shaping Jano's next move. The team is exploring Bolo, a smaller communication product derived from the chat flow, an adoption wedge that does not wait for full hospital-system change. The Doctor App remains the expression of Jano's larger chronic-care vision.
Learning
The hard part was deciding what to surface, what to defer, and how to keep doctors connected to a patient's evolving story.
I took the work from a chronic-care service problem to research synthesis, product strategy, interaction design, a reusable design system, and a working prototype ready for validation and implementation, with human judgment at the center.
Impact
A validation-ready product foundation.
Formal clinical validation is still underway, so the impact is framed around project outcomes: what the work clarified, produced, and made testable for the next stage.
- 6doctor reconstruction tasks
- Recurring clinical work translated into concrete design priorities.
- 4product principles
- A shared decision frame for attention, story, action, and accountable AI.
- 2prototype horizons
- V1 patient record and V2 doctor-day experience connected into one system.
- 1working React system
- Reusable prototype and component library prepared for validation.