Tray Logistics
(B2B · Healthcare · Enterprise SaaS · Service Design · Logistics · Complex Systems)
My Role
Role
Product Designer
I joined Tray Logistics after its first round of usability testing and helped redesign the experience through launch. I focused on simplifying the information architecture, improving tray tracking and alerts, designing patient verification workflows, and defining an MVP that balanced user needs, patient safety, and technical constraints.
Overview
Delivering a meal in a hospital is more complicated than it sounds.
Between the kitchen and a patient’s room, diets can change, allergies and restrictions need to be accounted for, trays move through multiple teams, and the wrong meal reaching the wrong patient can become a serious safety issue.
Tray Logistics was designed to replace CBORD’s aging tray-tracking software and make that process easier to manage. The system connected information across three other CBORD products and supported everyone from kitchen staff and delivery teams to nurses monitoring patients on the floor.
I joined the project after its first round of usability testing and helped rethink the experience around a simpler information architecture, clearer tray statuses and alerts, and workflows that could support a complicated hospital operation without making staff do the complicated thinking themselves.
01. One tray, a surprisingly complex journey
A hospital meal passes through a lot of hands.
Orders could originate from different CBORD products before moving through preparation, quality checks, cart assignment, delivery, patient verification, and eventually intake tracking. Nurses, expeditors, delivery staff, call centers, and patients all interacted with different parts of that journey.
The existing Tray Monitor product had grown into a collection of similar screens and overlapping functionality. Before we could improve it, we had to understand what the system was actually doing.
We mapped the existing product, compared overlapping features, and traced how trays and information moved between roles. That helped us identify where workflows could be consolidated and reorganize the product around the people actually using it.
Instead of asking users to understand the structure of the software, we started making the software reflect the structure of their work.
02. Designing for mistakes that matter
In most products, a missed notification is frustrating. In a hospital, it can be dangerous.
A patient’s diet, room, allergies, or restrictions can change after a meal has already entered the delivery process. Tray Logistics needed to make those changes visible quickly enough for staff to catch a tray before it reached the wrong patient.
At the same time, many of the people using the system worked in high-turnover roles with limited time for training. The experience couldn’t depend on someone memorizing a complicated piece of software.
We redesigned tray cards and status information to make the most important details easier to scan, introduced clearer alerts, and used text and icons alongside color so critical information wasn’t communicated through color alone.
For nurses, we intentionally kept familiar parts of the existing workflow rather than redesigning everything for the sake of redesigning it. They needed to understand what was happening with their patients quickly, not relearn software they already depended on.
03. Verifying the patient without exposing the patient
One of the hardest problems happened at the very end of the journey: making sure the right tray reached the right person.
The obvious solution would be to display identifying patient information. In a hospital environment, that creates an entirely different problem.
We explored patient wristband scanning as a way for delivery staff to verify a tray at the bedside without manually entering or unnecessarily exposing protected health information.
It was a small interaction with a much larger design constraint behind it. The product needed to balance speed, patient safety, privacy, accessibility, and the realities of hospital work at the same time.
Those constraints shaped decisions throughout Tray Logistics, from what information appeared on screen to how alerts, colors, and fallback workflows were designed.
04. When the ambitious version isn’t the version you ship
Tray Logistics started with a much bigger vision.
We explored features like Smart Batching, which could automatically organize trays into carts based on destination and timing, along with GPS tracking, live maps, messaging, task management, and reporting.
Then the timeline changed.
Building everything we had envisioned wasn’t realistic for the first release, so we narrowed the MVP around the workflows hospitals already depended on: tray tracking, alerts, patient information, pickup and delivery, intake tracking, and administrative settings.
That also meant being pragmatic about the redesign. Engineering could reuse portions of the existing product, users wouldn’t have to relearn their entire workflow, and we could still improve the information architecture, accessibility, hierarchy, and usability around it.
The first version of Tray Logistics launched on iOS and Android as the foundation for the larger logistics platform we had envisioned.
For me, the project became an early lesson in designing complex systems: sometimes the best solution isn’t rebuilding everything. It’s understanding what absolutely needs to change, what shouldn’t, and creating a foundation that can evolve from there.
