Healthcare & workforce SaaS · Germany

Two suites. Nine core applications.

Two companies with decades of their own history came together as one, leaving overlapping products that solved the same problems in different ways. I led the design that consolidated them into two software suites — Cairful and Timeful — and nine core applications.

ROLE
Senior Product Designer
WHEN
Aug 2024 – May 2026 · remote
SCOPE
Audit · research · design system · web migration · rebrand
SCALE
5,000+ organisations · 12 countries
LIVE PROTOTYPEGUIDED TOUR · YOURS TO DRIVE
LOADING PROTOTYPE
Cairful & Geocon shift planning interface shown on a laptop

/01 — the interface

Four rows of tabs before you reach the field you came for.

These are the products themselves — six compiled prototypes, embedded through this case where each story lands: PEX for the round on a phone, PAX for tour planning at the ward, DIX for shift planning, the Mitarbeiter-Portal for the employee’s own view, the management dashboard, and DOX — the route to one record. Mockups follow each one as supporting visuals. Guided flows walk their surfaces; take over at any point and click through on your own. They sit first because the argument of this case is visible in it before it is written down: care documentation is a navigation problem wearing a data-entry costume.

Names, values and dates in the prototypes are illustrative; the flows, structure and labels are the products’ own.

/02 — the situation

A merger left two ecosystems solving the same problems twice.

Geocon has served the German care sector for 27 years. It came together with Cairful — two previously independent companies, each with decades of its own history — and the result was two parallel product ecosystems: overlapping functionality, duplicate features, conflicting workflows, and customers who often used applications from both portfolios in the same working day.

12 → 9applications, after consolidation
2software suites — Cairful, Timeful
5,000+customer organisations
600,000+scheduled employees

The customers are the organisations that carry German care: Caritas, Diakonie, AWO, DRK, Korian, Alloheim. In a nursing home the same shift is planned by a manager on a desktop, staffed by a nurse holding a phone in a corridor, and documented on a tablet at the ward station — inside rules neither of them can negotiate. Cairful covers care documentation, scheduling, billing and controlling; Timeful is the open workforce-deployment system alongside it.

Fragmentation of this kind is rarely a visual problem first. Each application had its own answer to the same recurring questions: how a person is searched for, how a list is filtered, how a status is confirmed, what happens when something is overdue. Staff moving between applications carried none of their learning with them, and every new feature had to re-decide problems the company had already solved somewhere else.

There was also a commercial edge to it. Care organisations buy suites, not screens; a platform that behaves like nine separate products is harder to sell, harder to train and more expensive to support — a cost paid every day, quietly, by everyone.

/03 — how I worked

Audit the whole portfolio first. Then go and watch the work.

My first objective was to understand the ecosystem at a systems level. I ran a full product audit across the whole portfolio, mapping user journeys, feature sets, workflows and technical dependencies — and the pattern was unambiguous: the products solved many of the same problems in different ways.

That insight changed the scope of the work. Instead of treating each application as an isolated product, I repositioned the portfolio as a connected ecosystem — one experience that could carry existing customers and still leave room to grow.

Then I went to the work itself. Geocon had shipped successfully for 27 years on domain expertise and customer proximity, but never with structured user research. I ran field research inside our testing clinics and care facilities, observing care staff, administrators and coordinators through their daily routines. What surfaced were inefficiencies, workarounds and unmet needs that stakeholder interviews had never shown: excessive navigation, duplicate data entry, and manual processes so old they had stopped being visible as problems.

Those findings became the basis for both product improvements and entirely new features, prioritised around reducing cognitive load for people working fast, with little time and very mixed technical confidence.

The other half of the job was upward. At this scale design decisions are roadmap decisions — what gets unified first, what stays untouched, what a customer feels in the next release. Daily calls with a cross-functional team of product managers, developers, testers and designers kept that moving; monthly, I presented progress, decisions and upcoming work to the wider company.

The second half of the job was upward, not downward. Design decisions at this scale are roadmap decisions — what gets unified first, what stays untouched, what a customer will feel in the next release. I worked directly with the executive level so those trade-offs were made once, deliberately, rather than re-negotiated per feature.

[FILL — research specifics for the published version: number and type of sessions, sites visited, which findings changed the roadmap. Keep only what can be defended in a reference call.]

[FILL] — RESEARCH & PROCESS ARTEFACTSField notes, interview synthesis, service blueprint or flow maps. The evidence that the research happened, not just the claim.

/04 — care documentation

Documentation has to survive the corridor, not the demo.

The Cairful side is used during care, not after it. The design problem is not richness — it is how few actions a task can take when the person doing it is standing up, holding a phone, and being interrupted.

FLOW 01 — PEX Flow3 FLOWS · GUIDED TOUR · YOURS TO DRIVE
LOADING PROTOTYPE
1.1Guided tour — loading…
Point of care, not point of desk. The challenge: care documentation written hours after the moment, on desktops the shift never sits at. I designed for the corridor instead — the round as the unit of work, due tasks per resident, confirmations in thumb reach, and a single Versorgungskritisch filter that surfaces the overdue without a report. Cutting mobile scope to what one hand can do was the senior decision; everything else follows from it. Three guided flows — take over at any point.
Inside this prototype — three guided flows: Zwischenmahlzeit, a snack round documented resident by resident with fixed amount chips and an oral-versus-intravenous switch; Wundversorgung, wound care confirmed at the point of care; Versorgungskritisch, one filter that surfaces overdue residents without opening a report.
Care documentation app open on a phone held in one hand, showing a snack round with residents, drinking log and medication entries
One-handed by default. A round opens as a list of residents with the tasks due for each; confirmations sit under the thumb, and what is overdue is visible without opening anything.
Four phone screens showing drinking log entry, a group activity with resident states, and hydration progress over seven days
Values people can hit without aiming. Fixed amount chips instead of a number pad; group activities that surface absence and transfer needs before the round starts; hydration shown as progress rather than as a table.
Tour documentation on a tablet, showing residents in parallel columns with times and tasks
The same tour view on a tablet in a darker setting
Same model, different posture. At the ward station the tour becomes parallel columns — several residents at once, the next activity always in view — because a tablet is used seated and shared, where a phone is used moving and alone.

Every entry in these screens is a record someone can be asked about later. That pushes the interface toward explicitness: amounts chosen rather than typed, oral versus intravenous stated, an entry confirmed and timestamped rather than silently saved. Speed comes from removing steps, never from removing the record.

FLOW 02 — PAX4 FLOWS · GUIDED TOUR · YOURS TO DRIVE
LOADING PROTOTYPE
1.1Guided tour — loading…
Density with rules, not drag-and-drop folklore. Tour planning packs dozens of interventions into quarter-hour slots per resident — exactly where scheduling tools drown. I defined a select-then-place interaction, a QN qualification colour grammar the eye can audit, three zoom densities and three shift windows instead of endless scroll. Designing the constraint system rather than one more screen is what keeps planners fast and plans legible. Four guided flows — take over at any point.
Inside this prototype — four guided flows: Plan & Dichte, the tour board read at three zoom densities; Vorrat, the intervention backlog with resident and qualification detail; Einplanen, select-then-place scheduling into quarter-hour slots; Schicht & Woche, shift windows and the week view.
Legacy tour planning board: saturated colour blocks and full sentences filling every quarter-hour cell Redesigned PAX board: intervention backlog on the left, residents in parallel columns, quiet chips per quarter-hour
The same board, before and after. The legacy planner filled every cell with saturated colour and a full sentence — a wall that can be read but not scanned. I kept the parallel-column model planners depend on and cut the noise: colour carries qualification, the chip carries the intervention, and white space does the separating. Toggle to compare.

/05 — shift planning

Planners don't want simpler. They want denser, and readable.

Timeful is the other extreme: a month of shifts for a whole care home, on one screen, edited for hours. Here the temptation to "simplify" is exactly wrong — the work is comparison, and comparison needs density.

FLOW 03 — DIX Flow6 FLOWS · GUIDED TOUR · YOURS TO DRIVE
LOADING PROTOTYPE
1.1Guided tour — loading…
Planners asked for denser, not simpler — I listened. The redesign instinct says dissolve the grid; the evidence said keep it and give density a grammar: colour for state, weight for kind, position for time, running balances always in view. Knowing when not to simplify — and writing rules that make complexity readable — is the decision this screen argues. Two further modules carry the same rule set through the month: external time capture, where plan meets terminal booking, and the Soll/Ist balance with its approval chain. Six guided flows — take over at any point.
Inside this prototype — six guided flows: Dienstplan, shifts assigned on the monthly grid; Mitarbeiter, the employee profile; Auswertung, target versus actual hours; Dienste, shift types configured with times and breaks; Zeiterfassung, terminal bookings compared against the plan with six deviation types; Saldo, monthly target-versus-actual balances with an approval chain and history.
Legacy GeoconPRO+ duty roster: a dense Windows grid of colour-coded shift abbreviations across a month Redesigned DIX Dienstplan: the same month with staff rows, shift chips, qualification and running balances
The same month, before and after. The legacy plan was already dense — a Windows grid of colour-coded abbreviations, readable only to someone who had memorised the codes. I kept the density and gave it a grammar: colour carries the shift, weight carries the kind, position carries the day, and the balance stays in view. Toggle to compare.
Monthly duty roster grid showing staff rows, days as columns and running balances
Density with a grammar. Staff as rows, days as columns, balances carried at the right — with weekends, qualifications and absences encoded consistently enough to be read at a glance rather than decoded.
FLOW 04 — DIX Portal Flow4 FLOWS · GUIDED TOUR · YOURS TO DRIVE
LOADING PROTOTYPE
1.1Guided tour — loading…
One model, two postures. The roster planners steer is the same roster employees live by. Instead of a second product, I projected one data model into an employee surface: my month, my balances, a proposal flow with honest pending states. Role-specific projections over duplicated features — cheaper to build, coherent to learn, and the merger’s whole thesis on one screen. Four guided flows — take over at any point.
Inside this prototype — four guided flows: Plan lesen, reading the personal month; Tagesdetail, one day in detail; Tagesmarker, markers for deviations from the plan; Änderung, proposing a change with honest pending states.
Personal shift calendar showing a month of shifts with a colour-coded legend for request states
The same month, from the other side. Employees see their own plan, request shifts and report absence; every state a request can be in is named in the legend rather than implied by colour alone.

Two audiences, one dataset, opposite needs: the planner optimises coverage across a whole house, the employee wants to know what their next four weeks look like and whether their wish was accepted. Splitting them into separate mental models would have doubled the maintenance; sharing the model and changing the density was the cheaper and more honest answer.

FLOW 05 — Dashboard4 FLOWS · GUIDED TOUR · YOURS TO DRIVE
LOADING PROTOTYPE
1.1Guided tour — loading…
A dashboard scoped by taxonomy, not appetite. Management asked for everything on one screen — the request that kills dashboards. I turned the client brief into a card taxonomy with period and filter discipline, and pushed depth into detail-on-demand modals instead of more widgets; „Karte hinzufügen“ makes growth a system property, not a redesign. Four guided flows — take over at any point.
Inside this prototype — four guided flows: Überblick, occupancy and period filters; Aufgaben, open tasks by category; Klinik, clinical indicators and Zustandserhebungen per resident; Referenz, the card taxonomy the board grows by.
Employee master data screen with tabbed sections, search list and per-field edit and history controls
Enterprise depth, without the enterprise mess. Master data carries tabs, per-field editing and a history control on each value — because in an audited environment the question is rarely "what is it now" but "what was it then, and who changed it".

/06 — the migration

1,500 local installations, moved onto the web.

Organisations were running physically installed software — setup, maintenance and device-bound access, with the overhead landing on customers and support alike. I led the design of the move to a unified web and mobile experience: sign in, and the applications are there, on any device.

This is the part of the project with real operational risk attached. These are live systems inside care homes; the migration had to preserve what administrators, nursing staff, schedulers and operational managers depended on while removing the installation barrier entirely. Getting it wrong would not have been a design problem — it would have been a shift that could not be planned or documented.

It is also what made everything else compound: once the ecosystem was reachable from anywhere, one design system across it produced one experience rather than twelve local variations of one.

/07 — the design system

One system, applied to work that has nothing in common.

The unification was not a visual refresh. I designed and implemented a shared design system spanning both suites — a common visual language, interaction patterns, a component library, accessibility standards and a design governance model. For the first time customers experienced the portfolio as one ecosystem rather than a collection of disconnected tools.

Colour, type, spacing and elevation became variables rather than decisions. Search, filtering, confirmation, overdue states, destructive actions and history were specified once and reused. The visual language was pulled tight enough to be recognisable across two brands, and loose enough that a documentation app on a phone and a planning grid on a desktop could both use it without pretending to be the same product.

The governance model is the part that outlives me: not the components themselves but the rules for how the tenth application gets designed — who decides, what gets promoted into the core, and what a team is allowed to solve locally.

The rebrand rode on the same rails and shipped publicly at Messe ALTENPFLEGE in Essen in April 2026 — the point at which the system stopped being an internal argument and became the face of the company.

[FILL] — TOKENS, COMPONENTS & PROTOTYPEComponent library, token sheet, and a short screen recording of the interaction model in motion. An animated prototype belongs here.
DECISION

Unify the interaction model, not the interfaces

The fastest visible win would have been a single skin over everything. The durable one was slower and less photogenic.

CHOSE
One shared model — tokens, components and interaction rules under both suites
OVER
A visual refresh applied application by application
COST
Slower first release, and every later change has to hold for nine applications at once

/08 — the interface, up close

Six levels deep before a nurse writes anything.

Care documentation is a hierarchy problem before it is a screen problem. A record sits at the end of a route through provider, house, living area, area, resident and care plan — and the software has to make that route feel like one place rather than six.

FLOW 06 — DOX Flow5 FLOWS · GUIDED TOUR · YOURS TO DRIVE
LOADING PROTOTYPE
1.1Guided tour — loading…
From six levels deep to one record. The legacy asked six navigation levels of a nurse before she could write. I led the consolidation of that route — resident-first entry, the record as the destination, documentation and evaluation on one spine — the pattern that let two merged suites behave like one product. Five guided flows — the fifth opens the full resident record: master data, contacts, pharmacy, consents and the care plan behind one card — take over at any point.
Inside this prototype — five guided flows: Schicht, the shift dashboard; Bewohner, the resident list; Akte, the full resident record with master data, contacts, pharmacy, consents and the care plan; Medikamente, the medication round; Woche, the weekly analysis.
[FILL] — BEFORE / AFTERThe same documentation task in the old interface and the new one, side by side. The single most persuasive image in the case.
In the working file the frame is named Wb / Ber. / Bew. / Pflege / Planung / Pflege & Betreuung / Infosammlung. The route is the file name — which is what a six-level hierarchy does to a team's vocabulary.

/09 — outcome

A platform that behaves like one product.

A twelve-application portfolio is now two suites and nine core applications on one design system, in production across 1,500+ installations and 5,000+ customer organisations in 12 countries, covering more than 600,000 scheduled employees.

  • Nine core applications across two suites — Cairful and Timeful — on one design system with accessibility standards and a governance model.
  • 1,500+ customer installations moved from local deployment to a unified web and mobile experience.
  • Structured user research established in an organisation that had shipped for 27 years without it.
  • Frankfurter Verband onboarded — the largest provider of social institutions in Frankfurt am Main: 7 nursing homes, 6 day-care centres, 1 outpatient care service, 14 community and service centres.
  • New corporate design shipped publicly at Messe ALTENPFLEGE, Essen, April 2026.

[FILL — what I would do differently. The honest failure or reversal from this project, in Givi's words. This section is the one senior reviewers look for; leaving it out costs more than including something imperfect.]