Enterprise Workforce Platform

The project in brief

The design challenge

Research defined the MVP's people and priorities

Because I was new to staffing operations, research had two goals: build my domain understanding and give the team evidence for deciding what the MVP needed to demonstrate.

• Understand the domain. I interviewed stakeholders across leadership, engineering, sales, onboarding, and support, then audited the legacy system to map existing workflows, dependencies, and recurring customer problems. User surveys and competitor research helped test internal assumptions against broader expectations.
• Model the users. I synthesized the findings into personas and journey maps for frontline workers, agency managers, and parent-company executives. These were the company’s first formal user profiles and helped shift discussions from abstract feature requests to concrete responsibilities, risks, and decision points.
• Define the MVP. The research clarified which workflows were essential to the demonstration, which system dependencies needed to appear in the interface, and which employee-facing capabilities could remain at the design stage without weakening the core platform story.

The resulting profiles revealed three levels of responsibility the platform needed to support: frontline work, agency operations, and parent-company oversight.

Research translated organizational responsibilities into user needs, workflow priorities, and a focused MVP scope.

What shaped the product

Research surfaced three needs, and implementation revealed a separate scaling risk. Together, they became four design decisions that shaped the MVP. Each required balancing learnability, system accuracy, and implementation constraints.

01 · Making organizational hierarchy visible

1. CHALLENGE

   Parent-child relationships affected permissions, policies, reporting, and time calculations. A flat navigation model would have treated each agency as an isolated workspace, making it difficult for administrators to understand inherited rules, local overrides, and conflicts.

2. DECISION

   I designed hierarchy views that made agency relationships explicit and reusable across the platform. The same organizational model informed policy management, permissions, reporting, and timekeeping, allowing administrators to understand which organization they were working within and where a rule originated.

3. TRADE-OFF

   Representing hierarchy added complexity to the navigation, but hiding it would have forced every workflow to recreate the same organizational relationships independently.

02 · Making complex policy logic learnable

1. CHALLENGE

   Staffing agencies experienced frequent turnover, so the platform could not depend on lengthy training. This was especially important in policy configuration, where labor rules varied by state, agency, and client and could not be represented through one fixed form.

2. DECISION

   I prioritized task-focused flows, repeatable interaction patterns, plain language, and a foundation for English and Spanish localization. For policy management, I integrated the Code Effects Rule Engine into the front end and adapted its interaction patterns to the wider product. Administrators could create natural-language conditions and review each rule within the organizational context where it applied.

3. TRADE-OFF

   Exposing every backend option would have increased flexibility but reduced comprehension. I prioritized contextual editing so administrators could understand what a rule did, where it applied, and how it interacted with the agency hierarchy.

03 · Making time calculations inspectable

1. CHALLENGE

   Time formats, rounding rules, approvals, and exceptions could affect payroll-related calculations, benefits, and compliance. Agencies recorded time using both decimal and hours-and-minutes formats, so small inconsistencies in conversion or rounding could compound across large datasets.

   Accuracy alone was not enough. Administrators needed enough context to review edits, understand exceptions, and trust the result.

2. DECISION

   I designed timecard workflows that brought recorded hours, approvals, exceptions, calculation categories, and audit details into one reviewable experience. This allowed administrators to compare the original record with policy-defined outcomes and identify where a calculation had changed.

3. TECHNICAL RESPONSE

   During implementation, we surfaced a decimal-time rounding issue that could produce inaccurate results at scale. I worked with backend engineering to connect the technical problem to its user-facing consequences. The calculation logic was updated to preserve fractional remainders and normalize values at the appropriate point instead of rounding too early.

4. TRADE-OFF

   Exposing more calculation detail increased information density, but it gave administrators the context needed to review exceptions and trust the result.

04 · Balancing people-centered context with enterprise scale

1. CHALLENGE

   Early product direction intentionally moved away from spreadsheet-like administrative interfaces. Card-based employee views kept identity and context visible, but became inefficient as agency datasets grew into the thousands. A layout that felt approachable in a demonstration could slow scanning, comparison, sorting, and routine administration at enterprise scale.

2. DECISION

   I defined a dual-view strategy. Cards remained available for smaller datasets and detail-focused workflows, while tables supported larger datasets where density, sorting, and comparison mattered more.

3. TRADE-OFF

   Cards created a more approachable, people-centered experience, while tables supported faster work at scale. The product needed both rather than forcing one pattern into every context.

Where design met implementation

I implemented most of the front end alongside my UX/UI work. Working across both disciplines allowed me to test design decisions against live API responses, connected workflows, system states, performance constraints, and the practical limits of the MVP architecture.

Turning a shared design language into reusable code

I created reusable patterns in Figma and translated them into React and Next.js components. These patterns established consistent behavior across forms, navigation, feedback states, and administrative workflows.

When workflows required more specialized behavior, I extended the component system with custom components throughout the product, including components for agency hierarchies, policy configuration, assignments, and timecard management.

Designing within technical constraints

The MVP needed authentication, English and Spanish localization, reporting, time clocks, kiosks, and support for large datasets. These requirements affected component behavior, loading and error states, validation, data handling, and future scalability.

I implemented accessibility as part of component behavior through semantic HTML, appropriate ARIA roles, keyboard navigation, and sufficient color contrast. This made accessibility part of the product structure rather than a final visual check.

Validation and iteration

Because the MVP did not reach production during the project timeline, validation focused on internal usability reviews, stakeholder feedback, and technical feasibility testing. These methods tested whether workflows reflected the domain, organizational relationships were understandable, and connected experiences behaved reliably with the available data and integrations.

What changed through iteration

MVP outcome and project status

Within eight months, the team delivered a demo-ready MVP that brought the platform’s core agency and administrative workflows into one connected experience.

Core capabilities delivered in the MVP

• Parent-child agency hierarchy
• Policy and rule configuration
• Time tracking and timecard management
• Assignments and work orders
• Reporting and data exports
• Agency-facing employee records
• Authentication
• Localization architecture and English-Spanish foundations

Key areas deferred beyond the project timeline

• Employee-facing self-service workflows
• Complete permissions coverage across all hierarchy scenarios
• Full English-Spanish translation across every workflow
• Advanced enterprise table behavior and virtualization

These lists summarize the areas most relevant to this case study rather than the complete product scope or backlog.

Reflection and next steps

What I learned

What I would do next