arrow_back View all case studies

Case study

INGRID data product

Leading a team of stakeholders through the User-Centered Design process to define a data product for graduate employers.

📖 Background

This case study covers a project exploring how student and graduate data could be used by employers seeking to discover graduates when hiring.

Third-party data showed a large number of UK job vacancies going unfilled each year despite high graduate numbers, so the organisation wanted to explore how we could help get more graduates into roles.

I led a round of user research interviews with recruitment professionals across SMEs and larger enterprises, as well as a handful of recent graduates, to build an understanding of their recruitment processes. Across those conversations, I identified a set of problems and needs that were common to most interviewees.

⚠️ Problem statements

Two problems stood out as the clearest opportunities:

“It can be difficult to find candidates from diverse backgrounds when trying to strengthen our teams.”

“We struggle to identify which University courses to target our marketing at when trying to attract high quality candidates. Some courses are more obvious for certain roles, but not knowing the courses on the fringe means we’re missing opportunities to hire great talent.”

✨ Ideation

By this stage the team had a clear, evidence-based understanding of the challenges users faced, and it felt like the right moment to move into solutioning — but the team was stalling on ideas.

I set up and facilitated a brainstorming workshop to unblock this. In Miro, I ran a virtual version of the group-passing technique: each person starts an idea on a sticky note, then moves to the next person’s note and builds on it, cycling round until everyone’s original idea has evolved through the group’s input.

The session ran smoothly and generated 18 distinct ideas. More importantly, it shifted the team’s mood — from feeling stuck to having a genuine pipeline of directions worth exploring.

✏️ Prototyping

I worked with the team to narrow the ideas down to two, assessed against technical feasibility, user value, implementation effort, and commercial value. We then built a prototype for each in Figma.

Prototype 1 - Gradspire

During discovery, graduates had spoken about their career aspirations — the roles they hoped to move into.

Gradspire translated that into a set of data dashboards, letting employers select a role they were hiring for and see insights on student aspirations tied to it — for example, the courses studied by graduates who aspired to become mechanical engineers. The premise was that this would let employers target marketing at students on courses they wouldn’t otherwise have considered.

Prototype 2 - INGRID

A more traditional BI platform, allowing employers to build custom dashboards from large student datasets.

🤔 Assumptions gathering

Before testing either prototype, I ran a short assumptions-gathering exercise with the team using bingo cards, surfacing what the team expected to hear in feedback ahead of time. It’s a technique I use deliberately to get a team invested in the testing process and thinking objectively about what they’re about to learn, rather than reading confirmation into the results afterwards.

🔬 Concept testing

I designed and ran a series of 1-2-1 interviews remotely over MS Teams, with team members observing and taking notes.

Each participant was given access to both prototypes and asked a series of open-ended questions, following a semi-structured approach that left room to pursue lines of enquiry as they emerged rather than sticking rigidly to a script.

For one interview, I made the call to let the participant explore both prototypes unprompted before asking about specific pages — a deliberate departure from how I’d typically structure a session, where the priority is usually filling defined gaps in understanding. Given how data-rich these particular prototypes were, it paid off: it let the participant surface what was actually relevant to them, rather than only what we’d anticipated asking about.

📊 Research analysis

I led the team through pulling our notes into an affinity map, building a shared, holistic view of the feedback across both concepts.

🗣️ User needs/requirements

Alongside concept feedback, the conversations also surfaced broader needs, which I captured separately to keep them distinct from concept-specific reactions.

📋 Product requirements

Bringing the concept feedback and user needs together let us define product requirements with a direct, traceable line back to a specific user need for each one — ensuring nothing in scope was there without evidence behind it.

📜 Concept statement

To close the project out, I turned what we’d learned and validated into a concept statement — a concise articulation of what the product would do, who it was for, and which problems it solved.

Bonus

Product Death Flow

To pressure-test our confidence in the outcome, I ran the concept through the Product Death Flow — a checklist I developed to keep discovery work anchored to both user value and commercial value, rather than letting either one drift out of view.

There was a real sense of achievement across the team when the concept made it through to the end.

Product funeral

Once we’d carried the valuable elements of Gradspire across into INGRID, I held a virtual “funeral” for Gradspire — a deliberate ritual to help the team treat an unsuccessful idea as a legitimate and valuable outcome of the process, not a failure to be quietly dropped. The intent was also practical: giving the idea a clear, documented end so no one would unknowingly revisit ground we’d already proven wasn’t worth pursuing.

It landed well with the team, and led to requests to run the same ritual for other retired product ideas going forward.