Usability Study and Redesign of a Public Service Flow

The problem with online public service flows

Almost everyone has fought with an online form that decides something important: a university admission portal that times out, a scholarship application that loses your uploads, a utility bill payment page that does not work on a phone, a hospital appointment system that asks for the same details three times. The people who suffer most are those with the least slack: first-generation students, older citizens, people on cheap phones and slow connections, and people reading in their second language.

These flows rarely get tested with real users, because the organisations that run them seldom have a UX team. That makes them ideal for a student project: the problems are real, testers are easy to find among people who actually use the service, and there is a lot of room to improve.

What already exists and the gap

• The GOV.UK Design System and Service Manual show what good public service design looks like: one thing per page, plain language, clear errors, and repeated testing with users.
• Code for Pakistan works with government departments on citizen-facing services and has released Digital Design Nizam, an open source design system for government digital services.
• Maze and similar tools run unmoderated tests on Figma prototypes and report task success, time and SUS scores.

The gap is local evidence. Most flows people struggle with have never had a documented usability study, and most student UX case studies redesign a flow without measuring anything. This project produces both a better design and proof that it is better.

What you build

You are the research and design team for one flow with a clear goal and end point, five to ten screens long. The users are the people who complete that flow; the audience for your output is the organisation that owns it and your examiners.

The main flow of the project: write the brief, interview users about the last time they used the service, test the current flow, map where people struggle, redesign the worst parts, check accessibility, test again with new people, and publish.

Use realistic dummy data in every test. Never ask participants to enter real identity numbers, passwords or payment details.

The technically interesting part

The hard part is running a fair before and after comparison with small samples. Five users per round finds most of the serious problems, but it cannot prove statistical significance, so the rigour has to come from method:

• The same goal-based tasks in both rounds, written without leading words from the interface.
• Different participants in each round, recruited from the same kind of user.
• The same measures: task success (complete, with help, failed), time on task, errors, and the System Usability Scale, where 68 is a commonly cited average.
• Every problem rated by severity with the evidence (quote, clip timestamp) that justifies it.

Show your evaluators the severity table and trace each redesign decision back to a numbered problem. Decisions you rejected and why are as valuable as the ones you kept.

How to evaluate it

• Task success per task, before and after, for five plus five participants.
• Time on task median per task, before and after.
• SUS score per round, reported with the caution that small samples vary.
• Severity count: how many critical and major problems from round one are gone in round two, and any new ones introduced.
• Accessibility: WAVE and contrast checks pass on every redesigned screen, and a keyboard-only walkthrough is documented.

Honest results, including measures that did not improve, count in your favour.

Suggested plan

1. Week 1: choose the flow, write the brief, get consent forms ready.
2. Week 2: five interviews and an affinity map.
3. Week 3: test the current flow with five people and build the journey map.
4. Weeks 4 to 5: redesign in Figma, accessibility review, prototype ready for testing.
5. Week 6: second test with five new people, write the case study.

Path to a product

This is a research and design project, so the product is your skill. The realistic next steps are a portfolio case study that gets UX and product design interviews, a paid usability audit for a university admissions office, private school or clinic that saw your work, or a volunteer contribution to a civic tech group. Package the method (brief template, task script, severity scale, report template) so you can repeat it quickly for a paying client.

Scope warning

Do not redesign an entire website or app. Do not build the redesign in code unless you have a developer partner and time left over. Do not present your redesign as official, use the organisation's logo in a way that implies endorsement, or publish participants' names or faces without written permission.

Learn what you need on Sefism

• Frontend roadmap : the basics of how the screens you design get built.
• Laws of UX : named principles to justify each redesign decision.
• GOV.UK Design System : proven patterns for forms, errors and question pages.
• UX Design Roadmap : research methods, testing and the skills around this project.
• WAVE Web Accessibility Evaluation Tool : automated accessibility checks for every screen.
• Figma Learn : auto layout, components and prototyping.

Get help with this idea

The choice of flow and the task script decide whether this project produces evidence or opinions. Tauseef can help you pick a flow you can test ethically, write tasks that do not lead participants, and structure the case study your examiners and future employers will read. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session