Welfound

Why this brief existed.

Recruitment runs on the recruiter's address book. Welfound's bet is that it should not have to. Instead of a recruiter working their own network, a community of verified professionals refers people they genuinely know into relevant UK jobs, and AI joins the dots between the roles and the community.

The mechanic is straightforward. Companies post jobs. Those jobs are matched to relevant people in the community, who can apply themselves, refer someone, or share the role into their own social networks. The company receives a curated shortlist and runs the rest of the hiring process on the platform. Successful referrals result in referral bonuses and charity donations. Welfound wants three things out of that: more accurate matches, a better candidate experience, and lower hiring costs.

Which makes this a UX problem before it is a product problem. The brief is blunt that the platform is going against the grain of the traditional recruitment process and depends on a network effect to work at all. If the interface is not intuitive, nobody adopts it - and without adoption there is no network.

What the students worked within.

Who the design had to serve

Internal recruiters, HR managers and hiring managers inside UK-based businesses - specifically people who are, or have previously been, in a hiring capacity.

Constraints in the brief

• The MVP was nearing completion. This was design work inside a live product, not a greenfield concept.
• A two-sided marketplace - community members on one side, company users on the other - and the brief deliberately scoped the project to the company side only.
• Company users have five key activities: creating a company profile, job creation, job promotion and management, screening shortlisted applicants, and communication management. The brief narrowed the team to the last two.
• The design had to serve social-impact goals as well as efficiency ones, which shaped what could be shown about a candidate and how.
• The platform is built on Next.js and React with Material UI; design work in Figma.

What the team actually did.

Taken from the team’s own final presentation back to the client — the research they ran, what it told them, and the design decisions it drove. Including the ones that did not work.

The team started from assumptions rather than pretending not to have any. They built a proto-persona of a hiring manager first, wrote down what they believed about him, and used it to recruit and steer four exploratory interviews with people currently or previously in a hiring capacity in the UK.

The interviews produced one finding that reframed the whole project: hiring managers do not have time to read. One put a number on it - "I spend 6-8 seconds to screen each CV. We [hiring managers] just don't have time." Another described the real bottleneck as being at the end, not the start: "It is more difficult to choose between the 10 final candidates than 100." Screening was not the hard part. Choosing was.

A second theme was fragmentation. Recruiters described information scattered across email, documents and separate systems, with manual re-entry between them, and named the risk that comes with it - sending confidential information to the wrong person. Communication was the other drag: chasing candidates for interview slots delayed hires, and self-scheduling came up unprompted as the fix.

Affinity mapping the four interviews produced the list of information recruiters said actually decides a shortlist: degree, core skills specific to the job, previous experience and years of it, location, right to work, salary expectation. They were equally clear that soft skills and personality matter and that the interview, not the platform, is where those get assessed - which set a useful boundary on what the design should try to do.

The team then wrote out their remaining assumptions and open questions explicitly - how many candidates apply, how many get shortlisted, whether recruiters actually need to compare finalists, what device they work on - and carried them into concept testing rather than designing over them.

Ideas were run through an impact-effort matrix. Two came out: a comparison tool showing the top few candidates side by side, and a tool that highlights the selected criteria inside a CV so a recruiter can spot what they are looking for without reading the whole thing. The first was the quick win, the second the bigger build.

Concept testing asked two blunt questions - do users actually need these features, and is the layout easy to navigate. The comparison tool tested well against a real behaviour: "It can save us [recruiters] from having to create a spreadsheet of shortlisted candidates." The CV highlight tool got a more useful answer than a yes - "I would rather see a summary of key factors about the candidates than seeing their CV" - which pushed the design towards summarising rather than annotating.

The final round amended navigation tabs, action buttons and applicant filtering, and the team handed back a set of opportunities they had evidence for but had not built: message and job-post templates, applicant self-booking into interview slots the hiring manager sets, and a single dashboard tracking every applicant through the process. On the AI matching at the heart of the product, one interviewee was direct about where the risk sits - the engine doing what it says on the tin is, in their words, most of the success of the platform.

The deliverables.