How to choose a London UX agency for an education platform

Make it Clear and Foolproof are useful starting points for a London education UX shortlist. Their published work covers different problems: academic content for Cambridge University Press, and staff administration for UCL. Match the evidence to the product you need to improve before comparing proposals.

A university website, a research library, and a learning platform can share a client logo while asking completely different things of a designer. An agency that makes course pages easier to browse has demonstrated something valuable. It still needs to show how it would handle assessment, feedback, or a learner returning after an interrupted task.

Humbleteam publishes this guide and provides product research and design for London teams. The comparisons below use public accounts of each agency’s work. They identify relevant experience, without ranking firms or assuming that the original project team is available.

Which agencies have relevant public work?

Make it Clear: academic content and access

Make it Clear’s Cambridge Core case describes combining content from 2 existing platforms into a single experience. The work included user journeys, wireframes, testing, and interface design. The case specifically discusses helping people understand which content they could access and making reading easier on mobile.

That is a useful reference for an academic publisher or research platform with a difficult catalog. Ask the team to walk through search, access restrictions, and reading as a connected journey. A person finding the right paper still needs to know whether they can open it.

The agency lists a Twickenham, London location on the case page. Its published scope is academic content UX; buyers commissioning teaching or assessment software should request evidence for those workflows separately.

Foolproof: university staff workflows

Foolproof’s UCL case describes work with Zensar on an employee platform for tasks such as updating personal details and booking leave. The account covers research with university staff, reusable components, and integration with existing systems. One specific problem was uncertainty about whether changes had saved.

This case is relevant to a university improving internal tools or approval processes. It gives buyers something concrete to examine: how the team separated viewing from editing and communicated a completed action.

Foolproof lists a London office. Confirm the proposed delivery team and engineering scope. This is staff software evidence, so a student learning platform needs an additional conversation about learners, teaching, and assessment.

Humbleteam: strategy for student ventures

Humbleteam’s London service page describes product and design strategy work for student ventures at King’s College London. That experience is relevant to a university venture program helping founders define their products. It should not be presented as a university learning-platform implementation.

Humbleteam serves London teams from Prague and Dubai. For a broader education product brief, request a walkthrough of comparable product work and agree on research access, delivery responsibilities, and any sessions on site. Apply the same evidence test to the publisher of this guide as to every other candidate.

What does the portfolio need to prove?

Start with the activity that makes the product useful. A department website may need to explain a program clearly. An assessment platform must help a student submit the right work and understand what happens next. Both deserve usable interfaces, but they need different research participants and acceptance tests.

Use this table when reviewing a case:

Treat the last column as the start of a discussion. A polished screen does not explain the research, the constraints, or the decision behind it. Ask to see those connections.

What should a small evaluation project reveal?

Consider this illustrative scenario: a student uploads an assignment from a phone. The connection drops after the progress bar finishes. The student returns later and sees the file name, but cannot tell whether it is a draft or a submitted assignment.

Meanwhile, the teacher’s view shows no submission.

A useful agency exercise follows that disagreement through the system. Commission a paid, bounded discovery task using test data. Give the team access to someone who understands the submission rules and ask it to map what each person can establish.

The student needs a clear distinction between a file stored in a draft and work accepted for submission. The teacher needs to know which version is ready to review. A support colleague needs enough information to investigate the mismatch without asking the student to repeat everything.

Ask the agency to produce a short prototype and a state map covering:

• A saved draft that has not been submitted.
• An attempted submission whose result is still unknown.
• A confirmed submission with an identifiable version.
• Feedback the student can find when returning later.

Pay particular attention to the unknown result. A generic success message would be reassuring and wrong. A generic failure could prompt an unnecessary repeat submission. The design should show what the system knows and give the person an appropriate next step.

Engineers must confirm what the platform can detect. Academic staff must confirm deadline, resubmission, and feedback rules. Ask candidates to name those dependencies in their proposal.

How should the team test the result?

Recruit people who perform the relevant tasks, including participants who use assistive technology where it is relevant to the research. Test the student and staff views separately, then check whether they agree about the same submission.

Ask participants to explain what happened in their own words. Record whether they can identify the submitted version, understand its status, and find the next action. A fast click through the prototype can hide a mistaken understanding.

Keep interface outcomes separate from learning outcomes. In Lenny Rachitsky’s 2023 interview with Cem Kansu, Kansu described Duolingo’s Path team as pursuing learner navigation and learning efficacy through a mission that a single metric could not fully capture.

For an agency brief, that distinction matters. Making feedback easier to find is a testable UX goal. Establishing that students learn more requires a separate educational question and appropriate evidence. The proposal should make both responsibilities clear.

What belongs in the final brief?

Describe the product, the affected roles, and one journey that needs to work better. Include the current evidence, access to research participants, known system limitations, and the academic calendar. If workshops or observation must happen in London, specify who needs to attend and where.

Ask for the proposed designers, a relevant case walkthrough, and the exact outputs the institution will receive. Separate research and design from implementation, accessibility evaluation, and ongoing measurement so their owners and costs are visible. The London workshop preparation guide can help define the first decision the team needs to make.

By the end of the selection process, the institution should have a shortlist backed by relevant work and an evaluation task each candidate can explain. For the assignment example, that means a student and a teacher can agree on what was submitted, while an unresolved technical result stays visibly unresolved. That is specific enough to put in a brief and test before a wider redesign.