A good prompt gives you an idea.

It does not give you a project yet.

And it certainly does not give you a case study.

You can choose a topic from the 100 UX/UI Design Prompts, open Figma, and design an onboarding flow, dashboard, form, and success screen within a few days. Technically, the project exists.

The problem is that we still do not know:

• what problem you are actually solving,
• who you are solving it for,
• why you chose this particular solution,
• which alternatives you considered,
• what you deliberately left out,
• what you learned during the process.

Without those elements, the case study becomes a presentation of screens with a short summary:

Users had a problem, so I designed an intuitive solution.

Everything is intuitive, users are delighted, and the world has once again been saved by rounded cards.

A real case study should demonstrate something far more important:

How you moved from a broad idea to a deliberate design decision.

If you are still choosing a topic, start with How to Choose the Right UX Portfolio Project Prompt.

Here, we will focus on the next stage:

How do you turn a selected prompt into a credible project and case study that demonstrates how you think—not only how well you use Figma?

A Prompt Is a Starting Point, Not a Problem Statement

Imagine that you choose this prompt:

Design a system that helps university students reserve and borrow equipment owned by their institution.

This is not yet a well-defined problem.

We do not know:

• what kind of equipment is available,
• who is allowed to reserve it,
• how the current process works,
• why the process is not working,
• who manages it,
• how often booking conflicts occur,
• what happens when equipment is returned late,
• whether users collect equipment in person,
• which rules and restrictions apply.

The prompt describes a general opportunity.

Your first task is not to design a search screen. It is to turn the idea into a problem hypothesis that can be investigated, narrowed, and challenged.

1. Decide What the Project Should Demonstrate in Your Portfolio

Before beginning research, write down why you are creating this project.

It is not only about learning UX.

A portfolio project is also a professional communication tool. It should help a specific person understand which problems you are capable of solving.

Ask yourself three questions.

What roles am I applying for?

Someone applying for their first UI Designer role needs a different project from a designer targeting complex B2B products.

Which skills do I want to demonstrate?

For example:

• research and data synthesis,
• process design,
• information architecture,
• designing for multiple roles,
• permission systems,
• working with data,
• accessibility,
• form validation,
• edge-case analysis,
• product thinking.

What proof will the audience look for?

It is not enough to write:

I am good at designing complex systems.

The case study should demonstrate this through a specific decision, dependency, or compromise.

In an equipment-booking project, you could prove that you can:

• design a process with multiple statuses,
• separate student and administrator permissions,
• handle booking conflicts,
• design errors and interrupted scenarios,
• reduce scope without removing the product’s core value.

That is much more useful than the generic statement “I create user-centred experiences.” There are probably more portfolios containing that sentence than there are genuinely user-centred experiences in the world.

2. Turn the Prompt into a Problem Hypothesis

At the beginning, you do not need to know the final definition of the problem.

You do, however, need an initial version that can be tested.

Instead of:

Students need an app for reserving equipment.

Write:

Students using shared university equipment may struggle to check availability, understand borrowing requirements, and make a reservation without contacting a member of staff directly.

This version still contains assumptions. However, it is much more useful because it identifies:

• the user group,
• the situation,
• possible difficulties,
• the current way of handling the problem.

You can now investigate:

• whether the problem actually exists,
• who experiences it most frequently,
• which part of the process creates the most friction,
• whether users need a new tool or simply clearer information.

A Useful Structure

[User group] struggles with [task] in [context] because [possible cause]. This results in [consequence].

Example:

Students completing multimedia projects struggle to find and reserve available equipment because information about resources and dates is scattered across several channels. This results in additional messages, booking conflicts, and delays in project work.

This is still not revealed truth.

It is a hypothesis to investigate.

3. Separate What You Know from What You Assume

In fictional portfolio projects, the line between fact and imagination can disappear faster than the budget of a project containing “just one more small feature.”

Create a simple table:

We know	We assume	We need to investigate
The university provides equipment to students	Availability is difficult to check	How do students currently check availability?
Equipment must be collected and returned	Reservations often overlap	How frequently do conflicts occur?
Not every student can borrow every item	Users want to book independently	Does a staff member need to approve the reservation?

This table protects you from designing a product for a problem you invented fifteen minutes earlier.

It also demonstrates design maturity. You are not pretending to know every answer. You know which answers you still need to find.

4. Gather Enough Context

A conceptual project does not require a six-month research programme.

That does not mean research can be replaced with a quick ChatGPT question:

What problems do students experience when borrowing equipment?

AI can help prepare questions or organise material. It cannot provide evidence about people whose behaviour it has never observed.

Depending on the project, you can use:

• interviews with potential users,
• a conversation with someone managing a similar process,
• analysis of existing products,
• policies and instructions,
• public user reviews,
• forums and industry groups,
• observation of the current process,
• available reports and data.

Research Should Answer Questions

Do not conduct interviews simply because the Double Diamond diagram contains the appropriate diamond.

Decide what you need to learn:

• How do users handle the task now?
• Where does the problem occur most frequently?
• What information is required before making a reservation?
• What can prevent someone from borrowing equipment?
• Who makes the final decision?
• Which errors have the most serious consequences?
• What should happen when equipment is not returned?

A good research question influences a later decision.

If the answer would change nothing, you may only be asking it so you can add a microphone icon to your case study.

5. Narrow the Problem Before Designing the Solution

After your initial analysis, the prompt will probably still be too broad.

An equipment-booking system could include:

• catalogue browsing,
• search,
• filters,
• reservations,
• approval,
• collection,
• returns,
• reporting damage,
• borrowing history,
• penalties,
• notifications,
• reporting,
• inventory management,
• staff accounts,
• multiple departments,
• integration with the university user system.

You do not have to design everything.

A case study is much stronger when it presents one carefully considered process rather than a digital city-state whose constitution you wrote between the login screen and Settings.

Define Four Things

Primary user:
A student borrowing equipment for a project.

Primary task:
Finding available equipment and submitting a reservation.

Key flow:
Search → review requirements → choose a date → reserve → receive confirmation.

Out of scope:
Full inventory management, equipment purchasing, financial settlements, repairs, and advanced reporting.

An “Out of Scope” section is valuable in a case study.

It shows that the project did not simply end somewhere by accident. You deliberately controlled its boundaries.

6. Map the Current Process

Before designing the future flow, understand what currently happens.

Even a simplified current-state flow can reveal:

• where the user begins,
• how many channels they use,
• when they have to wait,
• who needs to respond,
• where information is lost,
• which decisions are made by a person and which by the system,
• where errors are likely to occur.

The current process might look like this:

1. The student searches for equipment information on the department website.
2. They cannot find current availability.
3. They message a member of staff.
4. The staff member checks the calendar.
5. They ask for additional project information.
6. The student responds.
7. The date has already been taken by someone else.
8. The process begins again.

The problem is now more specific.

You are no longer designing a “modern booking system.”

You are trying to reduce:

• uncertainty about availability,
• the number of messages,
• repeated requests for the same information,
• booking conflicts,
• unclear rules.

7. Define the Constraints

Constraints do not ruin a project.

They are what makes a project begin to resemble a real product.

Without constraints, every answer is easy:

• add automation,
• display all the data,
• give users full control,
• send a notification,
• use AI.

In a real environment, the constraints might include:

• reservations require approval,
• some equipment is available only to selected departments,
• users can have no more than two active reservations,
• certain devices require completed training,
• dates are managed in a legacy system,
• staff do not have the capacity to review every standard request manually,
• availability data may be delayed.

The most interesting decisions emerge from these constraints.

Include Them in the Case Study

Do not write only:

The challenge was to create an intuitive experience.

That is not a constraint. It is the minimum expectation of the project.

Be specific:

Reservations had to account for user permissions, completed training, and limited equipment availability, but the process could not require manual review of every standard booking.

Now the reader understands what you were actually working with.

8. Consider Alternatives Before Choosing the Solution

A case study becomes credible when it is clear that the final solution was not the only idea that entered your mind.

For the booking process, you might consider:

Option A — Immediate Booking

The student selects an available date and receives confirmation immediately.

Advantages:

• fast process,
• less administrative work,
• immediate feedback.

Risks:

• not every user has the required permissions,
• unusual cases may go unnoticed,
• users may reserve unsuitable equipment.

Option B — Every Reservation Requires Approval

The student submits a request, and a staff member makes the decision.

Advantages:

• greater control,
• mistakes can be caught,
• exceptions are easier to handle.

Risks:

• longer waiting time,
• greater staff workload,
• uncertainty for the student.

Option C — Conditional Approval

Standard reservations are confirmed automatically, while unusual cases are sent to a staff member.

Advantages:

• faster handling of standard situations,
• control remains where it is genuinely needed.

Risks:

• more complex logic,
• rules must be defined clearly,
• unexpected exceptions may still occur.

A case study does not need to show twenty variations.

It is enough to show:

• which options existed,
• which criteria you used to compare them,
• what you gained,
• what you lost,
• why you made the final decision.

That is product thinking.

Not the number of frames.

9. Document Decisions During the Project

The worst time to reconstruct your design process is usually three months after the project ends, when you begin writing the case study and discover folders named:

• final,
• final-2,
• final-new,
• final-final,
• final-use-this.

Do not rely on memory.

Keep a simple decision log.

For every important decision, record:

1. What decision needed to be made?
2. Why was it necessary?
3. Which options did you consider?
4. What were the trade-offs?
5. Which risks did you identify?
6. Which option did you choose and why?
7. How does it affect the user, system, and business?
8. What still needs to be validated?

This documentation will later become the most valuable part of your case study.

You will not need to reconstruct your reasoning from the colour of a button and a file’s modification date.

10. Design the Logic Before the Interface

Before polishing the UI, verify:

• the main flow,
• user decisions,
• system responses,
• conditions,
• roles,
• statuses,
• errors,
• ways to reverse actions,
• interruptions and process recovery.

In the booking project, you need answers to questions such as:

• What happens if the selected date becomes unavailable while the form is being completed?
• Can the reservation be changed?
• When may the user cancel it?
• What happens if the user lacks the required training?
• Should the system suggest alternative equipment?
• What does “available” mean: available to reserve or physically ready for collection?
• Who can restore access after an overdue return?
• Will a partially completed process be saved?

These details demonstrate product design.

The attractive calendar can come later.

It will not be offended that it was not invited first.

11. Test Questions, Not Only Screens

A usability test should not be limited to checking whether users can click the purple button.

Test specific hypotheses:

• Do users understand the difference between availability and eligibility to reserve?
• Are borrowing requirements visible early enough?
• Is the “pending approval” status clear?
• Does the user know what to do after a reservation is rejected?
• Do alternative dates help users complete the task?
• Does collection information appear too late?

Document:

• what you wanted to test,
• what happened during the session,
• what you changed,
• what the result did not confirm,
• what requires further validation.

Not Every Change Has to Come from a Usability Test

A solution may change after:

• a conversation with a developer,
• discovering a technical constraint,
• analysing an access policy,
• finding an inconsistency in the flow,
• reviewing an edge case,
• reassessing the project scope.

A case study should demonstrate how decisions evolved. It does not need to ritualistically reproduce a textbook process.

12. Do Not Invent Impact

A fictional project may include:

• a problem,
• research,
• hypotheses,
• a prototype,
• tests,
• iterations,
• conclusions.

It cannot include invented business outcomes presented as facts.

Do not write:

The new flow reduced booking time by 45%.

Unless you actually measured it and can explain the method.

You can write instead:

During the moderated test, participants completed the primary task without assistance, but two out of five did not notice the required training information. In the next version, I moved this condition to the equipment details view and reservation summary.

Or:

The prototype reduced the number of steps in the main flow from nine to six. This does not yet prove improved efficiency in a real environment.

Or:

The solution would require further validation with the staff responsible for issuing equipment and verification of its integration with the university permissions system.

It sounds more cautious.

And considerably more professional.

13. Collect Case Study Material While You Work

Do not wait until the end.

Save:

• the original hypothesis,
• research questions,
• important quotes,
• observations,
• the process map,
• constraints,
• alternative concepts,
• rejected solutions,
• the decision log,
• test results,
• later versions of the flow,
• moments when you changed your mind,
• unresolved questions.

The most interesting part of the project often does not look impressive when it happens.

It may be:

• removing half the planned features,
• discovering that the real problem lies elsewhere,
• rejecting the first concept,
• changing the permission model,
• abandoning automation,
• moving a decision to an earlier stage of the flow.

Those moments later become evidence of how you think.

14. Structure the Case Study Around Decisions, Not Chronology

You do not have to describe every stage in this order:

1. Empathise
2. Define
3. Ideate
4. Prototype
5. Test

Design processes are rarely that polite.

A strong case study should function as a clear argument.

1. Context

What product, environment, and situation are involved?

2. Problem

What was not working, and why did it matter?

3. Your Role

What were you genuinely responsible for?

4. Constraints

Time, scope, technology, data, permissions, regulations, or access to users.

5. Key Findings

What changed the way you understood the problem?

6. Key Decisions

Which options did you consider? What trade-offs did you face?

7. Solution

What did you design, and how did it respond to the problem?

8. Validation or Outcome

What were you able to verify? What is still unknown?

9. Learnings

What would you do differently? What did the project teach you?

This structure answers the reader’s questions.

It does not force them to reconstruct your process from 47 screenshots and two sentences labelled “Ideation.”

15. Choose the Three Most Important Decisions

Do not try to describe everything.

The reader probably does not need to know why one tooltip moved eight pixels to the left.

Choose the decisions that best demonstrate:

• the complexity of the problem,
• your reasoning,
• how you handled constraints,
• consequences for the product,
• how the solution changed.

In the booking project, these decisions might be:

1. Conditional approval instead of manually approving every reservation.
2. Showing equipment requirements before the user selects a date.
3. Separating reservation status from equipment-readiness status.

You can describe each one using a simple structure:

Problem → options considered → constraints → decision → consequences

That is enough to show both the final screen and the reasoning behind it.

16. Show the Solution in Context

Mockups alone do not explain a product.

Instead of presenting a screen with the caption:

Equipment details

Explain:

• which user question the screen answers,
• which information received priority,
• what decision is being made,
• what the system communicates,
• which risk the solution reduces.

Example:

In the equipment details view, I combined availability with information about required permissions. Previously, users could select a date before discovering that they were not eligible to complete the reservation. Moving the requirement earlier reduced the risk of starting a process that could not be completed.

Now the screen has meaning.

It is not merely a rectangle with a shadow and an unusually confident heading.

17. Show What Changed

One of the strongest pieces of evidence in a design case study is a change of direction.

You can show:

• the first and final versions of the flow,
• the original hypothesis and later finding,
• two alternatives you considered,
• a problem discovered during testing,
• a removed feature,
• a change in priorities.

You do not need to prove that the first version was terrible.

You only need to explain why the next one was more appropriate.

For example:

Initially, every reservation required staff approval regardless of equipment type. Process analysis showed, however, that most basic loans followed the same conditions. In the final flow, manual approval remained only for specialist equipment and exceptional cases.

That is far more interesting than:

After testing, I improved the design.

The word “improved” can conceal almost anything, including changing an icon.

18. End Honestly

The “Learnings” section should not consist of statements such as:

• communication is important,
• users are the most important,
• design is a process,
• testing is always valuable.

All true, but roughly on the same level as discovering that water is sometimes wet.

Be specific:

• Which assumption turned out to be wrong?
• What was more difficult than expected?
• What did you remove?
• Which constraint had the greatest impact?
• What requires further validation?
• What would you do differently next time?

Example:

Initially, I treated equipment availability as a straightforward calendar problem. During the analysis, it became clear that user permissions, equipment condition, and preparation time were equally important. In a future iteration, I would map the difference between resource availability and immediate borrowing eligibility earlier in the process.

That is a real conclusion.

It demonstrates a change in how you understood the problem.

How ChatGPT Can Help You Create a Case Study

AI can support the process, but it should not write a fictional project history.

It can help you:

• organise raw notes,
• separate the problem from the solution,
• identify missing information,
• create an initial article structure,
• compare alternative narratives,
• shorten repetitive sections,
• shift the focus from screens to decisions,
• prepare a two-minute project presentation.

You can use the following model:

Lead → Expand → Refine → Elevate

Lead

Provide the context:

I am creating a case study for a conceptual university equipment-booking system. The project covered the primary student flow rather than the complete administrative tool. I have no business metrics or implemented product.

Expand

Ask for structure:

Propose three ways to organise the case study: around the problem, around key decisions, and around the transition from the current process to the target process.

Refine

Remove anything you cannot defend:

Remove all suggestions that require non-existent metrics, extensive research, or business impact. Focus the structure on three design decisions.

Elevate

Add your own judgement:

• the real context,
• reasons behind decisions,
• constraints,
• reflection,
• tone and argumentation.

ChatGPT can help organise the material.

It should not decide what was genuinely important or add drama where the project did not provide any.

In 15 UX Prompts for ChatGPT That Support Real Design Work, you will find practical examples for research, documentation, design decisions, and portfolio writing.

An Example Final Case Study Structure

For the project described above, the structure could look like this:

Project Title

Designing a University Equipment Booking System

Context

Students need equipment to complete projects, but information about availability, requirements, and reservations is fragmented.

My Role

Conceptual research, process analysis, scope definition, primary-flow design, and prototype validation.

The Problem

Users cannot independently confirm whether equipment is available or whether they meet the requirements to borrow it.

Constraints

• different permissions,
• mandatory training,
• limited resources,
• approval required for exceptions,
• no inventory-system integration within the project scope.

Key Findings

• availability did not automatically mean eligibility to borrow,
• requirements appeared too late,
• manually approving every reservation unnecessarily prolonged the process.

Key Decisions

• conditional approval,
• earlier visibility of requirements,
• separation of reservation and collection statuses.

Solution

A description of the main flow and key screens in the context of those decisions.

Validation

What was tested in the prototype, what changed, and what still requires validation.

Learnings

How the understanding of availability changed and which constraints would need to be considered during further development.

That is enough.

You do not need to document the entire project like an archaeologist studying the ruins of a lost Figma civilisation.

A Case Study Should Show How You Make Decisions

The prompt helps you begin.

Research helps you validate assumptions.

Constraints make the solution realistic.

Alternatives demonstrate that the final direction was not arbitrary.

Testing and iteration show that you can respond to new information.

The case study connects these elements into one coherent argument.

The most important sequence looks like this:

prompt → problem hypothesis → context → scope → evidence → constraints → alternatives → decisions → solution → validation → learnings

You do not need to prove that the process was perfect.

You need to demonstrate that it was deliberate.

Start with a Prompt. Finish with Evidence of Your Thinking.

Choose a project from 100 UX/UI Design Prompts, then narrow it to a problem you can investigate credibly and complete realistically.

Do not ask only:

What can I design?

Ask:

Which decisions will this project allow me to demonstrate?

Those decisions will later become the most important part of your case study.

Screens attract attention.

Decisions build credibility.

---

Do You Want to Use AI for Research, Documentation, and Project Storytelling?

The Designer’s AI Playbook includes a library of 50 UX prompts, the Lead → Expand → Refine → Elevate framework, and practical templates supporting:

• problem definition,
• design decisions and trade-off analysis,
• research and information synthesis,
• user-flow descriptions,
• decision logs,
• UX documentation,
• portfolio case studies,
• project presentations.

The book helps you use AI to organise a real process—not to invent a story that never happened.

Explore The Designer’s AI Playbook →