Introduction
The strongest UX website redesign case studies rarely start with a screenshot. They start with a problem: a support ticket queue that won't shrink, a navigation menu nobody can parse, a conversion rate that's flatlined for two quarters.
The before-and-after visuals come later, if at all.
Many teams run into a different reality. Redesign projects become subjective when there's no baseline to measure against. They get expensive when nobody defined success upfront. And they're nearly impossible to evaluate when "we changed the design" is the only documented decision.
This shows up constantly on B2B and SaaS sites, where multiple user roles, technical workflows, and legacy information architecture make missteps costly.
This article breaks down what separates a credible UX website redesign case study from a portfolio highlight reel. It covers the research, design, accessibility, validation, implementation, and measurement patterns that show up across real projects, including work with organizations like Harvard Kennedy School and Starburst Data.
Key Takeaways
- Effective redesigns start with a documented user and business problem, not a visual refresh.
- Research methods like interviews, analytics review, card sorting, and usability testing should drive design decisions, not follow them.
- Credible case studies tie every design change to evidence and report results against a defined baseline.
- B2B and SaaS websites need extra attention to information architecture, multiple user roles, and long-term maintainability.
What UX Website Redesign Case Studies Should Include
A UX website redesign case study is a documented account of the problem, research, decisions, prototypes, validation, implementation, and results behind a redesign. It's not a gallery of polished screens.
Context Comes First
Before any finding matters, a case study needs to establish:
- The organization and website type (marketing site, product dashboard, self-service portal)
- Target users and their roles
- Business model and project constraints, including budget and timeline
- Team roles and who owned which decisions
- The actual scope of the redesign
Without this context, a reader can't judge whether a finding from one project applies to their own.
Show the Problem With Evidence
Strong case studies document the starting problem with real evidence, not assumptions:
- Analytics showing drop-off points or low engagement
- Support ticket volume tied to specific pages or tasks
- Stakeholder interviews revealing conflicting priorities
- Usability observations from watching real users struggle
- Accessibility audit findings
- Direct user feedback or complaints
Harvard Kennedy School's intranet redesign is a useful reference point. The problem wasn't vague dissatisfaction—it was specific: the department-based structure forced users to know which office owned a resource before they could find it, wasting time on routine tasks like cross-registration.
Evidence alone isn't enough, though. Strong case studies also show how teams moved from those findings to design decisions.
Separate Findings From Decisions
This is where most case studies fall apart. A finding ("users don't understand our department labels") is not the same as a decision ("we're switching to a needs-based navigation"). A credible case study shows the chain:
- Finding: Research reveals a specific problem or pattern.
- Hypothesis: A proposed reason and potential fix.
- Change: The actual design decision made.
- Validation: How the team confirmed the change worked.
Nielsen Norman Group's documented case study on a B2B manufacturer's IA redesign followed this exact structure. The team ran a baseline tree test, revised the IA through card sorting, then retested with fresh participants against the same tasks. That's project-specific evidence—not a universal benchmark to copy.
Report Limitations, Not Just Wins
A complete case study admits what it doesn't know. Common limitations to name include:
- A redesign that overlapped with a marketing push or other launch activity
- A small or skewed research sample
- Confounding factors that could also explain a metric's improvement
Naming these conditions builds more credibility than a suspiciously clean success story.
Recurring Lessons From UX Website Redesign Case Studies
Across dozens of documented redesigns, the same patterns keep showing up.
Define Goals and Ground Them in Research
Redesign goals need definition before wireframes exist. Common goals include:
- Clarifying a primary call to action
- Reducing friction in a specific task
- Improving navigation for a non-technical audience
- Meeting accessibility requirements
- Supporting qualified lead generation instead of raw traffic
Skip this step and teams end up redesigning based on opinion, not evidence.
Competitive analysis can reveal conventions and gaps worth exploring. But competitors aren't your users. Their choices might reflect different audiences or plain mistakes. Use competitive analysis to generate hypotheses, then test those hypotheses against your own users' behavior.
No single research method tells the whole story:
- Interviews surface motivations and mental models
- Analytics and heatmaps show actual behavior at scale
- Card sorting reveals how people naturally group content
- Tree testing checks whether a navigation structure actually works
- Support data flags recurring pain points
Stated preferences and actual behavior often diverge. Someone might say they love a mega-menu in an interview, then fail to use it during a task. Combining methods catches that gap.
Information architecture work in particular resolves problems that plague B2B sites: confusing labels, duplicated content, and navigation built around internal org charts instead of user tasks. Harvard Kennedy School's card sorting and tree testing exposed exactly that. Users had little understanding of the school's departmental structure, which drove the shift to a needs-based IA.
Prototype Early and Test With Real Tasks
Wireframes and interactive prototypes test structure and flow while changes are still cheap. Once a developer builds something, revisions cost more in time and morale.
Usability testing needs realistic tasks and representative participants, not friendly colleagues clicking around. Prioritize findings by severity, frequency, business impact, and accessibility implications—not whatever felt most annoying in the room.
Build Accessibility In and Follow Through After Handoff
Accessibility belongs in every phase, not a pre-launch audit. That means:
- Keyboard access and visible focus states
- Sufficient color contrast
- Alt text and semantic structure
- Clear form feedback
- Testing with people who use assistive technologies
At Yes Yes Know, founder Jen Bullard holds a CPACC certification through the International Association of Accessibility Professionals. That reflects working knowledge of accessibility standards and universal design principles, not a compliance guarantee for any specific client.
Redesigns that succeed long-term continue through developer handoff, responsive implementation, QA, launch monitoring, and post-launch iteration. Treating an approved mockup as the finish line is how good research gets lost in production.
How to Apply Case-Study Lessons to Your Own Website Redesign
Reading case studies is useful. Applying their structure to your own project is what actually improves outcomes.
Start With a Redesign Brief
Document these before any design work begins:
- Target users and priority tasks
- Business objectives
- Constraints, including budget, timeline, and technical dependencies
- Stakeholders and decision-makers
- What stays the same, such as brand, CMS, or integrations
Establish a Baseline
You can't measure improvement without a starting point. Collect:
- Conversion or lead data
- Current navigation and search behavior
- Task completion observations
- Support ticket themes
- Accessibility findings
- Site performance indicators
Segment Your Audience by Workflow
B2B and SaaS sites often serve multiple roles on the same platform: buyers, administrators, technical evaluators, day-to-day operators. Each group needs different things from the same pages. Treating them as one audience is how redesigns miss the mark for half their users.
Match Research Methods to Your Actual Questions
Pick methods based on the uncertainty you're investigating:
- Interviews for motivations
- Analytics for behavioral patterns
- Card sorting for content grouping
- Tree testing for navigation structure
- Usability testing for task friction
Turn Findings Into Testable Hypotheses
Every finding should lead to a specific hypothesis and a defined way to confirm or reject it. "Users are confused by our navigation" isn't enough. "Renaming this category will improve task success, confirmed via a repeat tree test," gives you something to actually validate.
Build in the Right Order
Work in this sequence:
- Information architecture and content hierarchy
- Wireframes
- Responsive UI and prototypes
- Accessibility review
- Implementation specs
Skipping ahead to polished UI before the structure is validated tends to waste design hours on layouts that get scrapped.
Yes Yes Know follows this same order for B2B software teams with data-heavy SaaS, cybersecurity, fintech, and enterprise platforms. The Harvard Kennedy School and Starburst Data engagements used the same sequence: research first, structure second, interface third.
Plan Validation and Launch From the Start
Build these into the project timeline, not as an afterthought:
- Usability testing with representative users
- Browser and device checks
- Redirect and URL review
- Analytics tagging before launch, not after
- A feedback loop for the weeks following launch
How to Evaluate the Outcomes in a UX Redesign Case Study
Not every metric belongs in every case study. The right ones depend on the goal.
Match Metrics to the Original Goal
| Outcome Type | Example Metrics |
|---|---|
| Usability | Task completion rate, time on task |
| Accessibility | Audit findings, assistive tech testing results |
| Engagement | Pages per session, scroll depth |
| Conversion/Leads | Conversion rate, lead quality |
| Technical | Page load time, error rate |
| Qualitative | User quotes, stakeholder feedback |
A redesign meant to improve navigation shouldn't be graded primarily on bounce rate. A redesign meant to boost lead quality shouldn't lean on page views alone.
Demand a Real Before-and-After
A credible comparison needs:
- A defined measurement period
- Consistent methodology on both sides
- A comparable audience
- Disclosure of what else changed, such as marketing campaigns or seasonality
Starburst Data's onboarding work is a good example of doing this cleanly. Setup time was measured before usability testing and product strategy work, then measured again afterward using the same task. It dropped from roughly three hours to just a few minutes.
Question the Claims That Sound Too Clean
Be skeptical of case studies that lean on:
- Isolated screenshots with no data behind them
- Small or unrepresentative sample sizes
- Vanity metrics with no context attached
- Results with no stated baseline or timeframe
Nielsen Norman Group defines vanity metrics as measures that look impressive but lack the context, such as a rate, ratio, or timeframe, needed to connect them to an actual decision. A metric without that context tells you very little.
Pair Numbers With Why
Quantitative results explain what changed. Qualitative evidence such as user quotes, observed task improvements, and recurring usability themes explains why. Both belong in a credible case study.
Conclusion
The most valuable UX website redesign case studies document disciplined decision-making. Strong ones typically:
- Define the problem clearly
- Research real users
- Structure content around actual tasks
- Prototype before development gets expensive
- Test with representative people
- Measure outcomes against a real baseline
A redesign should remove friction and support both user and business goals. Looking newer isn't the point. Working better is.
Use this framework to plan your own redesign with evidence at each step, not opinion. Treat accessibility, maintainability, and post-launch learning as core parts of the work, not extras to address if time allows.
Frequently Asked Questions
How much should a website redesign cost?
Cost depends on scope: research depth, number of templates and workflows, content needs, accessibility requirements, technical complexity, and whether development is included. Define your project brief first, then request estimates you can actually compare.
What is UX in website design?
UX covers how users understand, navigate, and complete goals on a website. Nielsen Norman Group's foundational definition frames it as encompassing every aspect of a user's interaction with a company's product or service, including research, structure, accessibility, and ongoing testing.
What makes a good UX website redesign case study?
A good case study identifies the problem, user and business context, research evidence, design rationale, testing process, implementation details, measurable outcomes, and honest limitations. If it skips the "why" behind a decision, it's a highlight reel, not a case study.
How do you measure the success of a UX website redesign?
Compare pre- and post-launch measures tied to your specific goal, using the same methodology on both sides. Common metrics include task completion, conversion quality, navigation success, accessibility findings, support ticket volume, and user satisfaction.
How long does a UX website redesign take?
Timelines vary with site size, research requirements, stakeholder availability, and content or development complexity. Estimate each phase separately rather than promising one universal number. A five-page marketing site and a multi-role SaaS platform aren't the same project.
