Product Design
UX/UI
Case Study
Oskrba na domu (Home Care app)

Oskrba na domu (Home Care) is a redesign concept for a mobile app used by home care workers; nurses, physiotherapists, and aides who visit patients in their homes across Ljubljana. The existing app has accumulated friction over the years: workers don’t get all the information they need, keep parallel paper records, and lose time on interactions that should be invisible. This self-initiated project reimagines the app around a single question: what would it take for the tool to recede into the routine, so the worker's attention can stay on the patient?

Context
Home care in Slovenia is coordinated through Zavod za oskrbo na domu that plan the days and weeks of their field workers. The staff maintain detailed records of patients; diagnoses, treatment plans, addresses, contact information and assemble each worker's week schedule. The Zavod also provides the usual support, admin, onboarding, and infrastructure around the work.

A typical day begins at the office. The worker arrives, taps their badge to start their shift, handles administrative work for an hour or so, then sets out on the day's route. Between patients, they commute (usually by car, sometimes by bicycle) and at each home they check in, perform the visit, document what was done, and move on. Lunch break is taken at the worker's discretion, somewhere between visits. The day ends after the last patient's been taken care of.

A "visit" is rarely just a visit. Depending on the patient, it might involve physiotherapy, wound care, medication management, hygiene support, vital-sign monitoring, or simply the kind of attentive company that keeps a fragile person stable in their own home.

The problem
The existing system isn't one app — it’s two. The main app handled the day's work: the plan, the check-ins, the patient information, the documentation. A second, separate app held the worker's own information: hours worked, hours remaining, vacation balance, absence requests, work history... From a practical stand-point it wasn’t clear why is it a separate app.

The main app had its own shortcomings. Some functions were unclear or half-working. The interface had visual inconsistencies rather than a coherent design. Iconography varied from screen to screen, sometimes within the same flow. Features that belonged together had been separated; information the worker actually needed was buried or unavailable.

The workers still had to fill reports and track treatment plans at the office, which meant the information had to be held by other means until it could be entered at the Zavod’s system. In most cases they lost time making separate notes after the patient’s visit. In the case of physiotherapy and medical care, more detailed records had to be kept, again separate, and manually entered at the office. This felt as an additional burden, especially considering the fact that the system could be easily expanded to allow this admin work to be done on site while information was still fresh. More often than not, one hour each morning at the office was not enough to back-log everything.



Research
The redesign was grounded in inquiries with a practicing physiotherapist and a home care nurse, combining observation and structured conversation. We prepared a list of use points to observe over a period of two weeks: the check-in ux, data entry, obtaining relevant and necessary information, how many taps to reach the features and functions, to observe the use in the conditions it was built for, then interviewed both about what was missing, what was redundant, what they’d quietly stopped using, and what they did instead.

They walked me through the shortcomings they encountered most often, the information they wished the app contained or had close at hand, and the ways the app's functions could be extended to further aid the work — particularly the friction of filling out treatment plans and report forms on the move, between visits, often in a parked car between appointments. The fact that one of them is a close personal friend and a very thorough and organised professional gave the research a quality that survey-based or short-interview research rarely produces.

Design Solutions
The worker’s day as a sequence, not a set of program features.  The centerpiece of the redesign is the day plan. It presents the worker's entire day as a vertical stack of cards, in chronological order: office hours, commutes, patient visits, lunch, more visits, more commutes, end of day. Each card is a discrete event with its own visual identity: color coding for type (office, commute, patient work, and lunch break) and color coding for state within patient visits (red for pending, yellow for ongoing, green for done). This screen complements the button-driven architecture of the existing app which is kept and further sequence-refined to retain familiarity. Instead of navigating to "check in," then to "view plan," then to "patient info," the worker sees her entire day at a glance, in the order it will happen, and acts on it directly. The plan is not a view of the work — it is the work, time-stamped and color-coded as it unfolds. A persistent bar on the left edge marks the current event. This is the worker's "you are here" — visible at a glance even when the phone is held loosely, even with peripheral vision, even in poor lighting.

The worker is rarely two-handed, and every additional interaction is a failure point. The day plan doubles as a time clock. The worker taps a card to start its timer; she taps it again to stop. There are no modals, no confirmations, no second screens for routine timing. The card visually transitions through its states (pending, ongoing, done) and the time information on the card updates accordingly. Each card has two tappable zones. The body of the card handles the start/stop action. A separate, generously-sized zone on the right opens the event's detail page, where additional notes, treatment plans, and forms live. This separation lets the worker do the routine, high-frequency action (timing) without ever leaving the plan, while still providing a clear path to the deeper functionality when needed. Done cards become inert to the start/stop gesture, only the detail zone remains tappable on them. This prevents accidental re-tapping after a visit has ended, which would otherwise create data integrity problems.




Time-tracking is the worker's own interest, and the information they needs depends on where they are in the event. Each card type shows different information depending on its state, because the worker is asking different questions at different moments. A pending card shows the patient's name and the planned time range. That's enough to answer "who am I seeing next, and when am I expected." An ongoing card shows the patient's name and the elapsed time, ticking live. The worker can glance at the card mid-visit and instantly see how long they’ve been there, against the planned duration she already knows from the schedule. Eventually this card will also show a quiet visual indicator of how the elapsed time compares to the planned duration, a soft progress signal that turns "am I on time" from a calculation into a glance. A done card shows the patient's name, the actual time range, and the elapsed total. The check mark confirms completion at a glance. The pattern is consistent across all event types.

The plan and the actual day diverge, and the app must handle both gracefully. Most days, the plan view is the right tool: the worker follows their schedule, taps each card in sequence, and the timing handles itself. But most days deviate; traffic conditions, visit takes longer or is cancelled last minute and another one is added with a delay, etc. For these cases, the redesign offers a second entry point: an attendance view, where every category of activity is a tappable button. The worker can start any activity at any time, regardless of whether it appears on the plan. The two views are interchangeable and live-synced. An event started from the attendance view updates on the plan view; a card tapped on the plan view updates the attendance state. The worker never has to choose between them, they use whichever matches her mental model at the moment..

Workers want to manage their own working day, not just report it. The redesign absorbs the second app into a profile page within the main app. This page represents the worker, not the Zavod. Accessed with one tap from almost anywhere in the app, is the day's running totals: hours worked, hours remaining, time spent in office, in patient visits, in commute, on breaks, total distance travelled. These reset on each new day. Beneath that, the request flows: vacation requests, absence requests, sick leave. Then the longer historical views: time statistics by day, week, and month; vacation balance; plan realization; a browsable history showing planned versus actual hours over time, and finally app personalization. Nothing in this section is novel as a feature. What's novel is that it exists where the worker would naturally look for it: behind her own avatar, in the same app they use for the rest of the day.

The institutional features must be reachable but not in the way. Beyond the worker's own day, the institution generates a substantial information layer: patient databases, plans for other workers, coordination across the team, work history, push notifications. Push notifications have been moved closer to the user’s attention at the profile page, with their avatar showing a tick.


©2006—’26

Endorsements