TalentReef – Bulk Export Tool
Designing a self-service bulk export tool from scratch for enterprise HR — and letting research catch what logic alone would have missed.
TalentReef – Employee Forms Bulk Export
Senior Product Designer
Mitratech
Self-Service Enterprise Workflows
HR Managers, Recruiters & Admins
Quick Story
There was no bulk export capability in TalentReef at all.
HR Admins were either downloading one form at a time or raising support tickets — where an internal team manually processed exports 200 records at a time.
Before designing anything, I asked the PM one question neither of us could answer:
How will we know this is working?
That gap was the signal.
We built the success criteria first. Then we designed and tested against them.
When Round 1 usability testing began, the critical finding arrived within the first two interviews — users weren't finding the CTA.
Not because it was hidden. But because this was a completely new concept, and users had no mental model telling them where to look.
Research caught it before a single line of code was written.
That's exactly what it's supposed to do.
Context
TalentReef is an enterprise hiring platform used by restaurant and retail organisations to manage high-volume recruitment and workforce operations.
The primary users were HR Admins and Managers responsible for employee data exports as a routine part of compliance, payroll, and reporting workflows.
For them, this wasn't a one-off task. It was something they needed to do repeatedly — and the friction of doing it one form at a time wasn't an inconvenience. It was a daily operational tax.
The Problem
No self-service bulk export existed.
HR Admins managing hundreds of employee records across multiple locations had two options:
Export one form at a time. Or contact support and wait.
The Support team was manually processing these requests in batches of 200 — with no automated client notification when exports failed.
This wasn't just user friction. It was a support dependency scaling in the wrong direction.
And because this was a brand new concept in the product, discoverability was going to be as important as the flow itself.
8/8
Users located the tool without assistance
7/7
Gave positive overall feedback after Round 1
#1
Avoidable support category — confirmed eliminated
Process
Research & Discovery: I recruited participants via Pendo segmentation — active Admins and HR Managers only, test accounts excluded. Real users from the live platform. Not a convenience sample.
Round 1 usability testing with 8 enterprise users surfaced the critical finding within the first 2 interviews.
Users weren't finding the CTA.
Not because it was hidden. It had visual weight and logical placement. But this was a completely new concept — and users had no existing mental model telling them where to look. Their eyes went to familiar patterns they already knew.
This was research doing exactly what it's supposed to do: catching something early enough to fix it.
Round 2 was different. Not usability — scalability.
I ran Workflow Validation Sessions with 5–6 internal Support and Tech stakeholders. The question had shifted: will this hold at 10,000+ employee records? Will it actually reduce the support ticket category it was built to replace?
Answer: yes.
Key Insight: "A feature that solves a real problem but can't be found is still a failed design. Familiarity to the designer is not familiarity to the user."
Design Thinking:
Define success criteria before designing — not after
Validate new concepts differently from redesigns
Discoverability is a design constraint, not an afterthought
Scalability must be validated separately from usability
Self-service in enterprise SaaS is a respect feature, not a convenience feature
Design Decisions:
Decision 1 — CTA redesign post-research: Redesigned with primary navy blue treatment aligned to the ATS redesign system — unmissable on first visit. Labels refined based on actual user language — "One-time" not "Ad-hoc."
Decision 2 — 7-state status lifecycle: Designed explicit system states across one-time and scheduled exports — Queued, Processing, Completed, Partial Success, Failed, Canceled, Paused — each with defined available actions and recovery paths.
Decision 3 — Partial failure handling: Designed a breakdown table showing exactly what failed and why — "98/100 files exported successfully." Users know immediately without contacting support.
Decision 4 — Cross-functional dev handoff: Produced full interaction specs, action matrices per state, error states and edge case documentation — confirmed across PM, Engineering and Support before development started.
"Self-service isn't just a convenience feature in enterprise SaaS. Every time a user has to contact support for a routine task, the design failed them. Familiarity to the designer is not familiarity to the user."
Solution Summary
End-to-end self-service bulk export — one-time and scheduled types
CTA redesigned post-Round 1 based on research findings
7-state status lifecycle with explicit feedback and recovery
Partial failure handling with breakdown and downloadable failure report
Scheduling options including last-day-of-month to match real admin workflows
Full cross-functional dev handoff before development started
Additional findings from Workflow Validation Sessions:
Feature scales to 10,000+ employee records
Support team confirmed highest-frequency avoidable request category addressed
Feature currently in active development
What I'd Do Next:Instrument Pendo analytics on the CTA post-launch — track first-visit vs returning-visit discoverability
Run follow-up Pendo Poll with the same Admin segment to capture real export frequency needs
Track support ticket reduction post-launch to validate Workflow Validation Session findings
View All Work