Public sector · 2026 · In development · Client work
Designing self-service to reduce membership support requests
answer the question before it’s asked
Members were contacting support because everything they needed was spread across two websites. I redesigned joining, renewing and the member dashboard around their most common questions.
- Role
- UX/UI Designer, discovery to delivery
- Client
- A national heritage organisation (anonymised, pre-launch)
- Team
- Me, 1 designer, 1 PM, plus the client’s membership team and in-house designer
- Scope
- Landing page, join and renewal journeys, member dashboard, reusable UI patterns
- Status
- In development, built by the client’s team and a partner agency
The problem
Membership information was split across two websites, so members contacted support instead of helping themselves.
What I did
Split one sprawling redesign into three focused problems, turned 13 membership types into a few questions, and built a dashboard around real support requests.
How it’ll be measured
Support requests by topic, join and renewal completion, and use of member benefits after launch.
Before
13 membership types to compare at once
After
- Is this for you or a gift?
- A few more simple questions
- Your recommended membership
Part 1 of 4
Context
The information members needed existed. It was just in the wrong places.
The problem
two websites, one confused member
The support team handled a high volume of membership requests: which membership to choose, how to renew or change it, how to update account details, and how to find and use member benefits.
The answers were split between the membership platform and the main website. When members couldn’t piece them together, they contacted support.
The goal: reduce support demand by making the core journeys self-explanatory, without stripping out detail members still needed.
Part 2 of 4
Research
I talked to members and staff to find where confusion actually happened, then broke the work into smaller problems.
Finding where confusion happened
5 interviews, 7 questionnaires
Three groups had very different needs: first-time joiners, members renewing or changing their membership, and members looking for their benefits.
- 5 member interviews to hear pain points in their own words
- A questionnaire with 7 staff and stakeholder responses, including the support team, to map the most common requests
- A UX audit of the existing experience
One big redesign, three focused problems
one decision at a time
Fixing everything at once risked fixing nothing well, so I split the work into three challenges:
Landing page
How might we get members logged in and visitors joining, without one crowding out the other?
Join and renewal
How might we help people choose from 13 membership types without overwhelming them?
Member dashboard
How might we answer the most common support questions inside the logged-in experience?
I annotated each wireframe with the research finding it addressed, so stakeholders could see why a decision was made. Sign-off was faster and debates stayed grounded in evidence.
Part 3 of 4
Design decisions
One answer for each of the three problems, designed to work within the platform’s limits.
A landing page for two audiences
There was no landing page before, and members and visitors arrived at the same place with different goals.
- Two equal actions: Log in and Become a member
- A benefits section that motivates both groups
- An FAQ answering the questions that most often reached support
13 membership types, a few questions
13 options, a few simple questions
Showing 13 options at once forced people to compare everything. The join flow now asks a few questions and recommends the right membership, starting with: is this for you or a gift?
Renewals show the current membership, let members switch if their circumstances changed, and come pre-filled but editable.
Working with a back-end constraint
Gift and personal purchases run as separate processes in the back end, so they couldn’t be merged into one form. The opening question routes people to the right journey instead, so the split feels invisible.
A dashboard built around support questions
answer it before they call
One of the most common support questions was how to register for member-only events. The dashboard is now a home base for membership status, benefits and how to use them, renewal, and account settings, ordered by what members look for most.
Designing for two build teams
design for what can ship
The client’s platform can’t support every design decision, and a separate agency is building part of it. I created reusable UI patterns shared across all three journeys, aligned with the client’s in-house designer on what the framework could support, and I’m supporting the partner agency through build. Accessibility was considered throughout, since this is a public-facing organisation.
Part 4 of 4
Outcome
Still in development, so this is what I’ll watch once it launches.
How we’ll measure success
pre-launch, so here’s what I’ll watch
| Goal | Metric |
|---|---|
| Reduce support demand | Volume of membership-related support requests, by topic |
| Easier joining | Join flow completion rate, and drop-off at each question |
| Easier renewal | Online renewal rate compared with renewals handled by support |
| Members use their benefits | Event registrations started from the dashboard |
What I learned
Breaking a complex redesign into three focused problems was the turning point. Each got proper depth, and stakeholders could review one decision at a time.
After launch, I’d compare support requests before and after, and run follow-up sessions with members to see which benefits they actually find.