Technologist
A recruitment and talent management product built inside OBSS, spanning the core product, a dashboard, email, mobile and a website. I took the design lead for a time-boxed assignment during an active phase of development.
- Client
- OBSS
- Role
- Lead Product Designer
- Sector
- HR tech · talent management
- Surfaces
- Core product · dashboard · email · mobile · website
- Dates
- Jun 2023 – Jun 2024
- Team
- 1 mid-level product designer · business analyst · project manager · 10 engineers
01
Role and ownership
Role and ownership
I led design across the connected recruitment workflows (talent pipelines, job–candidate matching, profile evaluation, interview coordination, and administrative templates) and kept recruiter, evaluator, admin and talent actions consistent between them. I reviewed the work of the mid-level designer on the team.
02
Decisions, and what we set aside
Decisions, and what we set aside
The pipeline is a column-based board because that structure showed the most content at once and was the easiest for recruiters to manage. The alternative on the table was an accordion, and it was set aside.
The other call I made with the client was not to build a native mobile app. Mobile here is the responsive web experience, and that is what the mobile screens in the scope below are.
03
What was delivered
What was delivered
- Research & information architecture
- Working prototypes
- Multi-surface product interface
- Core product, dashboard, email & mobile
- 715 artboards
- Website
- 80 artboards
Counts describe the scope of the work, not its results.
04
Where it stands
Where it stands
At the end of the time-boxed assignment I transferred the project context and the ongoing design responsibilities to another designer.
05
The work
The work 7 views
-
01
Pipeline
Every stage, visible at once
A recruiter is never working one candidate at a time. Columns were chosen because a pipeline is faster to follow down them than across rows, and the actions work on a selection rather than a single line.
-
02
Matching results
A score that shows its working
Showing the reasoning was never optional: a score without its working was ruled out at the product level. One card per match carries the job, the candidate, who owns it, the score and the reasoning behind it, with filters sharp enough to cut a long list down fast.
-
03
Fit comparison
Two columns, no verdict
The screen not deciding is a product rule, not an omission. What the job asks for and what the candidate brings sit side by side, and the two lists go where a person can weigh them.
-
04
Candidate history
Nobody starts from zero
Spread across screens, a candidate gets lost. One profile holds the whole history (stage, technical interview, team comments, next step) so nobody has to reconstruct who they are.
-
05
Assessments
Written once, used every round
The template was in the product from the first definition, not patched in later: a test written for one role gets reused for the next, holding the questions, what must be answered, and how much each answer counts.
-
06
Scheduling
One calendar, not three
This was the hard one to build, the interface and the availability maths behind it had to agree, and it shipped anyway. Open interview slots sit beside the meetings already booked, so a time is chosen once and against the whole picture.
-
07
Decision
The decision, at the end of the evidence
The order is the personas' order, not the database's: candidate, required and preferred skills, assessed levels, languages, education, and the decision itself at the end.