A Website Redesign UX Case Study Example, Torn Down (Frame)
Heads up: Frame is a fictional festival — an example portfolio built with Folioverse. The metrics below are illustrative sample figures from that fictional project, not real product results.
A website redesign ux case study is where most portfolios get vague, because “I redesigned the site” can mean anything. This teardown walks through Frame — a fictional design festival — to show how a redesign case study stays sharp when every design move maps to a specific funnel problem.
Frame’s old site got strong traffic but converted poorly to ticket sales. The designer redesigned the landing page, the schedule, and ticket registration. It is an example portfolio built with Folioverse: realistic but fictional, with illustrative figures.
Recruiter 30-second scan: Where was the funnel leaking? What did the designer own? Did each design change target a measured problem? And are the results framed honestly?
Case context
- Project type: event website redesign (landing, schedule, registration)
- Role: sole product designer, with a PM, a marketer, and two engineers
- Duration: 4 weeks, fixed festival brand, launch before the marketing campaign
Weak version:
“We redesigned the festival website.”
Strong version:
“I was the sole designer on a 4-week redesign of the landing page, schedule, and registration flow, working within a fixed brand and a hard launch deadline, alongside a PM, a marketer, and two engineers.”
The problem this case proves
A strong redesign problem statement is a funnel problem, not a taste problem.
Weak version:
“The old website looked outdated.”
Strong version:
“The site got traffic but converted poorly to tickets. The schedule was a downloadable PDF, speaker info was thin, and mobile registration dropped off at payment.”
That sentence already tells a reviewer where the money was leaking.
What the designer did — research that targets the funnel
The case shows funnel analysis (visit-to-ticket by device), a survey of last year’s attendees, and a competitor scan of three event sites. The synthesis names three blockers: no scannable schedule, low trust in the lineup, and a clunky mobile checkout.
Each blocker maps to one of the three pages being redesigned. That alignment is what makes the case feel deliberate rather than decorative.
Key decision 1: replace the PDF with an interactive schedule
Evidence: the PDF schedule was unscannable, especially on mobile.
Alternative considered: a cleaner PDF or a static HTML list.
Weak version:
“I redesigned the schedule page.”
Strong version:
“I replaced the downloadable PDF with an interactive, filterable schedule — pick a day and a track, and the relevant sessions surface instantly — because the old PDF was the first funnel blocker.”
Key decision 2: a speaker-forward lineup with credibility cues
Evidence: the survey showed low trust in the program.
Alternative considered: a simple list of names.
Weak version:
“I improved the speaker section.”
Strong version:
“I made the lineup speaker-forward, with roles, companies, and session titles, turning a thin list into a reason to trust the program enough to buy a ticket.”
Key decision 3: a two-step mobile registration
Evidence: mobile checkout dropped at payment.
Alternative considered: keep the existing multi-step flow.
Weak version:
“I streamlined the registration flow.”
Strong version:
“I cut registration to two steps on mobile — ticket selection, then a short payment form — because the funnel data showed drop-off concentrated at mobile payment.”
Outcome and evidence
The case includes results, framed as illustrative.
Weak version:
“Ticket sales improved a lot after launch.”
Strong version:
“In the example project, ticket conversion rose about 24%, mobile checkout completion improved roughly 15%, and on-page schedule engagement nearly replaced PDF downloads. These are illustrative figures for a fictional project, not a real launch.”
The framing lands the lesson: for an event, the website isn’t a brochure — it’s the box office, and the whole job is shrinking the distance between “I’m interested” and “I’m registered.”
What makes this teardown worth studying
- The problem is a funnel leak, stated with device detail.
- Each of three blockers maps cleanly to one redesigned page.
- The point of view (“the website is the box office”) gives the case a spine.
- Results are present but clearly labeled as illustrative.
For the full structure behind a case like this, use the UX case study guide. Browse more UX case study examples, including a fintech transfer teardown. If this is your first portfolio piece, start with how to write a UX case study with no experience.
FAQ
What makes a website redesign UX case study strong instead of just before-and-after screens?
Each design move should map to a specific funnel blocker the redesign was meant to fix, so the work reads as deliberate rather than decorative. A clear point of view, like 'the website is the box office,' gives the whole case a spine.
How do you map a redesign decision to a funnel problem?
Start by stating the problem as a funnel leak with detail, such as where drop-off happens by device, then tie each redesigned page to one named blocker. In this teardown, three blockers each map cleanly to one redesigned page.
How should you state redesign results honestly in a case study?
Present the numbers as concrete improvements but label them clearly for what they are, including when figures are illustrative rather than from a real launch. Honest framing keeps the lesson credible instead of overclaiming.