Designing a workforce management system for a multi-sided marketplace
Gig Marketplace is a multi-sided platform connecting gig workers with clients who need to recruit, onboard, and manage large volumes of people over defined periods of time. The platform serves three primary roles: workers, clients, and operations teams, each with distinct needs, permissions, and decision-making contexts (as explored in the SCIEX regulated workflows).
My work focused on the client and operations layer of the platform: the systems that allow organizations to understand their recruitment funnel, monitor workforce performance, and make informed decisions while campaigns are live.
I was the lead designer on the project, working end-to-end across product strategy, UX, UI, and system design. I led a small design team locally and an additional distributed team, collaborating closely with product, engineering, analytics, and senior stakeholders, including the CEO.
The problem space
At scale, gig work is not just a marketplace problem. It is a workforce management problem.
Clients are not simply posting jobs and waiting for responses. They are running campaigns with targets, timelines, quality thresholds, and budgets. They need to understand how many candidates are entering the funnel, how long it takes them to move through each stage, how many become active workers, and how those workers perform once deployed.
At the same time, operations teams at GigCX need visibility into these same flows across multiple clients, without collapsing everything into a single, unreadable dashboard.
The challenge was to design a system that could support:
- multiple roles with different levels of abstraction,
- real-time operational insight,
- and long-term decision-making based on trends rather than snapshots.
From onboarding to operations
What began as an onboarding dashboard evolved into a broader operational surface.
Initially, the focus was on understanding how candidates moved through the early stages of the funnel. Over time, it became clear that the same surface could support much more: active workforce monitoring, campaign health, and performance oversight.
Rather than splitting these concerns into separate tools, the dashboard evolved into a workforce intelligence layer, capable of answering different questions depending on who was looking at it.
For executives, it provided high-level signals about recruitment efficiency and capacity planning. For managers, it offered visibility into current activity and bottlenecks. For operations, it became a day-to-day control surface.
This evolution shaped both the information architecture and the interaction model.
Designing for role-based intelligence
A core challenge was designing for role-dependent perspectives without duplicating the system.
The same underlying data needed to support:
- high-level funnel health and forecasting,
- mid-level operational oversight,
- and detailed views of active workers and their status.
Rather than creating separate dashboards for each role, the system was designed to progressively reveal complexity. Views emphasized aggregation and trends first, with the ability to drill down only when necessary.
This kept the interface readable while still allowing experienced users to access depth when they needed it.
Systematic product design
While there was no externally marketed design system, the platform was built on a working internal system of patterns and components (similar to the Home Depot design system).
This system supported consistency across:
- dashboards,
- tables and data visualizations,
- filters and status indicators,
- and role-based layouts.
Patterns were documented internally and evolved alongside the product. Decisions were driven by reuse, clarity, and behavioral consistency rather than aesthetic uniformity.
This approach allowed the product to grow without fragmenting, even as new features and views were added.
Prototyping as exploration and proof
Prototyping played a central role in shaping the platform.
Early prototypes were used to explore different ways of representing complex flows and to test whether stakeholders could understand key signals at a glance. As the design matured, higher-fidelity prototypes were used to validate workflows, align teams, and stress-test the system against real scenarios.
One of these prototypes, now documented separately, demonstrates how onboarding data, active workforce metrics, and operational insight can coexist within a single, coherent dashboard. Rather than focusing on screens in isolation, the work explored flows and transitions, making it easier to reason about friction, timing, and decision-making.
These prototypes were instrumental in aligning design, product, and engineering before committing to implementation.
Collaboration and ownership
I owned the system end-to-end from a design perspective. This included product thinking, interaction design, visual language, and internal documentation.
I led and coordinated the work of multiple designers across locations, while collaborating closely with product managers, developers, analysts, and senior leadership. While I did not directly manage developers, I worked in close partnership with engineering to ensure feasibility and alignment.
This level of collaboration was essential given the complexity of the platform and the number of stakeholders involved.
Impact
The resulting system enabled clients to:
- understand the health of their recruitment funnel,
- assess whether they needed to scale hiring up or down,
- monitor active workers in real time,
- and make informed decisions during live campaigns.
For GigCX, it provided a shared operational view across clients, improving oversight and coordination.
Most importantly, the platform moved beyond simple reporting. It became a decision-making tool that reflected how large-scale gig operations actually function.
Reflection
This project reinforced the importance of treating dashboards not as collections of widgets, but as operational environments.
Designing for multiple roles, levels of abstraction, and time horizons requires restraint as much as creativity. The most valuable decisions were often about what not to show, and when.
If approached again today, I would invest even earlier in mapping decision paths before designing views. In systems of this complexity, clarity emerges from understanding intent, not from adding more data.