Choose a problem worth designing for
Two students start their capstone projects on the same day.
The first chooses "A redesign of Instagram". It sounds exciting. But she can't talk to Instagram's users in any structured way, has no access to its data, doesn't know its technical or business constraints, and ends up making beautiful screens based on her own opinions.
The second chooses "Helping customers of a small pharmacy in Surulere find out whether their medicine is in stock before they travel there." She can visit the pharmacy, interview customers in the queue, and watch the pharmacist answer the same phone question forty times a day. Her constraints are real: a tiny budget, customers on low-cost Android phones, and a pharmacist with no time to update a website.
Six weeks later, one has a pretty portfolio piece. The other has a story that shows exactly how she thinks, and evidence that her design helped real people. This module is your capstone: one complete project, from problem to portfolio. It starts with choosing a problem worth designing for.
Words in this lesson
| Word | What it means, in plain English |
|---|---|
| Capstone | A final project that brings together everything you've learned. |
| Case study | A written story of a design project: the problem, process, decisions and results. |
| Portfolio | A collection of your best case studies that shows employers or clients how you work. |
| Constraint | A real limit you have to design within, like budget, time, technology or users' devices. |
| Scope | What the project will and won't include. |
| Concept project | A self-initiated project, not commissioned or built by the organisation involved. |
What employers want to see
Nielsen Norman Group surveyed 204 UX professionals in charge of hiring about what they look for in a portfolio. Their comments came back to the same ideas:
- Show how you started with an opportunity and produced real value for users and the organisation.
- Explain what isn't in the design, and why, as well as what is.
- Show the messy process, not just the polished result: the problem, your role, the constraints, the timeline, what changed between iterations, and how research shaped the design.
That's why the problem you choose matters so much. A problem with no real users and no real constraints can't produce that story.
NN/g's advice for students
NN/g are direct about student portfolios. They say the first job is the hardest to get, and they strongly recommend an internship so you have at least one real-world project to show.
They also point out that student projects often have made-up constraints, including made-up users and personas, which makes them weak proof that you can design for the real world. Their advice:
- Choose problems with business relevance and realistic constraints.
- If a project does include unrealistic elements, say so in your portfolio, so employers don't assume you don't know better.
The capstone checklist
A good capstone problem passes every test below:
| Test | Question | Why it matters |
|---|---|---|
| Real people | Can you reach at least 10 people who have this problem, for interviews and two rounds of testing? | You can't do Modules 2 and 9 without them |
| Real problem | Is there evidence people struggle with this today, beyond your own opinion? | Research must discover, not decorate (Module 2) |
| Real constraints | Are the budget, technology, devices, connection and time limits real? | Constraints are what make design decisions meaningful |
| Right size | Can you complete one core flow properly in the time you have? | A finished small project beats an unfinished big one |
| Ethical and legal | Can you get consent, protect people's data under the NDPA 2023, and avoid harm? | Your reputation depends on it |
| Relevant | Does it show the kind of work you want to be hired for? | NN/g recommend prioritising projects that match the work you want |
| You care | Will you still care about it in week six? | Motivation carries you through the hard parts |
Where to find good problems
Look close to home. Many of the best capstones come from ordinary services people use every day:
- Small businesses: market traders, pharmacies, salons, repair shops, caterers, printers
- Schools and training centres: fees, results, admissions, parent communication
- Clinics and health services: appointments, prescriptions, test results
- Community organisations: churches, mosques, cooperatives, associations, NGOs
- Transport and logistics: bookings, deliveries, tracking
- Your earlier modules: the research you did in Module 2 may already point to a strong problem
Ideas to be careful with
| Risky idea | Why | Better version |
|---|---|---|
| "Redesign a famous global app" | No access to its users, data or constraints | A specific problem, for specific people you can reach |
| "Uber for [anything]" | Starts from a solution, not a problem (Module 1) | Research what the people actually struggle with first |
| "An app for all Nigerians" | Too broad to research or test properly | One group, one situation, one core task |
| "A social network for students" | Huge scope, and hard to test meaningfully | One specific student problem, like finding past questions for a course |
Be honest about what kind of project it is
Your capstone will usually be one of these:
| Type | What it means | How to present it |
|---|---|---|
| Client project | An organisation asked you, and agreed how the work is used | Follow any agreement; ask permission before showing their name or data |
| Partner project | An organisation let you research and test with them, but didn't commission it | Say so; get permission to name them |
| Concept project | Self-initiated, without the organisation's involvement | Label it clearly as a concept; don't imply you worked for them |
Never present a concept as client work. And if a real organisation asks you to keep things confidential, NN/g suggest ways to show your work without breaking a non-disclosure agreement (NDA): show process images instead of final screens, redact or blur identifying details, or recreate the designs generically without the client's branding.
Write your capstone brief
Before any research, write a one-page brief. You'll return to it at every stage.
Capstone brief: Pharmacy stock check
Problem (initial): Customers travel to a small pharmacy in Surulere without knowing if their medicine is in stock. The pharmacist spends a lot of time answering phone calls asking the same question. People: Regular customers collecting repeat prescriptions, often for older relatives; the pharmacist and one assistant. Evidence so far: 2 days observing: I counted 38 stock calls on day one. 3 informal chats with customers in the queue. Constraints: No budget for a custom app. Customers mainly use low-cost Android phones and WhatsApp. Pharmacist has no time to update stock manually. Must not share customers' health information. Type: Partner project (pharmacist has agreed to research and testing; name can be shown). Success would look like: Customers can find out whether a medicine is available before travelling, without calling; fewer repeated stock calls. Scope: One core flow: checking availability for a named medicine. Not in scope: payments, delivery. Risks: Stock data may not exist digitally. Fallback: design around the pharmacist's existing process. Timeline: 8 weeks (lesson 11.2).
(This is an example. Your evidence, constraints and names must be real, and anything personal must have consent.)
Notice the brief describes the problem, not a solution. It doesn't say "build an app". The research might show a WhatsApp message template, or a daily stock list, solves it better, as you saw with the church example in Module 1.
Compare your ideas before choosing
If you have more than one idea, score them honestly:
| Test (score 0–2) | Idea A: Instagram redesign | Idea B: Pharmacy stock check |
|---|---|---|
| Real people I can reach | 0 | 2 |
| Real problem, with evidence | 1 | 2 |
| Real constraints | 0 | 2 |
| Right size | 1 | 2 |
| Ethical and legal | 2 | 1 (health data needs care) |
| Relevant to the work I want | 1 | 2 |
| I care | 2 | 2 |
| Total | 7 | 13 |
Common mistakes
| Mistake | Better |
|---|---|
| Choosing a famous app to redesign | A specific problem for people you can reach |
| Starting from a solution: "I'll build an app for…" | Starting from a problem with evidence |
| A huge scope | One core flow, done properly |
| Made-up users and constraints | Real people and real limits, or clearly acknowledged ones |
| Presenting a concept as client work | Label concept projects honestly |
| Showing confidential work without permission | Ask; or show process, redact, or make it generic |
| No brief | A one-page brief you return to throughout |
The short version
- NN/g surveyed 204 hiring managers: they want to see real value, the messy process, your role, constraints, iterations and how research shaped the design.
- NN/g on students: internships are strongly recommended; avoid made-up users and constraints; choose problems with business relevance; acknowledge anything unrealistic.
- A capstone must have real people, a real problem, real constraints, the right size, ethics, relevance and your motivation.
- Be honest about whether it's a client, partner or concept project. For confidential work, NN/g suggest process images, redaction or generic recreations.
- Write a one-page brief describing the problem, not a solution.
Try it yourself
- List five possible capstone problems from your own life, community or earlier modules.
- Score each one against the capstone checklist, and choose the strongest.
- Spend at least two hours observing or talking to people involved, before committing. Write down what you saw.
- Decide whether it's a client, partner or concept project, and get any permissions you need.
- Write your one-page capstone brief, following the example.
- Ask a classmate to challenge your brief: "Is this a real problem? Can you reach the people? Is it too big?" Revise it.
You'll know you've got it when your brief describes a real problem, for real people you've already met, with constraints you didn't invent, and nothing in it assumes the solution.
More free previews
- ▶UX, UI, and why confusing them costs you20 min
- ▶Assumptions are not research: know what you actually know20 min
- ▶Set up Figma and draw your first screen20 min
- ▶Information architecture: why some apps feel obvious20 min
- ▶Design for the phone people actually own20 min
- ▶Spacing and the 8-point grid, used properly20 min
- ▶Why the words decide whether people finish15 min
- ▶Every screen has more than one state20 min
- ▶Why five users find most of the problems15 min
- ▶Design systems: why teams stop redrawing buttons20 min