VP of Product at a Series B fintech company. 73 employees. Building a loan application platform. Needed to redesign their onboarding flow – drop-off was 68% at identity verification.

They interviewed top UX design agencies. One agency’s case study caught their attention: Complete redesign of an insurance application flow. Timeline: 6 weeks. Result: “42% increase in completion rate.” Beautiful before/after screens. Client testimonial: “Seamless process, highly recommend.”

They signed. Six-week timeline promised.

Week 12: First design delivery. Week 16: Second revision after dev team flagged technical issues. Week 19: Third revision after stakeholder feedback. Week 23: Final designs approved. Week 31: Implementation complete.

31 weeks. Not 6.

The completion rate did improve – by 31%, not 42%. Good outcome, but the case study version and the actual project looked nothing alike.

This is standard. Case studies from top UX design agencies are marketing materials, not project documentation. They show the highlight reel. They hide: The 4 revision cycles. The scope adjustments. The timeline extensions. The implementation problems. The client effort required. Who actually did the work.

It’s not dishonest – case studies aren’t meant to be comprehensive. But if you’re evaluating agencies based on case studies alone, you’re making decisions on incomplete information.

Here’s what case studies systematically leave out, why it matters, and how to evaluate agencies beyond the portfolio.

What Case Studies Hide About Timeline

The case study version

Typical case study timeline: “Project duration: 8 weeks” “Week 1-2: Discovery and research” “Week 3-5: Design iterations” “Week 6-7: Refinement” “Week 8: Final delivery”

Clean. Linear. Finished on schedule.

What actually happened

The real timeline breakdown:

Weeks 1-4: Discovery (planned for 2 weeks)

• Case study: “Conducted stakeholder interviews and user research”
• Reality: Waited 6 days for stakeholder availability. Research participants took 11 days to recruit and schedule. Discovery extended to 4 weeks.

Week 5: Kickoff delay

• Case study: Doesn’t mention
• Reality: Agency’s lead designer rolled onto another project the week discovery finished. New designer needed 5 days to ramp up. Design start pushed by 1 week.

Weeks 6-9: Design iterations (planned for weeks 3-5)

• Case study: “Iterative design process with client feedback”
• Reality: Three revision cycles. First revision: presented Monday, feedback consolidated by following Monday (8 days). Second revision: agency pushed back on technical constraints, clarification took 6 days, iteration took another week (13 days total). Third revision: 7 days.

Weeks 10-11: Implementation review (not in plan)

• Case study: Doesn’t mention
• Reality: Dev team reviewed designs, found 19 components that wouldn’t work with their tech stack. Back to agency for modifications. 2 weeks.

Weeks 12-14: Stakeholder approval (not in plan)

• Case study: Doesn’t mention
• Reality: CEO saw designs for first time in Week 12 (wasn’t in earlier reviews). Requested changes to match competitor. Another revision cycle. 3 weeks.

Week 15: Final delivery

• Case study: Shows Week 8
• Reality: Week 15

Why the gap exists:

Top UX design agencies measure “project duration” as active design work, not calendar time. The 8 weeks is accurate if you only count hours the agency spent designing. It doesn’t count:

• Client delays
• Approval cycles
• Implementation feedback loops
• Scope adjustments

What this means for you:

When evaluating agencies, the case study timeline tells you how fast they design. It doesn’t tell you how long your project will take. Your project timeline includes:

• Your team’s feedback speed
• Your stakeholder availability
• Your dev team’s technical constraints
• Your organization’s decision-making process

The agency can’t control those. Neither can you, entirely. Factor in roughly 80-100% buffer on case study timelines.

What Case Studies Hide About Who Actually Did the Work

The case study version

Team section in case study: Photos of 3-4 senior designers with impressive credentials. “Led by Jane Chen, Principal Designer with 12 years experience at IDEO and Frog.”

You assume Jane is designing your product.

What actually happens

The pitch team vs the project team:

Who you meet in sales:

• Senior partner (15 years experience, impressive portfolio)
• Lead designer (10 years experience, did the case study work)
• Maybe a strategist (strong background)

Who works on your project:

• Mid-level designer (4 years experience, first project in your industry)
• Junior designer (2 years experience, does production work)
• Senior designer review (2 hours per week)

This isn’t deceptive. Top UX design agencies can’t staff every project with only senior people. It’s economically impossible. Senior designers cost $180-240/hr. Your project is billed at $140-170/hr blended rate. Math doesn’t work unless juniors do most of the work.

The case study shows senior work because:

1. Seniors actually did that project (high-profile client, used for sales)
2. Seniors reviewed junior work heavily (more oversight than typical)
3. It’s the agency’s best work, not typical work

What this means for you:

Questions to ask when evaluating agencies:

• “Who specifically will be assigned to our project?”
• “What’s their experience in our industry?”
• “How much time will the senior designer spend on our project?” (Get hours per week, not “they’ll be involved”)
• “Can we meet the actual team before signing?”

Good agencies are transparent about this. They’ll tell you the team structure, junior/senior split, review process. Bad agencies dodge the question or imply seniors do everything.

The team structure matters more than individual credentials. A junior designer with strong senior oversight often produces better work than a mid-level designer working alone. Ask about review frequency and decision-making authority.

What Case Studies Hide About Revisions and Scope Changes

The case study version

Revision language in case studies: “Collaborative design process” “Iterative refinement” “Close partnership with client team”

Sounds smooth. Sounds like 2-3 polite rounds of feedback.

What actually happened

Real revision breakdown for typical project:

Round 1: Strategic misalignment

• Agency presents initial concepts
• Client: “This doesn’t reflect our brand voice”
• Agency: “Your brief said minimal and modern”
• Client: “Modern yes, but not cold. We need warmth.”
• Result: 3 concepts scrapped, start over with new direction

Round 2: Stakeholder conflict

• Agency presents revised concepts
• Product VP: “Perfect, ship it”
• Marketing VP: “Completely off-brand”
• CEO: “Why doesn’t it look like Stripe?”
• Result: Another revision to reconcile 3 different visions

Round 3: Technical reality

• Agency presents refined designs
• Dev team: “This animation will tank mobile performance”
• Dev team: “This dropdown requires API changes we can’t make”
• Dev team: “This layout breaks on tablet”
• Result: Revision to make designs technically feasible

Round 4: Scope expansion

• Agency presents technically feasible designs
• Client: “Can we add a dashboard view?”
• Client: “Users will need export functionality”
• Client: “What about mobile?”
• Result: Either scope increase (more cost) or feature cuts (disappointment)

This is the classic scope creep pattern. Most MVPs only need one flow designed completely. Everything else can wait. Agencies will design whatever you ask for – knowing what to ask for is your job.

Round 5: Final polish

• Agency thinks they’re done
• Client: “The buttons feel off”
• Client: “Can we see it in dark mode?”
• Client: “Copy needs another pass”
• Result: Another week of small changes

Why case studies hide this:

Revision cycles make everyone look bad:

• Client looks indecisive
• Agency looks like they didn’t nail it first try
• Both look like poor communicators

But this is normal. Design isn’t linear. Every top UX design agency goes through this. The smooth case study narrative is fiction.

These revision cycles aren’t always the agency’s fault. If your organization can’t make design decisions quickly, or if stakeholders aren’t aligned on the problem you’re solving, revisions multiply. Before you hire any agency, make sure you’re ready to work with one.

What this means for you:

When evaluating agencies:

• Ask: “How many revision rounds are included in your estimate?”
• Ask: “What happens if we need more revisions?”
• Ask: “How do you handle scope changes mid-project?”

Good agencies budget 4-6 revision cycles. Bad agencies budget 2 and charge extra for more.

For your project:

• Get stakeholders aligned before agency starts
• Consolidate feedback (one doc, not 5 Slack threads)
• Involve dev team in early reviews
• Know that 4-6 revisions is standard, not a failure

What Case Studies Hide About Implementation

The case study version

Implementation section: “Delivered comprehensive design system with component specifications.”

Shows: Figma files with organized components, detailed specs, style guide.

Implies: Your developers can implement this smoothly.

What actually happens

The implementation reality:

What the case study shows:

• Beautiful Figma components
• Detailed specs (spacing, colors, typography)
• Interactive prototypes

What’s missing:

Technical specifications:

• Does this work with React? Vue? Angular?
• Are these components accessible (WCAG AA)?
• Do animations work on low-end devices?
• How does this handle RTL languages?
• What’s the fallback for unsupported browsers?

Case studies rarely specify. Agencies design for ideal conditions. Your developers implement for reality.

Component gaps:

• Figma shows “Button” component with 3 states
• Developers need: 8 states (hover, active, focus, disabled, loading, error, success, pressed)
• Figma shows clean data
• Developers need: Empty states, error states, loading states, edge cases (199+ notifications, 0 items, text overflow)

Missing context:

• How does this integrate with existing design system?
• Which components are new vs modifications?
• What existing components are deprecated?
• Migration strategy for old components?

Real example:

Agency delivered dashboard redesign to SaaS company. Case study shows beautiful interface. Implementation revealed:

• 23 components needed accessibility fixes
• 7 components didn’t work on mobile (despite being “responsive”)
• Data visualization library wasn’t specified (devs spent 2 weeks evaluating options)
• Loading states weren’t designed (devs improvised, looked inconsistent)

Implementation took 9 weeks instead of projected 4 weeks. Not because designs were bad – because specs were incomplete.

What this means for you:

When evaluating top UX design agencies:

• Ask: “Do your designs include technical specifications?”
• Ask: “How do you handle accessibility?”
• Ask: “What’s included in component specs?” (Show examples)
• Ask: “Do you provide implementation support?”

Better question: Ask to see their actual Figma deliverables (redacted), not case study images. Shows you what level of detail they provide.

How to Actually Evaluate Top UX Design Agencies

Don’t ignore case studies – contextualize them

Case studies aren’t useless. They show:

• Design quality ceiling (their best work)
• Industry experience
• Problem-solving approach
• Visual style range

What they don’t show: typical project experience, operational realities, what working with them feels like.

Use case studies to get to the interview, not make the decision.

Questions that reveal actual performance

Instead of: “Show me your best work”

Ask these:

1. “Walk me through a project that went over timeline. What happened?”

Good agencies: Honest about delays, explain what they learned, describe how they adjusted process. Bad agencies: Claim all projects finish on time (lie) or blame client entirely (red flag).

2. “Who specifically will work on our project, and what’s their experience level?”

Good agencies: Name specific people, show their work, explain team structure and review process. Bad agencies: Vague about team (“we’ll assign the right people”) or imply seniors do everything.

3. “How many revision rounds do you typically go through?”

Good agencies: “Usually 4-6, we budget for that” (realistic) Bad agencies: “Usually 2-3” (probably lying or counting very differently)

4. “What deliverables do developers get beyond Figma files?”

Good agencies: Describe component specs, interaction details, edge case documentation. Bad agencies: “Figma files and design system” (insufficient)

5. “Can we talk to a client from the past 6 months?”

Good agencies: Connect you with recent client, prepare them for honest conversation. Bad agencies: Only offer cherry-picked references from 2 years ago.

6. “What happens if our dev team says designs aren’t technically feasible?”

Good agencies: Describe revision process, technical collaboration, no additional charge for technical adjustments. Bad agencies: Charge for revisions or get defensive about technical constraints.

The pattern:

Good agencies are realistic about problems. Bad agencies present perfection. Reality isn’t perfect. Choose the agency that’s honest about it.

Case studies from top UX design agencies show the outcome. They don’t show the process.

They show 6 weeks. Not 14 weeks with client delays. They show senior work. Not the junior designer doing most of it. They show “iterative process.” Not 6 revision cycles. They show beautiful designs. Not the implementation gap.

This isn’t dishonest. Case studies are marketing. But evaluating agencies solely on case studies is like hiring someone based only on their highlight reel.

Ask about the messy parts. Timelines that extended. Revisions that multiplied. Teams that changed. Implementation problems they solved.

The agency that’s honest about problems is better than the agency that pretends they don’t exist.

We’re strict about this because you’re not buying perfect case studies. You’re buying a working relationship through the messy parts.