02 / PRODUCT EXPANSION
Designing a Collaborative Hiring Platform
Transforming StaffingNation from a direct hiring application into a multi-party hiring ecosystem
As the sole designer, I redesigned TCWGlobal’s contingent workforce platform alongside a complete rebuild of its technical foundation.
Company
TCWGlobal
Role
Senior UX Designer
Platform
Enterprise SaaS
Timeline
Multi-year product evolution
Expanding direct hiring into a connected ecosystem
01 / THE CONTEXT
When StaffingNation 2.0 launched, it supported a relatively direct process:
A client created a work order.
The client identified a worker.
The worker completed onboarding.
As TCWGlobal’s MSP business grew, that process became much more complex.
Clients needed to distribute job orders to staffing vendors. Vendors needed to submit candidates. Hiring managers needed to compare candidates, coordinate interviews, and approve selections. Internal program teams needed oversight across the entire process. Selected candidates then needed to move smoothly into offer and onboarding workflows.
StaffingNation was no longer supporting a single organization completing a linear task. It was coordinating work across multiple organizations with different responsibilities, permissions, relationships, and business goals.
Before
Direct client-to-worker hiring
After
A coordinated hiring process across multiple organizations
Owning the UX across a growing product ecosystem
02 / MY ROLE
This initiative evolved across multiple releases, and I was involved throughout its lifecycle.
I worked closely with Product before implementation began to understand business needs, question assumptions, and explore how collaboration between clients, vendors, recruiters, and internal program teams should work.
Rather than receiving fully defined requirements and translating them into screens, I helped shape the workflows themselves.
My work included:
Mapping the end-to-end hiring lifecycle
Defining role-specific visibility and actions
Designing vendor and candidate submission experiences
Creating candidate review, interview, approval, and hiring workflows
Extending onboarding to support new candidate scenarios
Designing dashboards, notifications, and operational tools
Partnering with Engineering throughout implementation
Responsibilities
Product discovery, workflow design, information architecture, interaction design, prototyping, stakeholder collaboration, and implementation support
Team
Sole UX designer working with product and engineering
Tools
Sketch · InVision
Designing around one shared lifecycle
03 / EXPERIENCE ARCHITECTURE
A straightforward approach would have been to design separate applications for clients, vendors, and internal teams.
Instead, I treated the hiring lifecycle as the product’s central organizing model.
Every participant entered that lifecycle from a different perspective. They had different permissions, responsibilities, and information needs, but they were all contributing to the same outcome: identifying and onboarding the right worker.
One lifecycle. Different perspectives, permissions, and responsibilities.
Creating one workflow for many perspectives
04 / SHARED WORKFLOW
Clients, vendors, recruiters, program managers, candidates, and workers all participated in the same hiring process.
Each group needed a different experience:
Hiring managers needed to review and compare candidates.
Vendors needed to submit candidates and monitor their progress.
Program managers needed visibility across every submission and vendor.
Candidates needed to provide information and complete required steps.
Internal teams needed to manage exceptions, approvals, and onboarding.
The challenge was not simply restricting access to screens. The interface needed to adapt its context, information, and available actions while still feeling like one product.
Candidates tab on the order viewed as a Program Manager who has visibility into who the submission was from
Design principle
Maintain one shared lifecycle while tailoring visibility and actions to each participant’s responsibilities.
05 / TRUST & FAIRNESS
Protecting vendor neutrality
One of the most sensitive design challenges involved protecting vendor relationships during candidate evaluation.
Hiring managers needed to assess candidates objectively without knowing which staffing vendor submitted them. Program managers required full visibility into vendor relationships, while each vendor could see only its own submissions.
The same candidate-management workflow therefore needed to present different information based on the viewer:
Hiring manager
Candidate qualifications
Resume and relevant experience
Current hiring stage
Interview and approval actions
No vendor identity
Program manager
Complete candidate information
Submitting vendor
Submission history
Oversight and administrative actions
Vendor
Only candidates submitted by that vendor
Candidate status and progress
Requests requiring vendor action
No visibility into competing submissions
Vendor identity could not simply be hidden visually. The underlying workflow, notifications, exports, and contextual information all needed to preserve the same boundaries.
Candidates viewed by a Hiring Manager
Candidates viewed by a Program Manager
Candidates viewed by a Vendor
Design principle
Give each participant enough context to make decisions without exposing information that could compromise trust.
Making progress and ownership clear
06 / VISIBILITY & OWNERSHIP
Candidate submissions moved through several stages:
Submitted → Under Review → Interviewing → Selected → Onboarding
Each stage changed who was responsible for acting.
A program manager might need to review submitted candidates. A hiring manager might need to review a resume. A vendor might need to coordinate an interview. A candidate might need to complete onboarding documents.
At every stage, the experience needed to answer two questions:
“Where is this candidate in the process?”
“Who needs to act next?”
I used consistent statuses, role-specific actions, notifications, dashboards, and contextual detail views to make progress and ownership visible.
The goal was not just to display a status. It was to help each person understand what that status meant for them.
Order Candidate View
Engagement Pusher
Candidate Portal
Design principle
Status should communicate both progress and responsibility.
A connected hiring experience across roles
07 / THE RESULTING EXPERIENCE
01 / Enter the talent ecosystem
Candidates could join a company’s talent community, create a reusable profile, and become discoverable for future opportunities.
02 / Discover and match talent
Search and matching helped teams discover both known talent and externally submitted candidates.
03 / Evaluate candidates in one workspace
Candidates from different sources could be evaluated through a shared pipeline while preserving the context appropriate to each record.
04 / Advance the selected candidate
Contextual actions moved candidates through interviews, selection, and offer without separating those decisions from the candidate record.
05 / Complete the transition to work
The candidate-facing portal connected offer acceptance, onboarding requirements, approvals, and readiness to begin work.
Talent Profile
Extending shared patterns across StaffingNation
08 / PLATFORM-WIDE IMPACT
Vendor Management was the largest expansion of StaffingNation during this period, but it also established reusable patterns that influenced the broader product.
These included:
Role-aware interfaces
Contextual record views
Shared status models
Permission-based actions
Candidate and worker record transitions
Operational dashboards
Notifications tied to workflow responsibility
Multi-party approval patterns
Those patterns later supported improvements across candidate submissions, interviews, onboarding, dashboards, reporting, and other workforce workflows.
The result was not simply a new module. It was a more flexible model for coordinating work across organizations.
A stronger ecosystem for collaborative hiring
09 / OUTCOME
This initiative fundamentally expanded what StaffingNation could support.
The platform evolved from a direct hiring application into a collaborative workforce-management system capable of supporting TCWGlobal’s growing MSP business.
The experience became part of customers’ daily hiring operations and received consistently positive feedback. One of the outcomes I am proudest of is that a workflow involving multiple organizations, permission models, and handoffs became something users could successfully navigate in their everyday work.
01 / Expanded the business model
Enabled StaffingNation to support TCWGlobal’s growing MSP services.
02 / Connected multiple organizations
Created one hiring lifecycle for clients, vendors, candidates, and program teams.
03 / Protected critical relationship
Supported objective candidate evaluation while preserving vendor neutrality.
04 / Established reusable patterns
Introduced role-aware workflows that influenced future product development.
What I learned designing a multi-party product
REFLECTION
This project reinforced a principle that continues to guide my work:
Enterprise UX is not about making every user see the same interface. It is about giving each person the right information, actions, and level of visibility at the right moment.
Complexity does not disappear simply because the interface looks simpler. It must be organized around clear responsibilities, trusted boundaries, and shared progress.
When users understand where they are, what they can see, and what they need to do next, even complicated collaboration can feel coherent.