HAVEN

HAVEN is a self-initiated WEXILAR concept: an imagined healthcare platform, designed and built end to end to show how we approach a complex, sensitive digital product. It is not a real healthcare company, hospital, clinic or doctor network, it has no patients, and nothing in it is medical advice. Every doctor, patient, record and prescription in these screens is sample data.

The vision is simple to say: find the right care, see a doctor — face to face or from home — and keep every summary, result and prescription in one calm place. For clinicians, the same platform becomes a quiet workspace for the day.

A single visit to a doctor can involve a search engine, a phone queue, a portal login, a waiting room, an email and a paper letter. Specialty names rarely match how people describe what's wrong, so the first choice is often a guess. Video consultations exist, but joining one can feel like a test of your equipment. And afterwards, summaries, results and prescriptions scatter across inboxes and drawers.

None of these are clinical problems — they are experience problems. That is where design can help: fewer handoffs, plainer language, and one place that remembers.

Patients discover doctors and specialties, read real profiles, book video or clinic visits, prepare, consult online, and keep their records, prescriptions and health information together — with notifications that arrive when they are useful. Clinicians see their schedule and today's appointments, open a patient's information, consult, write notes and prescribe from one dashboard.

Both sides sit on the same shared platform — scheduling, consultations, records and notifications — so what a doctor writes is what the patient sees.

The HAVEN mark is a plus — care — held between two arcs, like hands around something that matters. The arcs never close: a haven shelters without shutting anyone in. It is drawn on a 32-unit grid from two 12-unit arcs of 110° and a 10-unit plus, all in one stroke weight. The wordmark is set in Figtree capitals, tracked wide so it reads calm and steady.

The app icon keeps the idea at its smallest — warm white arcs and a mint plus on deep teal — legible at 32 pixels on a crowded home screen.

The palette avoids the sterile blue-and-white of many clinical products. Warm whites and linen greys make the interface feel domestic rather than institutional; a deep teal carries every primary action; charcoal carries type. Soft sage, clay, sky and sand tints identify people and categories, and four status colours — always paired with words — mark what's ready, what needs attention and what's critical.

Figtree does the interface work: open letterforms that stay clear at small sizes and for readers who need larger text. Newsreader, an editorial serif, is kept for human moments — a greeting, a confirmation, a health guide. IBM Plex Mono labels tokens and references.

One token set drives two themes: the light product, and a dark consultation room where the video is the only thing that matters. On top sit the general components — buttons with one primary action per screen, inputs with focus and error states, tabs, chips, switches, navigation, modals, toasts and notifications — and a layer made for healthcare: doctor cards and rows, appointment cards, a time picker, prescription cards with supply left, record rows and health-data tiles.

Health readings are always shown as data with their source — never as a diagnosis. Every board below renders the live components from the prototype.

Home opens on the one thing that matters today — the next visit — with preparation and joining a tap away. Find care starts from specialties or a search in the patient's own words; a doctor profile shows languages, focus areas and where to find them; choosing a time, reviewing and booking take three screens. Before a video visit, a short checklist removes the technical worry; after it, the next steps are spelled out and linked.

Visits, records, prescriptions, health information, notifications, profile and settings complete the app. Every screen is a real route in the prototype, and the booking flow carries the chosen doctor and time from step to step.

Finding a doctor and booking: search, profile, time, review, confirmation — nothing is committed until the last tap. Having a consultation: the upcoming visit on home, a preparation checklist, the video call, and a clear summary of what happens next. Staying on top of care: records link to what was prescribed, prescriptions show the supply left, and general health information sits one tap away — labelled as information, not advice.

The clinician dashboard opens on today: the next patient waiting, with their allergy flagged before anything else; the day's appointments with their status; tasks — results to review, prescriptions to sign, notes to finish; and the week at a glance. A schedule view lays the day out on a timeline, the patient list and patient record bring notes, medicines and results together, and the consultation screen puts video, the patient's own question, a note editor and prescribing side by side.

The patients and schedules shown are sample data; the dashboard isn't connected to any clinical system.

On desktop, patients get a dashboard built around the next visit, their readings, prescriptions, recent records and a health guide; doctor discovery with filters, cards and a booking panel that stays beside the results; appointments with a calendar and history; records with a full visit summary; and profile and settings. It shares the app's tokens and components — it is the same product, not a separate site.

The phone is where most care begins, so the mobile app gets the most attention: large, calm type; one filled button per screen; generous touch targets; and a consultation room that goes dark so the conversation is the only thing in view.

At 1440 pixels the platform has a full sidebar; at tablet width it folds into an icon rail; on a phone it becomes a five-tab bar with stacked cards. The clinician dashboard follows the same rules. Tokens, data and components stay identical at every size — only the arrangement changes — and every layout was checked at 390, 768 and 1440 pixels.

To design the product honestly we sketched how it would work: patient app, patient web and clinician dashboard behind one API and integration layer; identity for patient and clinician accounts with passkeys; domain services for the directory, appointments, consultations, records, prescriptions and notifications; and a consent and audit layer deciding who can see which record, and when.

This architecture is illustrative. The prototype is a Next.js app running on sample data, with one token file and one component library behind every screen in this case study. No hospitals, clinicians, clinical record systems, pharmacies, labs, payment providers or production healthcare infrastructure exist or are connected.

HAVEN carries across the mobile app, the patient web platform and the clinician dashboard, down to the app icon — and into launch graphics built from the product itself: real screens and real components, never a promise the prototype can't keep.

The HAVEN prototype is live at wexilar.com/concepts/haven (patient web), wexilar.com/concepts/haven/app (patient app, best viewed at phone width) and wexilar.com/concepts/haven/doctor (clinician dashboard). It runs entirely on sample data.