Healthcare · Munich · end-to-end practice

One practice, two patient journeys.

SmartPraxis is a Munich general-medicine practice rebuilt around two journeys: #gesundwerden for acute and reactive care, #gesundbleiben for prevention and long-term health. Everything else follows from that split.

ROLE
Product Designer
WHEN
Feb 2025 – Aug 2025 · Munich
SCOPE
IA · booking flows · video consultation · content · patient app
TOOLS
Figma · Figma Make · Claude · Jira
Smart Praxis brand cover
A practice as a product. Website, booking, video consultation, e-prescriptions and records under one information architecture.

/01 — the situation

One booking queue for four different visits.

German Hausarzt practices run on fragmented tooling and paper-heavy admin under Telematikinfrastruktur and eRezept rules. A one-size-fits-all booking page mixes acute, chronic, preventive and family visits into a single queue — eroding capacity and patient satisfaction.

2patient journeys
6segmented booking flows
1patient app in development
HZVproductised as loyalty
Smart Praxis website with Gesund werden and Gesund bleiben in the primary navigation, an online reception widget and a premium check-up call to action
The two pillars, in the navigation. Gesund werden and Gesund bleiben sit at the top level, so acute care and prevention stop competing for the same entry point — and the online reception stays docked on every page.

There was also no native mobile surface, so nothing kept patients engaged between visits — which matters most for exactly the preventive and chronic care the practice wanted to grow.

/02 — the approach

Segment the queue, then build around it.

An end-to-end digital practice on top of arzt-direkt.de with six segmented booking flows — acute, follow-up, preventive check-up, vaccination, chronic/HZV and family — plus open video consultations, digital follow-up prescriptions, and a content layer that markets the HZV Hausarztprogramm as a loyalty model.

The two-pillar architecture is the load-bearing decision. Once #gesundwerden and #gesundbleiben exist as separate journeys, the booking flows, the content and the app navigation all have an obvious place to live.

The system extends into a native patient app for iOS and Android, in development, covering booking, video calls, prescriptions and records under the same information architecture.

DECISION

Split the journey before designing the screens

Segmenting demand is an information-architecture decision, not a scheduling feature.

CHOSE
Two named patient journeys as the top-level structure
OVER
A single booking page with filters and categories
COST
Every new service has to be assigned to a pillar, and some genuinely straddle both
[FILL] — PROCESS & SCREENSProduct screens, flows and process artefacts for this case. The live site has a screenshot set; higher-resolution versions and one before/after belong here.

/03 — the booking assistant

Ask two questions before offering a slot.

Segmenting demand only works if the segmentation happens before the calendar opens. The assistant asks what the visit is for and how the patient is insured, then shows only the appointment types that actually apply — with duration and constraints stated up front.

Four steps of the Smartbot web assistant: choosing an intent, selecting insurance type, comparing acute appointment types with durations, and picking a doctor and time with a five-minute hold
Intent, insurance, then time. Appointment · prescription · sick note · open video consultation · HZV · check-up packages, filtered by statutory, HZV or private cover — and each option states its duration and its limits, so a five-minute video slot is never booked for something that needs an examination.

The five-minute hold on the chosen slot is the small detail that decides whether the flow works: without it, two patients race for the same time and one of them is told no after entering their details.

Stating what an appointment type cannot do — no examination in a video consultation, no long-standing complaints in an acute slot — is what keeps the segmentation honest. A queue only stays sorted if patients can sort themselves correctly.

/04 — the patient app

The practice, between visits.

A website ends when the tab closes. The native app is where the prevention pillar actually lives — the part of the relationship that has to survive the months when nobody is ill.

Patient app screens: welcome, home with popular services and symptom entry, family profiles with documents and access rights, emergency contacts, insurance and billing, doctor comparison and appointment confirmation
One account, a whole household. Family profiles with their own documents, access rights and quick actions — because in general medicine the person booking is often not the patient, and the parent managing a child and an elderly mother is the norm rather than the edge case.
Patient app: find a doctor with service filters, doctor profile with availability, my appointments with upcoming and completed tabs, and appointment detail with preparation and document upload
Preparation as part of the appointment. The detail view asks for documents and preparation before the visit rather than at reception — the same instinct as the booking assistant, moved one step later in the journey.

Insurance and billing carry the German reality: what was spent, what the insurer covered, and what is still pending — the questions a Hausarzt practice answers by phone every day.

The app is in development for iOS and Android; the screens here are the designed system, not a shipped store listing.

/05 — outcome

A digital practice, live.

  • Two-pillar practice architecture live — #gesundwerden / #gesundbleiben
  • Six segmented booking flows shipped on arzt-direkt
  • Open video consultation and digital follow-up prescriptions live
  • HZV Hausarztprogramm productised as a patient-loyalty offer

[FILL] What would be done differently, and the honest failure or reversal from this project.