Internal Operations Platform
Designing a role-based internal platform that unified three isolated teams into a single real-time system. No more email coordination. Every role with a complete view of the customer lifecycle.
About Hourly
Hourly is a workforce management and payroll platform for SMBs with hourly workers. As the company scaled, three core internal teams, Sales, Compliance, and Customer Success, were operating in complete isolation, coordinating entirely through email threads and shared spreadsheets. This project built the operational backbone that connected all three.
ROLE
Director of UX · Technology co-decision-maker
TIMELINE
2025
LOCATION
Remote
The Problem
Four internal teams shared the same customers but had no shared system. Each team started from scratch at every handoff. Sales had no visibility into whether leads converted. Compliance received incomplete records weeks after the fact. Customer Success had no account history when they first made contact. Payments were going out on customers who never converted.
The cost was invisible but real. Slow handoffs, duplicate effort, and decisions made on outdated information. The broken state wasn't a people problem. It was a structural one.
The Thinking
Coordination happened through individuals rather than systems. Every role had workarounds: spreadsheets for tracking, email chains for status, manual exports for reporting. The cumulative effect was an organization where no one had a complete picture of any customer at any given moment, and every handoff was a potential point of failure.
Before designing anything, I mapped the full lifecycle from each role's perspective. What data they needed, at what point in the pipeline, and what actions they were responsible for taking. That mapping became the foundation for everything that followed, including a technology decision I initiated with the Director of Engineering before a single screen was designed.
Our existing component library was built for customer-facing surfaces. Extending it to dense, data-heavy internal tooling would have been slow and expensive. We evaluated alternatives against three criteria: stack compatibility, ability to handle complex table and form-heavy screens, and reduction in engineering overhead. We landed on Ant Design. It met all three and let us move fast without rebuilding from scratch.
The Solution
The core challenge was role-based information architecture. The same customer data needed to surface differently depending on who was looking at it and what action they needed to take.
I defined the data hierarchy and permission model for each role before any screen work began. What each view would expose, what it would gate, and why. That became the structural contract engineering used to build the role-scoped navigation and access logic, a decision I co-owned with the Director of Engineering.
With the foundations set, I collaborated with a designer on the screen-level work for each role view, providing direction and design critique while they executed on the interfaces:
Sales got real-time pipeline visibility and automated earning statements that replaced the shared Excel tracker entirely. Compliance got a structured work queue with auto-assignment, so records arrived complete and on time with no email chasing. Customer Success received accounts with full context already populated, no more starting from scratch.
Impact
Three teams, one platform. The same system serving three distinct operational realities without requiring separate applications or risking data inconsistency.
The Excel-based revenue tracking was gone. Real-time earning statements gave Sales full transparency and ended the recurring disputes with Finance. Every compliance handoff moved from email to a structured auto-assignment queue, with complete records and full audit history on every account.
The technology decision held up. The platform scaled as the company grew, and keeping internal and external design systems separate removed a recurring source of confusion for both design and engineering.
Reflections
The role-based permission model was built reactively, responding to what each team said they needed in the moment rather than from a proactive governance framework. I'd establish a formal permission model earlier in the process next time, treating access control as a design problem from day one rather than an edge case to resolve late.
I also underinvested in the internal launch experience. The teams who stood to gain the most were also the slowest to adopt. Not because the product was wrong, but because we didn't pair the launch with sufficient onboarding or change management. Adoption is a design deliverable too.
