Context
A global quick-service restaurant brand needed a better way to communicate with and support frontline workers.
The challenge was structural. Corporate did not directly employ most frontline staff. Franchise owners had significant autonomy. Tooling varied widely by location. In the absence of a cohesive system, stores created their own unofficial channels, some of which introduced legal and operational risk.
The goal was not to replace everything at once, but to explore whether a single, controlled platform could support communication, scheduling, pay visibility, training, and basic operational needs for frontline employees.
This work needed to function entirely on mobile, within tight platform constraints, and across a highly fragmented organizational model.
The Tension
Frontline work is time-bound, physically demanding, and unforgiving of friction.
Employees needed access to information without being overwhelmed. Managers needed visibility without surveillance. Corporate needed consistency without overreach. All of it had to respect on-clock versus off-clock boundaries.
At the same time, this work was happening inside an existing platform not designed for this level of customization. Every design decision carried downstream implications for policy, technology, and trust.
The risk was not building something imperfect.
The risk was building something that ignored how frontline work actually feels.
The Misalignment
Initial requirements focused heavily on capability. What features could exist. What data could be exposed. What integrations were technically possible.
What was less clear was how all of this would land in the hands of someone checking their schedule between shifts, reviewing pay details late at night, or trying to complete training while the clock was running.
There was also an implicit assumption that a single experience could serve every role equally. In reality, crew members, shift managers, and store managers navigated very different constraints and responsibilities.
Designing for everyone meant first acknowledging those differences.
How I Approached It
I started by separating the experience by role, not hierarchy.
We built distinct journeys for crew members and managers, grounded in how their days actually unfolded. Design and decision-making happened rapidly, but intentionally. Each morning focused on a single capability. Afternoons were spent prototyping. Evenings were reserved for technical feasibility checks and adjustment.
Rather than treat platform constraints as blockers, I treated them as design material. Close collaboration with engineering teams allowed us to push the boundaries of what the platform could support, while still keeping the experience coherent and respectful of user context.
Throughout the work, the focus remained on clarity and restraint. What should be immediately visible. What should be accessible but not foregrounded. What should be intentionally unavailable depending on time, role, or location.
The goal was not to do everything.
It was to do the right things well.
What Shifted
As the prototype came together, the experience began to feel calmer.
Information that had previously been scattered across systems was consolidated and contextualized. Employees could see what mattered to them in the moment, without digging or second-guessing. Managers gained visibility without needing to chase updates or manually relay information.
Just as importantly, boundaries became clearer. On-clock and off-clock experiences were intentionally different. Access was purposeful, not accidental.
The platform stopped feeling like another demand on attention and started feeling like quiet support.
Why It Mattered
This work demonstrated that scale does not have to come at the expense of humanity.
By designing around real constraints and lived realities, the experience reduced friction without flattening nuance. It respected time, attention, and trust in an environment where all three are often scarce.
It reinforced a principle that shows up across my work: when systems are designed with care, people can spend less energy navigating them and more energy doing the work that actually matters.