Case Studies: Telling the Story of Your Work

You'll learn to transform project details into a credible story using a five-part narrative arc. By the end you'll be able to filter out feature tours and highlight your specific role and impact. This lesson gives you a framework for avoiding common pitfalls like hiding your contribution or skipping honest reflection. Learning Objective: By the end of this lesson, learners will be able to structure a UX case study using a five-part narrative arc that highlights role, decisions, and impact. Transcript The Problem with Feature Tours Ask a UX team how they handle case studies, and the answers cluster into a few approaches. [pause:1s] Most start with a feature tour, listing every button and screen without explaining the why. This is the most common pitfall, hiding your actual role and skipping reflection. [pause:1s] The core issue is that these tours lack a story and fail to demonstrate critical thinking. Recruiters and peers look for decision-making, not just visual output or a pretty interface. [pause:1s] When you list features without context, you hide your contribution and miss the chance to show impact. The goal is to turn a finished project into a credible, compelling story for portfolios or talks. [pause:1s] You need to identify the five components of the UX narrative arc to avoid this trap. By applying the narrative framework, you distinguish between essential story elements and irrelevant feature details. [pause:1s] That sets the stage for building the five-part structure that actually showcases your work. Key Points: Real-world scenario: A portfolio entry that lists every button and screen without explaining the 'why'. The core issue: Feature tours lack a story and fail to demonstrate critical thinking. The goal: Turn a finished project into a credible, compelling story for portfolios or talks. Why it matters: Recruiters and peers look for decision-making, not just visual output. The Five-Part Narrative Arc The sequence begins by establishing the context and the problem, which means you have to define the user need and the business challenge with absolute clarity right from the start. You are not just listing features here, because a feature tour with no story fails to demonstrate critical thinking, so you must anchor the listener in the specific pain point that demanded a solution. When you skip this foundational step, the rest of your case study floats without gravity, and the audience struggles to care about the screens you designed later. The reason is simple: people connect with struggles, not just solutions, so you need to articulate the 'why' before you ever show the 'what'. This first step sets the stage for everything that follows, ensuring your work feels necessary rather than just decorative. The second step requires you to explicitly state your role versus what the team did, because hiding your actual contribution is a common pitfall that undermines your credibility. You might feel modest about claiming credit, but the field treats vague language as a red flag, so you must distinguish your specific inputs from the collective effort. Instead of saying the team built the app, you need to say you led the user research or defined the information architecture, which clarifies exactly where your expertise lies. This transparency allows hiring managers to assess your individual capabilities, rather than guessing what you might have done behind the scenes. When you are clear about your role, you avoid the trap of diluting your impact with passive voice or ambiguous group statements. The third step highlights the process and the key decisions you made, which means you should focus on the specific choices and the reasoning behind them. You are not documenting every single task, but rather explaining why you chose one path over another, because that reasoning reveals your strategic thinking. For instance, you might explain why you simplified a login flow to reduce drop-offs, rather than just stating that you designed the screen. This distinction separates a mechanic who follows instructions from a designer who solves problems, and it shows how you navigate trade-offs in real time. Experienced practitioners look for these decision points, because they indicate how you will handle complex challenges in future projects. The fourth step presents the outcome and its impact, requiring you to share measurable results or qualitative feedback rather than just claiming completion. A project is not a success story if it lacks evidence, so you must avoid the pitfall of having no measurable outcome by citing specific metrics or user quotes. Whether it is a fifteen percent increase in engagement or a reduction in support tickets, these data points validate the work you described in the previous steps. Without this evidence, your case study remains an opinion, but with it, you transform your narrative into a credible account of value creation. The field respects data, so let the numbers or the user voices speak for the effectiveness of your design. The final step involves honest reflection, where you discuss what you learned, what failed, and what you would do differently if you started over. Skipping reflection is a missed opportunity to show growth, because perfection is not the goal, but continuous improvement is. You might admit that a certain assumption was wrong or that a timeline was unrealistic, which demonstrates self-awareness and maturity. This vulnerability makes you more relatable and trustworthy, because it shows you are capable of learning from mistakes. By including this final piece, you complete the five-part narrative arc, turning a static project description into a dynamic story of professional development. That's the structure of the work; the specific decisions practitioners face inside it come next. Key Points: Step 1: Context and Problem — Define the user need and business challenge clearly. Step 2: Your Role — Explicitly state what you did versus what the team did to avoid hiding your contribution. Step 3: Process and Key Decisions — Highlight the specific choices made and the reasoning behind them. Step 4: Outcome and Impact — Present measurable results or qualitative feedback, not just completion. Step 5: Honest Reflection — Discuss what you learned, what failed, and what you would do differently. Worked Example: Filtering Content Let’s say you’re staring at a draft case study that reads like a feature tour, listing every button and screen without explaining the why. You’ve spent hours describing the visual style, but the reader still doesn’t understand the impact of your work. The core issue is that feature tours lack a story, so you need to apply the narrative framework to distinguish between essential story elements and irrelevant feature details. Start by auditing your text for descriptions that don’t drive the narrative forward. Take a common statement like "I designed the login screen," which tells the reader what you made but not why it matters. Replace that with "I simplified the login flow to reduce drop-offs by fifteen percent," which connects your action to a measurable outcome. This shift transforms a passive description into an active demonstration of critical thinking, because it shows how your design decisions solved a specific business challenge. The reason this works is that it anchors your contribution in user behavior rather than just visual output. Another frequent pitfall is hiding your actual role behind vague team statements, such as "the team built the app." This phrasing obscures your individual contribution, so you need to explicitly state what you did versus what the group achieved. Change that to "I led the user research and defined the information architecture," which clarifies your specific expertise and leadership within the project. Experienced practitioners notice that clear role definition builds credibility, because it allows hiring managers to assess your exact skill set. To maintain narrative tension, ensure every section answers the question "So what?" before you move on to the next point. If a paragraph describes a feature but doesn’t explain its impact on the user or the business, cut it entirely. This discipline forces you to prioritize impact over inventory, which keeps the reader engaged with the story rather than the specs. The field treats this pattern as a warning sign: portfolios that list features without context fail to demonstrate strategic thinking. By filtering out irrelevant details and highlighting your specific decisions, you turn a finished project into a credible, compelling story for portfolios or talks. This approach ensures your case study highlights role, decisions, and impact, rather than just showcasing pretty screens. Now that you’ve learned to filter content for narrative strength, the next section guides you through practicing these changes on your own work. Key Points: Worked example: Analyzing a draft case study to cut irrelevant feature descriptions. Guidance: Replace 'I designed the login screen' with 'I simplified the login flow to reduce drop-offs by 15%'. Guidance: Replace 'The team built the app' with 'I led the user research and defined the information architecture'. Guidance: Ensure every section answers 'So what?' to maintain narrative tension. Practice and Transfer Consider your last project and ask yourself which part of the five-part arc feels weakest in your current portfolio. You might find that you hid your role or skipped reflection entirely, which means the story lacks the critical thinking that hiring managers look for. The reason this matters is that a feature tour without a narrative fails to demonstrate your specific contributions to the team’s success. Pause and think about one case study where you can identify a project where you hid your role or skipped reflection. Experienced practitioners notice that rewriting the role section to explicitly name your contributions transforms a generic description into a compelling professional narrative. When you apply this arc to your next portfolio update or conference talk outline, you’ll see how much stronger the story becomes. The signal of strong work here is a clear distinction between what the team did and what you specifically led. So when you rewrite that section, focus on the decisions you made and the impact those choices had on the final product. That brings the lesson full circle, back to the listener and the moment they’ll first put the protocol into practice. Key Points: Practice prompt: Identify one project where you hid your role or skipped reflection. Reflection question: Which part of the five-part arc is weakest in your current portfolio? Transfer action: Rewrite the 'Role' section of one case study to explicitly name your contributions. Next step: Apply this arc to your next portfolio update or conference talk outline.