HalilErenÇelik
Case study · 2023–2024

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.

The work 7 views

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

You can write to me about the work, or about the things I make.