Welbe Care

Welbe's medical network had no structured way to capture a patient's clinical background before a consultation. Doctors started every appointment from zero — re-asking the same questions about allergies, chronic conditions, family history, and current medication — which slowed consultations down and left gaps in the data Welbe needed to power preventive-care analytics for its enterprise clients.

The goal was a Historia Clínica experience where patients complete their own medical background once, in plain language, while doctors get a standardized, code-based clinical record to rely on and build on at every subsequent visit.

Design question: How might we let a layperson accurately self-report ten categories of sensitive health information, while feeding a data model rigorous enough for a doctor to use clinically?

Unlike a typical discovery built on user interviews, this project's discovery was shaped by working directly with a Product Manager with a clinical background — translating medical requirements into the right questions, in the right order, with the right classification.

Partnered with the PM to define clinical accuracy for every question, while keeping language understandable to a layperson.

Mapped the ten-step patient journey, sequencing sensitive topics (family history, addictions, medication) so it felt progressive, not invasive.

Defined, with the PM, which fields doctors needed to see and edit once patient data reached them — standardized coding, treatment status, comments.

Used Claude to organize the question set, structure the step-by-step flow, and accelerate wireframe exploration.

Ten sequential, self-contained steps for the patient; a persistent tab structure (A.H.F → A.P.P → A.P.N.P → Vaccines → Diagnostics → Medication) for the doctor.

Mapped every patient path, including yes/no branching, alongside the doctor's review-and-edit flow. Validated both structures separately in low-fidelity before merging into one system.

One question per screen on mobile for patients; dense tables and standardized inputs on desktop for doctors. Built navigable prototypes for both, validated with the PM.

Documented the full solution, including new form-state components, and handed off to Engineering.

New reusable components contributed to Welbe 2.0: yes/no answer-state components, the antecedent row pattern, the ICD-10/CIE-10 lookup field, the progress-step header, and the clinical record tab navigation — all reused elsewhere at Welbe.

Unlike other Welbe projects, this one didn't involve a contested design decision to defend. The core challenge was translation — taking clinically precise requirements from a PM with medical training and shaping them into an experience two very different audiences could each use confidently, from the same data.

Designing for two audiences on one data model requires resisting the urge to solve it with a single interface. Holding both without compromising either — while staying tightly aligned with a subject-matter expert instead of running a traditional discovery process — was the real design problem to solve.

Welbe operates a B2B2C model: companies purchase health benefits, employees use them, and HR teams get administrative and analytics capabilities. Large enterprise clients, including Bimbo and MetLife, required a new benefits model based on usage quotas — each employee gets a limited number of subsidized consultations or exams, and must be able to purchase additional services directly through the platform once that limit is reached, without depending on Welbe's support team.

This required a completely different experience from the existing app, plus digital payments integration via Stripe.

Design question: How might we make benefit quotas, out-of-pocket payment, and appointment booking understandable in one continuous journey — without forcing employees to contact support?

All of this needed to feel intuitive, even for users who had never used this kind of corporate benefit before.

This project didn't include direct user interviews, but the full discovery process was run in close partnership with business stakeholders.

Met with the PM and business teams to understand the new enterprise clients' specific needs and every rule behind the quota model.

Audited the legacy app flow end-to-end to identify limitations, friction points, and improvement opportunities before proposing a solution.

Researched healthcare platforms and digital-service purchase experiences to understand market patterns for booking and payment journeys.

Structured the full flow architecture in Miro, covering dozens of scenarios related to quotas, payments, lab confirmation, and scheduling.

Used Claude to organize requirements, structure flows, and accelerate the first wireframes before prototyping.

This project carried far more complexity than a typical checkout. It required holding, in one journey:

In total, the project resulted in approximately 45 responsive screens, covering every possible journey scenario.

Structured navigation flows accounting for the different states a user's journey could be in — quota available, exhausted, family-linked, or fully paid.

Mapped every possible path to guarantee consistency between business rules and user experience.

Built low-fidelity wireframes to quickly validate the flow's structure before layering in visual design.

Evolved into high-fidelity interfaces using Welbe's Design System, once the wireframes were validated.

Built navigable prototypes for validation with the PM and stakeholders before development began.

Documented the complete solution and ran full handoff to Engineering, following implementation alongside the technical team.

Identified components that didn't yet exist in Welbe's Design System, used them in the flow, and formally incorporated them into the company's shared library: quota cards, benefit cards, discount indicators, payment-status components, exam cards, lab information blocks, and new reusable visual patterns — now used across other products on the platform.

During project reviews, Product, Engineering, and Design disagreed on the best way to present available quotas to the employee. My proposal prioritized UX principles — recognition over recall, visibility of system status, reduced cognitive load, and clarity on available benefits before purchase.

The entire project was delivered in approximately 48 hours of work spread across six days.

This project reinforced the importance of balancing complex business rules with a simple user experience, and demonstrated how UX-grounded decisions can influence Product and Engineering toward more intuitive, sustainable solutions across the whole platform.

Welbe's Design System spans five linked Figma files — Tokens & Components, Patterns, Modules, Templates & Pages, and Base-flows (WhiteLabel/Aura). As one of two Product Designers at Welbe, I share ownership of this system with Antonio — together we're responsible for creating and maintaining it as the single source of truth every product surface (App, WhiteLabel/Aura, Backoffice, Doctor and Médicos portals) is built from.

This section documents the foundation layer: Tokens & Components — the raw design tokens (color, typography, spacing, radii) and the base component primitives everything else in the system composes from.

Every token in the system is versioned across two modes — Welbe 1.0 and Welbe 2.0 — letting the team evolve the visual language (a shift toward a deeper teal, more saturated brand palette) without breaking any component still referencing the legacy mode. 461 variables across 4 token collections currently sit behind Welbe's entire product surface.

A scaled, semantic color architecture: global color ramps (gray, red, pink, purple, cyan, blue, teal, green, yellow, orange, and four brand-specific ramps — main, second, third, complement) each running 50→950, feeding a semantic layer (Wb-bg, Wb-border, Wb-text, plus status colors) so components reference intent ("success", "warning", "muted") rather than a raw hex value.

A single typeface — Inter — for heading, body, and mono roles in Welbe 2.0 (Welbe 1.0 used Montserrat for headings, one of the visual shifts the rebrand token layer absorbed). Nine-step font-size scale, full 100–900 weight range, five line-height steps, five letter-spacing steps.

A 4px-based spacing scale (2 → 384px) drives all gaps and padding. Corner radius follows its own scale — none to full (9999px, for pills/avatars) — with three semantic aliases (l1, l2, l3) mapped to specific steps so components reference "level 1 rounding" rather than a raw pixel value.

Every mockup in the two case studies above — the Historia Clínica questionnaire, the doctor's clinical record, the Estudios Médicos purchase journey — is built entirely from this token layer: the same teal scale, the same radius steps, the same type scale. Maintaining it alongside Antonio means every new flow at Welbe starts from a consistent, accessible, on-brand foundation instead of one-off decisions per screen.