Case Study

Improving real-time operations oversight

tl;dr

Redesigned a hospital housekeeping management system by modeling dispatcher workflows and operational concepts first, transforming a standalone application into an intuitive platform capability for real-time shift management across desktop, tablet, and mobile.

Designing an operational model for hospital housekeeping management

Housekeeping operations in hospitals are highly dynamic. Throughout a shift, dispatchers continuously monitor staff availability, assign work, reprioritize tasks, and respond to changing patient activity across multiple floors and departments.

Compass Digital wanted to consolidate an existing standalone housekeeping application into the broader Elevra operations platform. I led the product definition and interaction design effort to ensure the new experience accurately represented how dispatchers actually reasoned about work throughout a shift.

The project became less about integrating software and more about translating a complex operational domain into a coherent product model.

Modeling the work before designing the interface

The existing application already contained the necessary functionality, but functionality alone wasn’t enough to inform the redesign.

Interfaces describe one interpretation of a problem.

Before designing anything, I wanted to understand the underlying operational model that those interfaces represented.

Working closely with Product, I facilitated a series of requirements definition workshops where we decomposed the existing workflow into its underlying concepts, entities, relationships, and operational scenarios.

Rather than asking “What screens do we need?”, I asked a different question:

“How do dispatchers understand and manage housekeeping operations throughout a shift?”

This exercise allowed us to separate product capabilities from interface decisions while establishing a shared understanding of the domain before discussing layouts or components.

Identifying the concepts that deserved representation

One of the most valuable outcomes of the requirements workshops was recognizing that not every concept deserved equal visibility within the interface.

Operational systems often accumulate functionality over time, resulting in interfaces that attempt to expose every available capability equally. Instead, we identified the concepts that dispatchers relied upon to make operational decisions in real time. These included:

  • Operators
  • Shifts
  • Work status
  • Task categories
  • Facility structure
  • Assignment state

By explicitly modeling these concepts before designing the interface, every subsequent design decision became considerably easier because the interface was communicating an already agreed-upon operational model rather than simply exposing features.

Organizing the interface around operational awareness

The primary workspace became the “Shift Board”, a real-time operational dashboard that provided dispatchers with a comprehensive view of housekeeping activity throughout a shift.

Rather than presenting isolated lists or individual records, the interface emphasized operational awareness. Dispatchers could immediately understand:

  • Operator availability
  • Workload distribution
  • Task assignment
  • Task progression
  • Facility coverage

This transformed the interface from a collection of management screens into a live operational view that supported continuous decision making.

Representing state as a first-class design problem

Managing housekeeping operations depends almost entirely on understanding state. Tasks continuously transition between assignment, execution, cancellation, and completion while operators simultaneously move between different workloads throughout a shift.

I designed interaction patterns that communicated these changing states clearly without requiring dispatchers to inspect individual records. Operators, tasks, and work categories each exposed the information necessary to support rapid decision making while maintaining consistency throughout the experience. Rather than simply displaying data, the interface continuously communicated what was happening operationally.

Designing around how dispatchers think—not how data is stored

One of the most important design decisions involved representing work according to how dispatchers mentally organize their responsibilities rather than how the underlying system stored information.

Housekeeping work naturally falls into several categories including discharge cleaning, routine duties, and ad-hoc requests—each progressing through distinct operational states.

The interface surfaced these concepts directly because they reflected the questions dispatchers were constantly asking themselves throughout a shift:

  • What still needs attention?
  • Who is available?
  • What is already in progress?
  • Where are bottlenecks emerging?

Designing around these mental models reduced the cognitive effort required to monitor activity while supporting faster operational decisions.

Designing a system that works across every device

Housekeeping management doesn’t happen exclusively from a desktop. Dispatchers move throughout facilities while supervisors frequently monitor operations from tablets and mobile devices.

I designed each experience around the operational needs of its context while preserving a consistent interaction model across desktop, tablet, and mobile interfaces. This ensured users could transition between devices without relearning workflows.

Designing alongside engineering

Throughout the project I partnered closely with engineering to validate implementation feasibility, refine interaction behavior, and ensure the operational model translated cleanly into a scalable product architecture.

Design specifications extended beyond interface layouts to include interaction behaviors, state definitions, and supporting documentation that reduced ambiguity during implementation.

By treating engineering as a design partner rather than a downstream consumer, we maintained alignment from product definition through delivery.

Translating an application into a platform capability

My objective was to transform a standalone product into a platform capability while preserving the operational workflows dispatchers depended upon every day.

Grounding the redesign in a shared conceptual model allowed the interface to evolve without losing the behaviors that made the original application valuable. 👍


This project reinforced a principle that has shaped the way I approach complex enterprise software. Features rarely reveal how people actually work. Operational systems are built around concepts, relationships, and decisions. Not screens.

By investing time in modeling the domain before designing the interface, design becomes an exercise in representing work rather than arranging controls.

The resulting interface feels intuitive because it mirrors the way users already think about their work.

Next Case

A conversational learning experience