Real client brief

LEM Verify

Identity verification & RegTech

A web-based identity verification product. A user proves who they are by photographing an identity document and completing a short liveness video check, inside a flow that other businesses white-label as their own.

The problem

Why this brief existed.

Identity verification is a flow nobody chooses to be in. You are there because a bank, a landlord or a service will not let you proceed until you have photographed your passport and filmed your own face - and if you give up halfway, the business that sent you there loses you.

That makes the design brief unusually concrete. The team set three areas of focus: improve the completion rate, improve the speed of completion, and improve confidence and trust in the verification process. The first two are conversion. The third is the one that causes the first two.

Discovery produced four pain points, and none of them were cosmetic. Checklist fatigue, and having to hold multiple instructions in your head at once. Instructions that were more complex than they needed to be. Users unsure how to correct a mistake once they had made one. And no clear explanation of where the information goes or how it is used - which, in a flow where you are handing over your passport and a video of your face, is the whole ballgame.

The last one is the trust problem stated precisely. A user who does not know what happens to their data is a user deciding whether to finish.

Rethink and optimise UX and flow of the current ID verification web app so that the process is easy to use for all demographics.

LEM Verify, from the original brief
The brief

What LEM Verify asked for.

Rethink and optimise the UX and flow of the current identity verification web app so that the process is easy to use for all demographics.

Context

What the students worked within.

Who the design had to serve

People aged roughly 20 to 50 across the UK and Europe being asked to complete an identity check, with no assumption of prior experience. The brief's phrase "easy to use for all demographics" was the constraint that mattered: this is not an app anyone opts into, so the design cannot assume a confident or practised user.

Constraints in the brief

  • The team could not access LEM Verify's real end users, for legal and security reasons, and said so on the slide rather than quietly working around it. They assumed the role of the end user themselves and used a mix of research methods to fill the gaps that created.
  • The flow is white-labelled. Every screen has to carry a customer's branding alongside LEM Verify's, so the design had to work as a system that changes colour and logo rather than as a fixed look.
  • Terms and consent are not optional furniture - this is a regulated process, and the design had to place them somewhere that is both visible and not an obstacle.
  • The liveness check requires someone to film their own face and follow spoken prompts in public or at their desk. Awkwardness was treated as a design problem, not a user failing.
The design challenge

What the team had to figure out.

No answers were supplied with the brief. These are the questions the students had to research, argue about and design their way through.

  1. How do you provide context and purpose for the verification process, so a user understands why they are being asked for this before they are asked for it?
  2. How do you reduce the amount of text while improving the explanation? Fewer words and more clarity usually pull against each other.
  3. How do you reduce the awkwardness of capturing a likeness video - the part where someone has to talk to their own phone and turn their head on command?
  4. How should terms and consents be managed, balancing visibility against presentation, in a flow where consent genuinely matters?
  5. When a capture fails, how does the user find out and how do they recover without starting again?
  6. How much of the process should be visible up front - how many steps there are, and how far in you currently are?
The work

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.

Discovery was organised around four themes rather than a general trawl: knowledge and expectations, trust and security, information and visual complexity, and process complexity. Those four kept reappearing all the way through to the final recommendations.

From them the team defined four pain points and, deliberately, four matching goals - provide context and purpose for the process, reduce the amount of text while improving explanations, reduce the awkwardness of the likeness video capture, and manage terms and consents so they are visible without being an obstacle. Pairing each problem with a stated goal is what let them argue for specific design decisions later.

Those resolved into four solution areas: improve the onboarding experience, improve trust in the verification process, optimise the experience for a wider variety of users, and reduce the number of steps.

The wireframes were annotated with the reasoning, which is the part worth reading. On the onboarding screen: a progress bar, a route back to the previous screen, an explicit acknowledge-terms control, and both the customer's logo and LEM Verify's. The progress bar was specified as a component in its own right, with completed and upcoming states and a percentage rather than a step count.

The document capture screen went further. The instruction sits at the top, the capture area is marked out, and the background around it is blurred and darkened so the eye goes to the one place it needs to go. The error state was designed as a first-class screen, not an afterthought: the failure is named in plain language - "movement detected" - and it comes up in a different colour so it is unmissable.

The prototype was tested against a written hypothesis: that the new UX improvements would reduce cognitive load and increase verification efficiency. Testers were aged 28 to 56 across EMEA and Australia, drawn from a spread of professions, and deliberately mixed between people with prior experience of identity verification and people with none.

What came back was triaged into three buckets - implemented, idea, and needs further research - rather than treated as one undifferentiated list. Implemented: more context for why the identity information is requested, a larger acknowledgement box, and a switch from step counts to percentage complete. Confirmed as working: the getting-started instructions were clear and explicit. Still open: clarifying where the data is used.

Some feedback was too big to absorb in the round and was passed back honestly as ideas and open questions - an initial menu asking for nationality so other document types could be supported, a notification confirming that data has been deleted, and a testers' question the team could not answer, which was why the document and the face are not captured at the same time.

The before-and-after comparison shows what the work bought. The old flow led with a version string and an IP address, put terms and conditions early, and offered a green Continue with "or go back and try again" underneath. The new one leads with a percentage complete, names the step, tells the user what to check in the image, and puts consent at the point of submit - next to Retake, so the two available actions sit side by side.

A UI style guide was handed over with it: a typography scale, a fixed colour palette including a dedicated error colour, a repeated icon language, consistent button placement, and the redesigned face-zoning used in the liveness check. That is what makes a white-labelled product re-skinnable without falling apart.

From the presentation

The actual work.

Design artefacts from the deck the team presented to LEM Verify.

The LEM Verify project team slide with photographs of Ben Dair, product manager, Annabel Jones, visual designer, Ala Tayebi, fine artist, and Rob Chiummo, IT specialist.
The four UX Academy students who presented to LEM Verify in March 2021, with the role each took on the project.
Annotated LEM Verify wireframe of an onboarding screen, labelling the progress bar, the back control, the acknowledge-terms checkbox and the paired client and LEM Verify logos, with a separate progress bar component detail.
The onboarding wireframe, annotated with the reasoning. Note the progress bar specified as its own component with completed and upcoming states, and the space reserved for a white-label customer logo next to LEM Verify.
Annotated LEM Verify wireframe showing a document capture screen next to its error state, where a movement-detected message and the capture frame both turn red.
The error state designed as a first-class screen rather than an afterthought. The failure is named in plain language and comes up in a different colour, so a user who has made a mistake can see it and recover.
LEM Verify before and after comparison. The old screen is a dense document-upload page with a version string, a full-width green Continue button and a go back and try again link. The redesigned screen adds a percentage-complete progress bar, a plain instruction to check the image, consent to terms placed at the point of submit, and paired Retake and Consent and Submit actions. The photograph on the specimen identity card is redacted.
The clearest artefact in the deck: the old flow beside the redesigned one. A progress bar, an explanation at each stage, terms at the point of submit, and a single Consent and Submit action. The photograph on the specimen identity document has been redacted for publication.
LEM Verify UI style guide showing a type scale from heading large 24 on 32 pixels down to body copy small, a colour set with hex values for orange, error red and four greys, and UI elements including a primary button, a secondary Retake button, a step indicator and a checkbox.
The style guide handed over with the design: type scale, a named colour set with hex values, and the UI elements the flow is built from.
What the students produced

The deliverables.

  • Discovery research
  • Pain point and goal definition
  • Annotated wireframes
  • Interactive prototype
  • Prototype testing and feedback triage
  • UI style guide
Student team

Who did the work.

Ben DairAnnabel JonesAla TayebiRob Chiummo
How client projects work

Every cohort gets a real brief.

UX Academy courses are 100% live online, capped at 15 students, and built around a genuine client brief rather than a simulated exercise. Students work to the client’s real constraints and present their work back to the client — which is what turns a course project into a portfolio piece you can talk through in an interview.

All student workGraduate outcomes
Learn this

Advanced UX Design

View course →

Product Design

View course →

Want a brief like this on your CV?

Get the full curriculum and see how the client project runs.

By submitting, you agree to receive course updates and our occasional newsletter. Unsubscribe any time. Privacy policy.

Your turn

Work on a real brief. Build your portfolio.

Join the free masterclass to see how UX Academy teaches, or browse the courses to find your fit.

Join the free masterclassBrowse all courses