The Mission

Designing the platform that runs a sick-leave case from start to finish, for teams who already have enough systems.

At a Dutch arbodienst, managing an employee's absence spans months and four parties: the casemanager who owns the case, the bedrijfsarts who owns the calendar, the werkgever who employs the person, and the werknemer who's out sick. The clinical judgment lives in the dossier. Everything around it, collecting client information, tracking the case, coordinating a single appointment, is drag that leaks across WhatsApp, Outlook, and voicemail. Happy is the platform that holds all of it: clients, dossiers, tasks, hours, quotes, invoicing, and scheduling. I owned the product design across that system, but this case goes deep on the two surfaces where the design problem was hardest: the dossier overview, where a sick-leave case has to stay legible to users who don't trust software, and scheduling, where coordination has to survive leaving the building.

The audience that shaped every decision

One concern runs underneath the whole platform: our users are not confident with software. Casemanagers are experienced professionals, often later in their careers, who will abandon a tool that makes them feel lost. And the outside parties, employers and employees, will never log in at all.

That single fact produced the two hardest calls in the product, and interestingly, it pushed in opposite directions on the two surfaces. On the dossier, protecting a low-confidence user meant showing more. On scheduling, it meant showing less. Same principle, opposite answers, because the anxiety is different when you're managing a case you own versus completing a task you never asked for.

scheduling, who picks the time?

Coordinating one appointment touches four people who don't share a tool, and the design has to survive leaving Happy entirely, because employers and employees will never log in.

That split the audience into three tolerances for complexity: power users (casemanagers) who want speed and control inside the dossier; professionals (bedrijfsartsen) who protect their Outlook calendar and won't adopt a tool that fights it; and occasional users (employer/employee) who abandon anything resembling another portal and just need a link that works on a phone.

The hardest fork was sequencing, someone has to pick the time, and every option traded control against effort:

Option A, casemanager picks, everyone confirms. Fastest for the team, but it makes the internal user guess two people's availability. The invite becomes a hope, not a commitment, the phone-tag we were trying to kill.

Option B, employee picks first. Cleanest in theory: the person who has to show up chooses. But employees are the least-engaged party, so putting the cold-start on them meant most bookings would stall at step one.

Option C, employer shortlists, employee confirms. The employer selects at least two preferred times; soft holds reserve them; the employee makes one final choice from that shortlist.

I chose C. It puts the heavier task on the more-engaged party and leaves the least-engaged one a single, near-frictionless decision. The soft hold keeps it honest: those slots are genuinely reserved while the employee decides, so the options are still available when the employee picks. It's the sequence least likely to die in the middle.