What I did

Design System Extension

Ework already had a company-wide design system shared across several internal products, but it didn't yet cover what SAT needed. I extended it with around 20 new components — including a candidate card, a pipeline progress tracker, and a filter for switching between client companies and their open job postings — while keeping everything consistent with the shared system other teams relied on.

Recruiter Research

I interviewed seven of Ework's recruiters to understand how they were actually working day to day. The pain point was the same across all seven: there was no single system — work was scattered across spreadsheets, email threads, and a legacy tool nobody trusted. From there, I tested a few navigation concepts with them, focused on how to move between companies and job postings without losing track of which candidate belonged where.

UX & UI Design

I designed development-ready screens covering a candidate pipeline per client and an applicant profile that let recruiters compare a candidate's fields against a role's requirements to judge fit. I also designed a companion mobile app — built for COVID-era conditions, when much of recruiter-candidate contact was happening outside the office and recruiters needed to stay connected to candidates on the go.

Ework Group is a staffing and talent solutions company that recruits, places, and manages consultants on behalf of over 500 client companies across 50 countries. Before SAT, its recruiters were tracking every client's open roles and candidates through spreadsheets and email threads — the one legacy system built for this was so old and inconvenient that almost no one used it. I joined early to design SAT (Staffing Applicant Tracker), a web and mobile platform that gave Ework's recruiters a single place to manage requests, track applicants, and move candidates through hiring for every client account at once, replacing a patchwork that couldn't scale past a handful of clients.

Ework already had a company-wide design system shared across several internal products, but it didn't cover what a multi-client recruitment tool needed.

I extended it with around 20 new components — including a candidate card, an applicant profile view, a match-score indicator for candidate-role fit, a status badge, a job posting card, and a company/job switcher for moving between client accounts — while keeping everything consistent with the shared system other teams were building on.

Design System Extension

I ran a two-hour workshop with seven of Ework's recruiters, opening with a quick icebreaker (a round of memes, just to loosen people up) before asking everyone to walk me through what actually happens when a candidate applies — their real day-to-day process, in their own words. From there, I laid out a set of potential problems — missing follow-ups, forgetting which client a candidate belonged to, double-booking interviews, losing track of candidates between companies — and had the group dot-vote on FigJam to surface what actually hurt the most. Losing track of candidates between companies and forgetting which client they belonged to came out clearly on top. I reframed those into "How might we" statements to keep the group focused on the problem before jumping to solutions, then opened it up to free discussion.

The recurring ask was simple: an easy way to switch between companies and between job postings within a single company — several people described wanting something like tabs or a switcher. We closed with each person naming the one thing they most wanted from the new system, plus a quick retro on the session itself. The scale of the problem became clear from the numbers that came out of it: recruiters were juggling requests from 2–3 client companies at once, and losing 2–3 hours a day to manual tracking just to stay on top of it.

Recruiter Research

...

Concept Testing

...

Final Screens

After launch, average session duration grew from around 28 seconds to roughly 1 minute 43 seconds — a sign users were browsing rather than bouncing. The product manager also reported a drop in support tickets tied to navigation and search confusion, and agent activity grew alongside this, with more agents choosing to list on OnMap in addition to competing platforms — a meaningful trust signal in a market where agents are selective about where they invest listing effort. Traffic also rose over this period, though some of that likely reflects SEO and organic search gains rather than the redesign alone.

Outcome

What Was Done

This project combined a brand refresh with a full product redesign — rebuilding the design system from the ground up with tokens rather than hardcoded values, so a four-language, RTL-inclusive product could scale without constant screen-by-screen rework. Beyond the visual system, key decisions like prioritizing scrollable hierarchy over cramming every field above the fold, combining map and listings into a single view, and building agent-specific flows for desktop reflected a recurring pattern: choosing what a real user needed over what looked most impressive at first glance.

What Could Be Improved

With more time, I'd want proper before/after instrumentation in place from day one — session duration and ticket volume told a clear story here, but a lot of the reasoning during the project relied on qualitative interviews and judgment rather than structured A/B data. I'd also want to validate the RTL and multilingual system with real Russian and French-speaking users specifically, since most of the direct research happened with Hebrew and English speakers.