All UX case studiesColleago B2B2CLive · iterating

From phone calls to one request: a client portal for temp staffing

Context
Hospitals, schools and event venues booked temp staff by calling several agencies, and chased managers to approve timesheets.
My role
Lead product designer for the client portal: client journeys, usability testing, and shipping changes in code alongside two other designers.
Outcome
Live with 22 agencies. Timesheet approval reached 94% task success; creating a request is at 67% against a 90% target, and round 3 is closing the gap.
Team
3 designers, PO, engineering squad
Users
Clients, agencies, temps
Status
Live with 22 agencies, iterating

In numbers

22agencies onboarded to the platform
14usability sessions: 9 client managers across 6 hospitals, and 5 agency admins
94%task success approving timesheets
67%task success creating a request, against a 90% target

The problem

Clients filled temporary shifts by calling several labour hire agencies and repeating the same details. Agencies re-keyed requests from emails, and timesheet approval meant chasing managers for signatures. Colleago connects all three sides: clients on a web portal, agencies on an admin portal and temps on a mobile app. I designed the client portal, where every request starts; testing so far has been with hospital client managers.

  • The first eligible temp to accept gets the shift, so every hour a request sits in an inbox matters.
  • Nurse unit managers approve 20 to 40 agency timesheets a week, often in one sitting before the payroll cut-off.
“This is the bit that used to take my Monday morning.”
Client manager on bulk approval, usability testing
One place for clients to request shifts and approve timesheets, so agencies don't copy and paste and clients don't chase agencies.

How I work on it

I first worked on Colleago in 2020, when it was a startup. Now it's scaling, and still changing every week.

Understand

  1. Map both client journeys into the PRD

    Creating a request and approving a timesheet, from the gap on the roster to the temp getting paid. The journeys fed the client portal v2 PRD, owned by the PO and the source of truth for scope.

    WithPODesigners

    Journey map: create a work request
    Create a work request: 9 steps, 3 of them uncertain in testing.
    Journey map: approve a timesheet
    Approve a timesheet: from the temp's phone to the agency's billing.
Design

  1. Design the client portal

    From the dashboard to sending a request. The example here is a school's account.

    WithDesignersPO

    Dashboard. The week's shifts, and one-click repeat requests.

    1 / 4
    Client portal dashboard with a shift summary, quick requests and a calendar
Test

  1. Test, then turn findings into change requests

    Three rounds of moderated think-aloud sessions, July to September, with client managers and agency admins on the live product. Findings became 12 change requests with evidence, priority and status; I checked them against the PRD with Claude, and two needed a PO decision.

    WithClient managersAgency adminsPO

    Usability session notes with task results and observations
    Session notes: task results, timestamped observations and follow-up actions.
    Consolidated testing feedback and change requests
    Consolidated feedback, updated weekly while round 3 synthesis continues.
Ship

  1. Design in code, through pull requests

    Some components live in Figma and some only in the repo. I start from the source of truth, branch from main, change it with Claude Code and open a pull request that explains what changed, what each reviewer should check and what's left out.

    WithDesignersEngineering

    Workflow from Figma to production through Claude Code
    How three designers ship changes in one repo.
    Claude Code summarising a branch and opening a pull request
    A round 3 PR: five change requests, with reviewers and tests listed.

What testing is changing

Timesheet approval is close to target. Creating a request is where the friction sits.

  • Templates and repeat requests weren't found4 of 9 peopleIn progressI didn't even see that, I just saw the hospitals.
    Recent requests and templates shown first, and a Duplicate action on every request.
  • The second schedule block was misunderstood6 of 9 peopleIn review
    Renamed to “Add another shift pattern”, with a shift count on each block.
  • Unsure which agency receives the request4 of 9 peopleDoneWhich agency? We use two.
    The agency is named on the send button and in the confirmation.
  • No rostered vs actual comparison6 of 9 peopleIn progress
    Rostered and submitted hours side by side, with variances highlighted.

A mistake that changed how we ship

Early on, design changes skipped review. A branch I cut from an older version overwrote another designer's component update, and we only noticed once it was live.

  • Branch from the latest main every time, one change request per branch
  • No merge without a pull request and two approvals: a designer and a developer
  • Every PR carries a written summary, so the whole team knows what changed
With three designers in one repo, the process is part of the design.

Working with stakeholders

Three designers, a PO, an engineering squad and 22 agencies relying on one product while testing runs.

Who I worked with, and on what

Product OwnerScope, the PRD and open decisions
Two designersShared components and a review on every PR
Engineering squadEndpoints, tests and releases
Agency adminsInvite clients and receive requests
Client managersHospital nurse unit managers, in every testing round

Blockers, and how I moved them

  • Who owns the shift rate: the client or the agency?Rates come from the agency contract, so I'm designing a read-only rate with a “request a different rate” note.
  • Should clients approve timesheets from email?Parked for a security review. Meanwhile, a deep link returns to the exact timesheet after sign-in.
  • Four managers asked to approve on their phoneRaised as a scope question for v2, with the evidence from testing.

What we're aiming for

The success measures in the PRD, and where we are:

90%task success creating a request. Today: 67%
< 1 minto send a repeat request
85%of timesheets approved within 48 hours

Of the 12 change requests: 4 done, 2 in review, 3 in progress, 1 waiting on a decision and 2 in the backlog.

Reflection

I first worked on Colleago in 2020, when it was a startup. Coming back to it now, the biggest change for me is working in one codebase with two other designers, and thinking about how a change reaches production, not just how it looks.

More work
Sensand

Designing farm tasks into an existing IoT platform

Apta

A health tracker for families living apart, live in 2 weeks