Making AI job matches explainable for 1,000+ enterprise users

Background

Large organisations struggle to see what skills they actually have, and employees rarely know what’s possible for them inside their own company.

This startup set out to fix that with an AI-⁠powered ecosystem matching employees to jobs and courses, giving HR real workforce visibility, and connecting training sponsors to job seekers.

I was the sole designer for 2+ years, covering all three platforms across web and mobile. Two I built from scratch: no UI kit, no prior files, no comparable products to learn from. The third, the admin platform, I inherited and reworked until it belonged to the same system.

Problem

The platform’s answer was AI matching: employees build a skills profile, the system matches them to jobs and courses, and HR sees skills across the workforce. After the web MVP launched, 6 usability sessions showed two problems, and together they caused a third.

1. 1

   Employees didn’t trust the matches.

   They couldn’t tell why a job was suggested, what the system saw in their profile, or how to get better results.

2. 2

   Onboarding felt like homework, and profiles stayed thin.

   10+ steps, all of them skippable. Whatever people skipped left their profiles too thin for good matches.

3. 3

   HR had nothing to act on.

   Without full profiles and matches employees trusted, HR had no skills data and no internal candidates.

The trust problem on the employee side was the client’s problem too.

What made it harder: an investor deadline that gave me 6 weeks for the whole employee mobile app, two product owners who changed mid-⁠project, no UI kit, and three very different users (employees, HR managers, admins).

Process

Building an MVP under pressure. The first investor deadline gave us weeks. I had 6 weeks to design the entire employee mobile app from scratch, while the product vision was still being defined, so alongside delivery I was shaping it: researching competitors, studying patterns in similar platforms, and working with the team to define what good meant here. None of it was formal research. It gave us enough structure to move fast without guessing. We shipped, and we knew speed had a cost.

Fixing what rushing had broken. Before moving to web, I ran a heuristic analysis of the mobile MVP and found we hadn’t taken accessibility seriously enough. WCAG AA isn’t optional in this industry, so it became a non-⁠negotiable fix, carried into every subsequent screen.

Then, real users. Once the web MVP launched, I ran 6 usability sessions with employees from prospective enterprise clients. The sessions surfaced what no metric could show.

Users didn’t trust the AI recommendations because they didn’t understand them.

They didn’t know why a job was suggested, what the system saw in their profile, or how to get better results. The onboarding felt like homework.

Solutions

Onboarding: only what the matching needs

The old onboarding had 10+ steps, and any of them could be skipped. It asked for a lot, and whatever people skipped left their profiles too thin for good matches. The redesign went the other way.

• Only the data matching can’t work without. We kept the 5 steps that already give fairly accurate recommendations and cut the rest. 13 screens became 8.
• No skipping. All 5 are required. Five steps people can’t skip give the matching more to work with than 10+ optional ones.
• Completing the profile improves results. A nudge to “add up to 30 skills for better recommendations” ties every extra skill to better matches, so filling in the profile stops feeling like a form.
• Reasoning from the first card. Match reasoning and the skill gap show up on the very first matches, so users see what the system saw and what to add next.

Everyone who finishes onboarding now has a profile complete enough for useful matches, in fewer screens than before.

For the client, that means skills data on every employee who signs up.

Making AI legible: Skill Passport (employee app)

Employees didn’t act on recommendations they couldn’t understand, so every place a recommendation appears now says why.

• Match reasoning on every job card. Employees see why a job was suggested, so they can judge it instead of taking it on faith.
• Skill Gap view. Match vs. missing at a glance, so the next step, a course or a skill to add, is obvious.
• Job card labels. High Demand, High Paying and High Skills Match let people go for what matters to them first.
• Anonymous applications. No name, no photo, so applying for an internal role feels fair and safe.

A recommendation became something employees could act on, and acting on it is what fills the client’s internal pipeline.

The rest of the ecosystem

Trust on the employee side only matters if HR acts on the same matches. Before designing the HR platform, I mapped the full hiring workflow with a business analyst and traced how one status change cascades across employee, HR and admin. Skill Source (HR) and Mission Control (admin, inherited and reworked) were built on that map, so all three products show the same matches and the same statuses.

Skill Source (HR platform). Built around how HR managers actually work:

• Vacancy funnel analytics. Matches → Active Candidates → Offers → Hired, so HR sees where candidates drop out of each vacancy and where to step in.
• Matches vs. Shortlisted. A working shortlist kept apart from the full list of matches, so nobody gets lost between stages.
• Cross-⁠vacancy matching. A strong candidate for one role surfaces for others too, so internal talent isn’t lost after one rejection.

HR can hire from inside the company, which is the point of the platform for the client.

Mission Control (admin platform). It already existed but felt like a different product. I simplified the UI, reworked the programme status logic and added Participant and Employer profile screens, so a status change means the same thing to the employee, HR and the admin, and programmes don’t break in the gaps between products.