A pile of RFP submissions sits on a procurement officer's desk. Most look identical β glossy, high-fidelity mockups of websites floating in isometric space, paired with vague promises of "human-centered design." The reviewer flips through them in less than thirty seconds, looking for any sign that the agency actually understands how to solve a business problem. They find none, and the beautiful PDFs go straight into the trash.
This is the reality of the request for proposal (RFP) process. When clients look to hire a design partner, they are not shopping for art. They want to mitigate risk. They need to know that if they hand you a complex product, a tight deadline, and a messy set of requirements, you can deliver a solution that works.
To win these pitches, your portfolio cannot just be a self-indulgent gallery of pretty pixels. It needs to be a collection of highly structured, narrative-driven sales tools.
Why beautiful mockups aren't enough to win the pitch
Most design portfolios are built for other designers. We love to show off custom transitions, perfect typography pairings, and clean grids in Figma. But the marketing leaders and procurement officers reading your RFP response do not buy design the way designers do. They buy outcomes.
A beautiful mockup shows that you know how to use design software. It does not prove that you can diagnose a drop in conversion rates, navigate stakeholder misalignment, or build a scalable system. When you present only the final polished assets, you hide the very thing the client is trying to buy β your thinking.
A great case study is a narrative of decisions. It explains why a button was placed in a specific corner, why a certain user flow was abandoned, and how the final design directly serves the client's bottom line. If your case study does not explain the "why," the reader will assume you simply guessed your way to a pretty interface.
The four-part framework: Problem, constraints, process, and outcome
To write a case study that builds trust, you need a predictable structure. We use a simple four-part framework that mirrors the classic dramatic arc:
- The Problem: What was broken, and why did it matter to the business?
- The Constraints: What stood in the way of a simple solution?
- The Process: How did the team navigate those obstacles to find the right path?
- The Outcome: What did the design achieve, and how do we measure it?
Skipping any of these four elements makes the narrative fall flat. If you omit the constraints, the project looks too easy. If you omit the process, the solution feels unearned. By keeping this structure consistent across your portfolio, you give prospects a reassuring, structured look at how your team operates.
Setting the stage: Defining the problem and the constraints
Every great story needs a conflict. In a design case study, that conflict is the business problem. Start by defining exactly what was failing before your team arrived.
Do not use vague language like "the brand felt outdated." Instead, ground the problem in operational reality. For example, a hypothetical B2B SaaS client might have a powerful platform, but their self-serve onboarding flow is so confusing that users abandon the product before completing their profile.
Once the problem is clear, introduce the constraints. Constraints are not excuses β they are the guardrails that give your design decisions context and weight. Every project has them, whether it is a legacy tech stack, a strict brand guideline, or a hard deadline.
Let us look at a realistic, hypothetical example of how to frame this:
The Problem: Our hypothetical client, a logistics SaaS platform, was losing users during the initial setup phase. For example, data showed a 45% drop-off rate (illustrative number) on the third step of their onboarding wizard.
The Constraints: We had to redesign the onboarding flow within a strict six-week window before the client's public launch. Additionally, we could not alter the underlying database schema β meaning we had to work entirely within the existing data fields.
By framing the project this way, you show the prospect that you understand business metrics and work realistically within technical limitations.
Showing the process without the fluff
The "process" section of a case study is where many agencies lose their reader. It is tempting to dump every Miro board, user persona, and early wireframe into the page to prove how hard you worked.
Resist this urge. Your prospect does not have time to look at fifty identical sticky notes. Only show the process work that directly led to the final solution.
If you show an early sketch, explain why it failed and how it informed the next iteration. If you show a user testing map, highlight the single insight that changed your design direction.
For example, you might show a side-by-side comparison of an early Figma prototype and the final layout. Explain that during user testing, four out of five participants missed the primary call-to-action because it was placed below the fold. Showing how you identified a mistake, pivoted, and corrected it is incredibly reassuring to a prospect. It proves you rely on data and testing, not just aesthetic intuition.
Proving the outcome with clear, honest metrics
A beautiful design without a measurable outcome is just an art project. To win an RFP, you must prove that your work solved the problem you defined at the beginning of the case study.
Tie your final designs back to business-centric metrics. Whenever possible, use concrete numbers. If you designed a marketing site, talk about conversion rates or page load speeds. If you built a design system, talk about how much faster the client's internal engineering team can now ship new features.
Here is how you might write an outcome section using illustrative metrics:
The Outcome: The redesigned onboarding flow reduced the setup drop-off rate from 45% to just 12% (illustrative numbers) within the first month of launch. By simplifying the interface and adding clear progress indicators, the client saw a 30% increase (illustrative number) in active weekly users.
If your client cannot share exact revenue or user numbers due to an NDA, focus on relative growth, operational efficiency, or qualitative feedback. Explain how the new design system cut their product team's launch time in half, or how customer support tickets regarding onboarding dropped significantly.
How we put this into practice at Northwind Studio
At Northwind Studio, we apply this exact narrative structure to our own web design and brand identity projects. As a small, craft-focused agency, we do not rely on massive sales teams or aggressive outreach. Instead, we let our case studies do the heavy lifting of building trust with B2B SaaS and professional services clients before we ever get on a call.
We treat our portfolio with the same care we bring to our client work β ensuring every case study clearly demonstrates how we navigate complex technical constraints to deliver highly accessible, scalable design systems.
If you want to win more RFPs, stop treating your portfolio as a static gallery. Start telling the stories of how you solve hard problems.
We help growing teams build clear, accessible web designs and robust design systems that turn complex product stories into clear business outcomes. If you want to collaborate on your next digital project, reach out to us at Northwind Studio.
FAQs
How long should a design case study be?
Keep it concise. A strong case study should take no more than four to five minutes to read. Use clear headings, bullet points, and bold text so busy marketing leaders and procurement officers can easily skim the narrative during an RFP review.
What if the client won't let us share metrics or NDA-protected data?
Focus on qualitative outcomes and relative growth. You can use percentages instead of raw numbers β such as "a 40% increase in sign-ups" β or focus on operational improvements, like how a new design system cut their product team's launch time in half.
Should we include early sketches and wireframes in the case study?
Only if they help explain a pivotal decision. Do not include sketches just to prove you did the work β instead, use them to show how you tested an assumption, failed, and pivoted to the correct solution.
How do we format case studies for PDF RFPs versus our website?
Your website should host the evergreen, highly visual version of the story. For specific RFPs, export a tailored PDF version that highlights the specific constraints and outcomes that match the prospect's current challenges.