My role
Sole designer
Team
PM, product director, process team, operation team, site leaders, engineering
Platform
Web
Timeline
3 weeks
Responsibilities
Scope definition
Design direction
Research
Interaction design
Visual design
Prototyping
Five tools. One broken field operation workflow
Carvana operates 140+ market hubs where vehicles are received, prepped, and handed off to customers. Site leaders manage hub operations through MOMS, an internal platform that tracks scheduling, labor, and daily activity execution.
The problem was that leaders had no way to investigate or resolve at-risk activities from inside MOMS. Every step required jumping between five disconnected tools. Hubs were ending each day with an average of 35 unclosed at-risk activities.
I was the sole designer on this project, owning everything from research to final specs. The solution was a side panel built into Activity Execution that gives leaders everything they need to investigate and act without leaving MOMS.
I connected different pieces of the project
Bridged 2 engineering teams to build the AI summary feature
Added a new pattern to the local logistics design library
Designed across 3 interconnected systems: MOMS, Cruise Control and CARMA
IMPACT
The rollout is live and showing early promise
We rolled out the new designs to three hubs over six weeks before expanding to the full network. The results came back strong.
Final solution
The Activity Execution page showed leaders what was at risk but it didn't allow them to act on it. With the new side panel, leaders have everything they need to investigate and resolve an activity without leaving MOMS.
Leaders can assign advocates to work on tasks directly from the panel and the assignment flows through to Cruise Control automatically. Verification history is summarized by AI so leaders know what the team has already done before they act. For the first time, all three workflows are visible and actionable from a single surface.
MY DESIGN PROCESS
35 unclosed at-risk activities per hub per day was the number that started everything
Site leaders were managing their day across five tools: MOMS, Cruise Control, CARMA, Tableau, and Jira. All open at the same time, every shift. A survey across all 140+ hubs found that 51% of leaders flagged multi-platform navigation as a major frustration.
The impact was real. Hubs ended each day with an average of 35 unclosed at-risk activities. Delayed appointments. Real customers waiting longer than they should.
Who actually uses this tool and what they needed from it
To design the right solution, I needed to understand the tool itself and the users operating out of the hubs.
Site leaders are the primary users of MOMS. Their job is to spot problems early and get the right person on it fast and not to do the work themselves unless they really had to. Customer Advocates (CA) and Lot Attendants (LA) carry out the day-to-day tasks and work out of Cruise Control app.
Trying out the tool and testing the workflow myself
Before I shaped any interview questions, I walked through the existing Activity Execution page the way a leader would at the start of a shift. The core problem was immediate. The page only showed that something was wrong but it gave leaders no way to figure out why or what to do next.
![](data:image/svg+xml,<svg display="block" role="presentation" viewBox="0 0 9 60" xmlns="http://www.w3.org/2000/svg"><path d="M 4.076 0 C 6.328 0 8.153 1.825 8.153 4.076 C 8.153 6.328 6.328 8.153 4.076 8.153 C 1.825 8.153 0 6.328 0 4.076 C 0 1.825 1.825 0 4.076 0 Z" fill="rgb(255, 172, 164)" height="8.152773727279087px" id="GPpE0Lu4M" transform="translate(0.041 0)" width="8.152773727279913px"/><path d="M 2.718 0 C 4.218 0 5.435 1.217 5.435 2.718 C 5.435 4.218 4.218 5.435 2.718 5.435 C 1.217 5.435 0 4.218 0 2.718 C 0 1.217 1.217 0 2.718 0 Z" fill="rgb(240, 34, 14)" height="5.435189804235082px" id="kpGgVFb7F" transform="translate(1.4 1.358)" width="5.4351898042352325px"/><path d="M 0 0 L 0 52.232" fill="transparent" height="52.23205873843872px" id="o2B6bU3pr" stroke-dasharray="" stroke-linecap="butt" stroke-linejoin="miter" stroke-miterlimit="10" stroke-width="0.66" stroke="rgb(255, 172, 164)" transform="translate(4.117 8.153)" width="1px"/></svg>)
Saw leaders managing the day using 5 disconnected tools
After auditing the tool, I ran shadowing sessions with three site leaders at the Montebello hub to see the actual workflow: what they looked for, in what order, and how long each step took.
What I watched was a leader using 4-5 tools at once that never talked to each other. He'd open MOMS to find flagged activities, flip to Cruise Control to check if the CA had contacted the customer, open Carma to check verification status, then open Jira to file a push request if the vehicle had issues. Then back to MOMS, which had no idea any of that happened.
Every switch cost time. And because the tool couldn't surface what he needed or let him act on anything, the whole operation ran on him holding it all in his head.
Interviews surfaced two problems the brief had not mentioned
Step 1
Sees that customer is not verified and therefore appointment can’t be completed
Step 2
Reaches out to Verification team on Slack to inquire about status
Step 3
Pending on response since Verification team has to reach out to customer
Step 4
Verification team responds after a while with an update
Step 5
Waiting for customer to complete their verification tasks
Loop ends only after customer completes all their tasks
VERIFICATION UPDATES
Handoffs were entirely manual
LAs found out about urgent task changes through a tap on the shoulder. If a CA ran late and missed pre-work, a leader would step in to cover but because none of it happened in the tool, the CA had no idea what had been done on their behalf unless the leaders tell them directly.
9:02 AM
CA calls leader: running 30 min late
Phone call
9:05 AM
Leader covers pre-work tasks for the next appointment*
Not logged anywhere
9:18 AM
Leader completes verification check on the CA’s behalf*
Not logged anywhere
9:32 AM
CA arrives at the hub and finds leader to get update
In person
MANUAL HANDOFF
Borrowing from other tools that had solved the problem
I looked at tools in adjacent industries that had already solved a version of the same problem: field operations where managers need live context and the ability to act from one place. Three products shaped how I thought about the design.
Synthesized the findings with my product owners to arrive at 5 themes
I brought the PM and product director into a synthesis session to make sense of the research findings. We clustered the raw notes together and landed on five themes. Two became the focus of this project. The remaining three (urgency signal failure, same-day awareness gap, and false at-risk signals) were valid problems but we kept them out of scope. The goal was to ship a focused solution and learn from it first.
Mapping the triage workflow to pinpoint the areas of friction
To understand where the workflow was breaking down, I reconstructed the full triage workflow a site leader goes through during their shift.
Leaders started on the Activity Execution page but were already switching tools by step three. Investigating incomplete pre-work tasks required jumping to Cruise Control to see if the CA was mid-appointment and running late. Checking customer verification meant opening CARMA, then messaging the verification team to get more information. Rescheduling involved manually pulling data and writing Jira tickets.
By the time a leader closed a single at-risk activity, they had touched four tools and carried information between them by hand at every step.
Finds at-risk activity
Investigate
Coordinate
Escalate
Close
Leader actions
Tools used
Pain points
CA actions
LA actions
The decision tree for rescheduling at-risk activities
Rescheduling an at-risk activity requires leaders to quickly assess task progress, customer verification status, and vehicle repair status against the departure window. If any cannot finish on time, they reschedule the appointment.
The planning system should auto-flag issues, but it often lacks real-time visibility into active verification calls or sudden repair delays. As the final decision-makers, leaders need all three statuses in one place to decide fast and accurately.
Four principles to guide the design
To keep design focused on the problems and make sure the solutions are actually speeding up users workflows and not slowing them down. I came up with 4 design principles to use as my north star.
The constraints that made this harder than it looked
Throughout the design process, I came across many constraints related to design, data, and workflows. I worked closely with the PM, engineering, and cross-functional stakeholders to understand what was technically possible and adjusted the design to work within those limits.
The goal was to find solutions that were still meaningful to leaders even when the data or system access wasn't perfect.
Activity Details: The right place to show all the details
The challenge was figuring out how to show activity details without pulling leaders away from the board. With multiple at-risk activities, they needed to investigate each one and act fast. The layout had to support both scanning and resolution at the same time. I tested four directions before landing on the side panel, which was the only approach that cleanly separated the two jobs: the table handles scanning, the panel handles investigation and action.
Modal
Blocks the entire table.
The moment a leader opens one activity, they lose sight of everything else on the board.
Inline expanded rows
Kept the table visible but became unmanageable with six or more flagged activities.
Not enough room to show the detail leaders needed.
New status columns on table
Added noise to every row, not just flagged ones.
On-time activities carried columns they had no use for, making the whole table harder to read.
Side panel
Split the jobs correctly. The table handles scanning and prioritization.
The panel handles investigation and action.
Neither competes with the other.
Side Panel: What information to show and how to show it
The challenge was figuring out how to show activity details without pulling leaders away from the board. With multiple at-risk activities, they needed to investigate each one and act fast. The layout had to support both scanning and resolution at the same time. I tested four directions before landing on the side panel, which was the only approach that cleanly separated the two jobs: the table handles scanning, the panel handles investigation and action.
Tasks: Giving leaders control over tasks
The tasks section was the most important to get right. It's the one section every activity has, and where leaders have the most direct control.
Pipeline tasks belong to LAs. Pre-work tasks belong to the assigned CA. Because they have different owners and different resolutions, I needed to make that separation obvious at a glance.
The other decision was how leaders mark pre-work tasks complete on behalf of a CA. Because the action triggers an update in Cruise Control, the action should be irreversible.
From one-off design to a shared local pattern
When I built the task list component for MOMS, I realized I had seen the same pattern used across other logistics tools like Cruise Control but built inconsistently each time with no shared standard.
I audited the logistics tools to see how each one handled it, then worked with the design system team on best practices for contributing to a local library. I built the component using global design system variables with configurable slots for different states and use cases, and wrote usage guidelines to go with it. It now lives in the logistics local library as a shared pattern any internal tool can use going forward.
![](data:image/svg+xml,<svg display="block" role="presentation" viewBox="0 0 111 11" xmlns="http://www.w3.org/2000/svg"><path d="M 0 5.089 C 0 2.279 2.279 0 5.089 0 C 7.9 0 10.179 2.279 10.179 5.089 C 10.179 7.9 7.9 10.179 5.089 10.179 C 2.279 10.179 0 7.9 0 5.089 Z" fill="rgb(255, 172, 164)" height="10.17892px" id="RwhafP1P1" width="10.17892px"/><path d="M 0 3.393 C 0 1.519 1.519 0 3.393 0 C 5.267 0 6.786 1.519 6.786 3.393 C 6.786 5.267 5.267 6.786 3.393 6.786 C 1.519 6.786 0 5.267 0 3.393 Z" fill="rgb(240, 34, 14)" height="6.785959999999999px" id="yqW6dPfdG" transform="translate(1.698 1.696)" width="6.785959999999999px"/><path d="M 0 0 L 100 0" fill="transparent" height="1px" id="M3LeG9UKg" stroke-dasharray="" stroke-linecap="butt" stroke-linejoin="miter" stroke-miterlimit="10" stroke-width="0.848244" stroke="rgb(255, 172, 164)" transform="translate(10.179 5.089)" width="100px"/></svg>)
Tested, validated, and scoped
I tested the designs with three site leaders across experience levels: newer, mid-level, and experienced. Each session covered the same tasks: triaging at-risk activities, using the side panel to investigate and act, completing assign and mark-complete flows, contacting the verification team, and rescheduling an activity.
Their feedback sharpened my understanding of their workflow. Not everything shipped in v1. Some was saved for future phases due to complexity or edge cases.
Early results showed real impact
The team rolled out the new designs to 3 hubs for 6 weeks before expanding to the rest. So far the data was promising.
Resolution time dropped from ~30 minutes to about 21 minutes, and open at-risk activities fell from the average of 35 to 7. We expected some activities to stay open since advocates weren't marking completed calls as done, an issue we plan to address in a future project.
Tool switching also dropped. Leaders stayed in MOMS for most of the workflow instead of jumping between CARMA, Car Tower, and Jira. Steps to resolve an activity went from 4-5 down to mostly two tools. Time in the side panel increased, which was a good sign. The panel keeps leaders focused on one activity at a time rather than scanning the full table.
Want to see more of my work?
Check out my other case studies, or reach out to me at
