Remote Design, Video and Creative Jobs

What to Include in a UX Design Case Study

The sections every UX case study needs, from problem to results, with word counts, NDA tips, concept project rules and Nigeria-specific advice for remote roles.

By Dapo Ogundipe, Marketing, sales and creative careers writer

Updated 17 min read

Diverse office employees discussing project

A UX design case study needs nine things: the context, the problem, your role, the research, the ideas you tried and dropped, the final design, how you tested it, the result, and what you learned. Remote hiring managers reading it want to see how you think and decide. Polished screens with no reasoning behind them get skipped.

This matters more for Nigerian designers applying abroad than for almost anyone else. Nobody on a remote hiring team in Berlin or Toronto has watched you work. They may never have used a USSD menu or opened a Nigerian bank app. Your case study has to explain your context, prove your judgement and show you can write clearly, because that is how you'll work with them every day.

This guide goes through each section with a suggested length. It also covers what to cut, how to handle client confidentiality, and how to write up a concept project honestly. A hypothetical outline you can adapt is included.

Quick answer

A strong UX case study includes a one-line summary, the product and user context, a clearly stated problem and goal, your specific role, the research and what it changed, ideas you explored and rejected, the final design with the reasoning behind key decisions, testing, results (with metrics if you have them) and lessons learned. Keep it skimmable, and label concept or course projects as such.

What a UX case study is, and how it differs from a portfolio

A UX case study is a written account of one design project. It goes from the problem to the outcome and shows the decisions you made along the way. A portfolio is the collection of those case studies, plus your bio, contact details and CV link.

Hiring managers use the case study to judge three things:

  • Thinking: did you understand the problem before designing?
  • Judgement: can you explain why you chose one option over another?
  • Communication: can a stranger follow your work without you in the room?

The last point matters a lot for remote roles. Distributed teams make decisions in written documents, Figma comments and Slack threads. If your case study is clear, a hiring manager can reasonably expect your design specs and handover notes to be clear too.

How many case studies to put in your portfolio, and where to host them, is covered in our guide to building a design portfolio for remote employers. The short version: a few strong ones beat many thin ones.

The sections a UX design case study should include

Nielsen Norman Group's guidance on creating a UX design portfolio (Rachel Krause, 2019) lists what each case study should cover: the problem or hypothesis, your role, how research and testing led to the solution, the results, ideas you dropped, the impact, and lessons learned. UX Design Institute's article on what hiring managers look for in a UX portfolio groups the same material into four stages: problem, approach, process and result.

The table below turns that guidance into a working structure. The word counts are our editorial suggestion for a skimmable case study, not an industry standard.

SectionWhat it provesSuggested length
Title and summaryYou can state value quickly1 to 2 sentences
ContextYou understand the product and users60 to 120 words
Problem and goalYou define before designing50 to 100 words
Your roleHonesty about ownership40 to 80 words
ResearchDecisions came from evidence150 to 300 words
Ideas and iterationsYou explore and discard100 to 250 words
Final design and decisionsYou can defend trade-offs150 to 300 words
Testing and resultsYou check your work100 to 200 words
Impact and lessonsYou reflect and improve80 to 150 words

That adds up to roughly 900 to 1,500 words plus visuals. If yours runs much longer, the extra detail is probably better saved for the interview.

1. Title and one-line summary

Open with a plain title and a sentence that says what changed. "Redesigning loan repayment for a microfinance app: cut repayment steps from seven to four" tells a reviewer more in five seconds than "Project Phoenix".

Add a short fact strip under it: product type, platform (Android, iOS, web), timeline, team size and your role. Reviewers use it to decide whether to keep reading.

2. Context: the product, the users and the constraints

Describe what the product does, who uses it and what limited the work. Constraints might include a two-week deadline, no dedicated researcher, a legacy design system, or a regulator's rules.

Nigerian designers often skip this section, and it's the one foreign reviewers need most. If your users onboard with a BVN, pay through USSD, share phones, or ration mobile data, say so in a sentence each. Context that seems obvious in Lagos is new information in London.

3. The problem and the goal

State the problem in terms of users and the business, then the goal you agreed on. A good problem statement is specific enough to measure.

  • Weak: "The onboarding was confusing."
  • Better: "About half of new sign-ups quit at the identity verification step, according to the product team's funnel data, and support tickets mostly asked why verification failed."

Only include numbers you actually had. If you didn't have data, describe the evidence you did have, such as support tickets, app store reviews or stakeholder reports, and say that's what it was.

4. Your role and how you worked with the team

Say exactly what you did and what others did. NN/g's guidance specifically asks designers to describe their responsibilities and how they worked with teammates.

Hiring managers spot inflated ownership quickly, usually in the first follow-up question at interview. "I led the interaction design and ran four of the six usability sessions; our researcher wrote the discussion guide" is stronger than "I designed the whole app". It's also easier to defend.

For remote roles, mention how the collaboration worked: async reviews in Figma, weekly calls with a product manager in another time zone, handover to developers through Jira tickets. These details show you've already worked the way remote teams work.

5. Research and what it changed

List the methods you used (user interviews, a survey, analytics review, competitor analysis, usability testing of the old design), then spend most of the words on findings. One sentence for each insight, and one for what you did because of it.

A finding with a consequence reads like this: "Five of the eight traders we interviewed kept their repayment records in a notebook, not the app, so we added a printable monthly statement to the plan." A finding with no consequence is just a fact.

Show one or two research artefacts if they help: an affinity map, a short user quote, a simple user flow. Blur names and faces. NN/g recommends including process artefacts such as sketches, whiteboard photos and research documents rather than only final screens.

6. Ideas you explored, iterations and what you dropped

Show at least one direction you rejected and why. NN/g lists ideas that were explored but not pursued as something hiring managers want to see.

For example: "We considered a single long form for verification. We dropped it because testing showed users on low-end Android phones lost their progress when the app restarted." That one sentence shows you test assumptions, think about real devices and accept being wrong.

Low-fidelity sketches and wireframes belong here. Two or three images are enough. A wall of 20 wireframes makes the reader do your editing.

7. The final design and the key decisions

Present the final screens, but annotate them. For each important screen, add a short caption explaining the decision and the trade-off. "Moved the repayment amount above the fold because test participants scrolled past it" is a good caption. "Clean, modern UI" is not.

Be clear about which work is yours. If a visual designer produced the final UI from your wireframes, say so.

If you worked inside a design system, mention which parts you used and which you added. It shows you can work within constraints, which is most of the job at a larger company.

8. Testing and results

Explain how you checked whether the design worked: moderated usability tests, an unmoderated test, an A/B test after launch, or feedback from a pilot group. Give the number of participants and what changed after testing.

If you didn't test, don't pretend you did. Say what you would have tested and how, and explain the design principles behind your decisions. A reviewer will respect an honest gap more than a vague claim.

9. Impact: metrics, or honest evidence without them

Include results if the product shipped and you have permission to share them: completion rates, drop-off, support ticket volume, time on task, app store rating changes. UX Design Institute advises including metrics where you have them.

Many designers, especially freelancers and those on agency projects, never see post-launch data. In that case, write what you know: "The client launched the redesign in March. I didn't have access to analytics afterwards, but the product owner reported fewer verification complaints in the first month." Quote only what someone actually told you, and don't turn it into a percentage.

10. Lessons learned and what you would do next

End with two or three sentences on what you'd do differently and what the next iteration should address. This is the section reviewers use to judge self-awareness, so make it specific. "I'd recruit participants outside Lagos earlier, because our rural users behaved differently" beats "I learned a lot about teamwork".

What to leave out of a UX case study

Cutting is part of the craft. Leave out:

  • Every artefact you produced. Pick the two or three that explain a decision.
  • Generic process diagrams. A "double diamond" graphic copied from a course says nothing about your project.
  • Personas with no evidence behind them. If a persona wasn't based on research, drop it or label it as an assumption.
  • Long tool lists. Mention Figma, Maze or FigJam only where they explain how you worked.
  • Claims you can't back up. Invented metrics and inflated roles tend to come apart in the first interview.
  • Confidential material. See the NDA section below.

How long should a UX case study be?

A UX case study should be short enough to skim in a few minutes and detailed enough to support a 30-minute interview conversation. UX Design Institute's article says hiring managers have limited time, and a clear overview of your skills and approach should be understandable "within a few minutes". It suggests saving the deeper detail for interviews.

A practical test: read only your headings, captions and the first sentence of each section. If someone could still explain the project back to you from that alone, the length is right. If they couldn't, tighten the writing before adding more.

On numbers, NN/g suggests choosing three to five projects that match the work you want, with quality over quantity. UX Design Institute cites hiring managers recommending two to three case studies. Two to four solid case studies is a sensible target for most applicants.

Concept projects and course projects: how to include them honestly

You can include a concept project or course project if you label it clearly. UX Design Institute notes that entry-level designers can use course projects or hypothetical solutions, as long as they are marked as hypothetical.

Say at the top of the case study: "Self-initiated concept project. Not commissioned by or affiliated with [the company]." Then hold it to the same standard as client work. Talk to real users, test with real people (five friends of friends is better than zero) and show what you changed.

Many Nigerian designers start with the Google UX Design Professional Certificate. As of October 2026, Coursera's page for the certificate says it includes three end-to-end portfolio projects and takes about six months at 10 hours a week. It costs $49 a month in the US and Canada after a 7-day free trial, prices may be lower in other countries, and financial aid is available.

Thousands of other graduates have the same course projects, so a lightly edited course brief won't stand out. Change the problem to one you can research locally, such as a market-day stock tracker for traders or a PTA dues app for a school, and your case study becomes original.

For more ways to build design evidence before your first client, see our guide to creating a design portfolio without clients.

How to show UX work under an NDA

If a non-disclosure agreement (NDA) or client confidentiality limits what you can show, you can still write a case study. NN/g's guidance suggests three approaches:

  • Share process images rather than final screens.
  • Blur or redact sensitive details.
  • Recreate the designs with generic branding.

Before you publish anything, read your contract and ask the client or your former manager in writing what you may show. Many will agree to an anonymised version. Replace the company name with a description ("a Lagos-based digital lender"), remove real customer data and change exact business figures to directional statements ("completion improved noticeably after launch") unless you have permission to share them.

You can also keep a password-protected version and share the password only with recruiters. Say on the public page that a full walkthrough is available on request.

Nigeria-specific things to get right

Explain local context in one line, not one page

Foreign reviewers don't need a lecture on Nigerian fintech. They need just enough to follow your decisions. A single sentence such as "Many users pay through USSD codes on basic phones because mobile data is expensive" turns a confusing design choice into a smart one.

This context can become your strength. Designing for low bandwidth, shared devices, unreliable power and people with very different levels of digital literacy is valuable experience. Companies serving emerging markets want it.

Treat research participants' data properly

If your research involved real people in Nigeria, their personal data is covered by the Nigeria Data Protection Act 2023. KPMG Nigeria's summary of the Act explains that it was signed on 12 June 2023, replaced the 2019 NDPR regime and set up the Nigeria Data Protection Commission (NDPC) to enforce it.

In practice, for a portfolio:

  • Get participants' permission before recording sessions, and tell them how you'll use quotes.
  • Never publish names, phone numbers, BVNs, account details or faces without explicit permission.
  • Use first names only or labels like "Participant 3, trader, Onitsha".

This is general guidance, not legal advice. If you're researching for a company, follow its own consent process.

Build a portfolio page that loads on a slow connection

Some reviewers will open your case study on a phone. You'll also be editing it over Nigerian mobile data. Compress images, export screens as WebP or optimised PNG, and avoid autoplaying video. A case study that takes 30 seconds to load on a weak connection loses readers before the first heading.

Keep a PDF version of each case study too. Some application forms ask for an upload, and a PDF is easy to send when a recruiter asks on short notice.

Mention working hours and collaboration across time zones

If you've worked with a team abroad, say how. For example: "Worked async with a product manager in Toronto (5 hours behind Lagos in summer, 6 in winter), with a two-hour daily overlap for calls." It shows you already handle the most common practical problem in remote work.

How remote hiring teams use your case study

The case study usually comes up at three points in a remote hiring process:

  1. Screening. A recruiter or designer skims your portfolio to decide whether to interview. Headings, captions and the summary do the work here.
  2. Portfolio review interview. You present one or two case studies on a video call, often in 20 to 40 minutes, and answer questions about your decisions.
  3. Hiring panel. Other team members read your case study before the final round.

Prepare to present your strongest case study in about 15 minutes, leaving time for questions. Our UI/UX designer interview questions and product designer interview questions cover what interviewers commonly ask. Some companies also set a take-home task. That's a different exercise, covered in our guide to completing a remote UX design challenge.

Check eligibility before you polish a case study for one company

A brilliant case study won't help if the role isn't open to people in Nigeria. Many remote design jobs are limited to specific countries. For example, as of October 2026, Typeform's Greenhouse job board listed its EU remote roles as open in Germany, Ireland, the Netherlands, Portugal, Spain and the United Kingdom. "Remote" there doesn't mean "remote from anywhere".

Read the location line and the application form's country question first. On WorkRemote's job listings, each listing shows where applicants may live, which saves you that step.

Example (hypothetical): a case study outline for a Nigerian fintech project

The outline below is invented to show the structure. It is not a real project or company.

Title: Making loan repayment easier for market traders.

Summary: Redesigned the repayment flow of a microlending app used by traders in South-East Nigeria, reducing the steps to repay from seven to four. Android, 8 weeks, team of five, my role: product designer.

Context (about 90 words): The app gives small working-capital loans to traders. Most users run it on low-end Android phones, often share the phone with family, and top up data in small amounts. Repayments can be made by bank transfer or USSD. Constraints: no budget for new illustrations, an existing component library, and a regulator-required disclosure screen that couldn't be removed.

Problem and goal (about 70 words): The operations team reported that many repayments arrived late and support calls often concerned "where to pay". Goal: make the repayment amount, due date and payment options clear from the home screen, and cut repayment steps without removing the disclosure screen.

Role (about 60 words): I led interaction design and prototyping, co-ran user interviews with the product manager, and handed over specs to two Flutter developers. A visual designer reviewed the final UI.

Research (about 220 words): Eight interviews with traders in two markets (in person, with recorded verbal consent), a review of support tickets, and a walkthrough of two competitor apps. Key findings:

  • Traders checked balances on market days, not at home, often with poor signal. Decision: show the cached balance and due date offline.
  • Several relied on a family member to read the app. Decision: larger amount text and a plain "Pay ₦X by Friday" label.
  • USSD users didn't know the code was in the app. Decision: show the code on the repayment screen with a copy button.

Iterations (about 150 words): Explored a one-screen "pay now" button. Dropped it because the disclosure screen had to stay, and combining them confused testers. Tried a calendar view of repayments and dropped it because testers read it as a savings schedule.

Final design (about 200 words): Three annotated screens, each with a caption explaining the decision and trade-off.

Testing (about 120 words): Two rounds of moderated tests with five traders each. After round one, renamed "Settle obligation" to "Pay loan".

Impact and lessons (about 100 words): State what the client later reported, if anything, and what you'd test next.

A checklist before you publish

Go through this before sending your portfolio link to anyone:

  • The first two lines say what the project was and what changed.
  • Your role is specific and honest, with teammates credited.
  • Every research finding links to a design decision.
  • At least one rejected idea is shown, with the reason.
  • Final screens have captions that explain decisions, not adjectives.
  • Results are real, sourced from someone and permitted to share, or the gap is stated honestly.
  • Concept and course projects are labelled at the top.
  • Personal data and client secrets are removed or anonymised.
  • Images are compressed and the page loads on a phone over mobile data.
  • A PDF version exists.
  • Someone who isn't a designer has read it and can explain the project back to you.

Frequently asked questions

How many case studies should a UX portfolio have?

Two to four strong case studies is a sensible target. NN/g suggests choosing three to five projects that match the work you want, and UX Design Institute cites hiring managers recommending two to three. Pick projects that show different skills, such as research-heavy work and interaction design.

Can I get a remote UX job with only concept projects in my case studies?

Yes, at junior level some designers do, but it's harder than with real client work. Label concept projects clearly, research and test with real users, and choose a problem you can study closely. Adding one small real project, even unpaid work for a local business or NGO, strengthens your portfolio a lot.

What if my project has no metrics?

Describe the evidence you do have and say plainly that you didn't have post-launch data. Usability test findings, client feedback and support trends are all valid if they're true. Never invent percentages, because interviewers will ask how you measured them.

Should I include the full design process in every case study?

No. Include the stages that explain your key decisions and cut the rest. A case study on a small UI fix doesn't need personas and a full research plan. Match the depth to the project.

Is a UX case study the same as a product design case study?

They're very close, and many companies use the terms interchangeably. Product design case studies usually say more about business goals, metrics and working with engineers. UX case studies often say more about research and usability. Adjust the emphasis to match the job title you're applying for.

Should I host my case studies on Behance, Medium or my own website?

Any of them works if the case study is clear and loads fast. Your own site looks more professional. Behance and Notion are free and quick to set up. Platform choice is covered in our guide to building a design portfolio for remote employers.

Do foreign employers care about projects for Nigerian companies?

Yes, if you explain the context. Designing for low data budgets, shared phones and mixed digital literacy is relevant experience for companies serving emerging markets. Add one or two lines of context so reviewers outside Nigeria understand your decisions.

Key takeaways

  • A UX case study shows reasoning: context, problem, role, research, iterations, final design, testing, results and lessons.
  • Keep it skimmable, around 900 to 1,500 words plus annotated visuals, and save the rest for the interview.
  • Be precise about your role and never invent metrics or research.
  • Label concept and course projects clearly, and make course briefs your own by researching a local problem.
  • Protect client confidentiality and participants' personal data, and anonymise where needed.
  • Give foreign reviewers one-line context on Nigerian user realities. It can be your strongest selling point.
  • Check a role's location eligibility before tailoring your portfolio to it.

Next steps

Start by rewriting your strongest project with the section order above, then test it on a non-designer friend. To see the skills and tools remote employers expect, read our guides on becoming a remote UI/UX designer and becoming a remote product designer. When your case studies are ready, search "UX designer" or "product designer" on remote jobs open to applicants in Nigeria and use "Get email updates" to receive new matching jobs by email each day. If you'd like the WorkRemote team to rewrite your CV and LinkedIn profile to match your portfolio, see what's included in our CV and LinkedIn review, part of Premium.

Sources

Share or discuss this article

All posts