← Work
[ Case 04 ]

Member Services Design Sprint

Eight member-service journeys to redesign, a hard deadline, and a team with no time to test – so I ran a compressed design sprint that delivered a usable journey a week.

Role
UX Designer
Year
2019
Team
Product Owner (decider), client BA, front-line SMEs, two SaaSFocus BAs, head of consultants
Tools
Design sprints, sketching, storyboarding, wireframes, clickable prototype, Salesforce
A redesigned member-services console screen, built for Salesforce.

In one line

Eight journeys to redesign, a fixed deadline, and a team too stretched to run a full sprint – so I built a faster one that still got results out the door each week.

The brief

I facilitated design sprints to redesign how a member-services team handled its work – eight separate journeys in all, each needing wireframes and, where it helped, a clickable prototype, at a pace of roughly one journey a week. I ran the workshops; the product owner was the decider, with a client business analyst, front-line subject-matter experts, and consultants from SaaSFocus in the room.

The constraints

The hard part wasn’t the design, it was the constraints. The team was time-poor and couldn’t afford a proper, test-everything sprint. The deadline didn’t move. People were only available in narrow windows. And whatever we designed had to land in Salesforce, which has its own limits on what’s possible.

The sprint, compressed

So I bent the sprint to fit – a tight cycle, run each week, that still got a tested journey out the other end.

Understanding

Each cycle opened on the current state. The BAs had assessed the existing system and laid out the steps, the pain points, and the “How Might We” prompts that turned those pains into things to solve. Pinning it all up got everyone in the same headspace before anyone reached for a solution.

Current-state screens and How Might We notes pinned up at the workshop.
Current-state screens and "How Might We" notes – getting the real journey and its pains to the front of everyone's mind.
Workshop wall framing the problems before sketching solutions.
Framing the problems together before anyone sketched a fix.

Map

Then we mapped the journey to six steps – a quick, effective way to get the member to their goal while cutting the steps the old system had bolted on. From there we drew the detailed user flow, capturing the decision points along the way.

A six-step member journey mapped in sticky notes on a window.
The six-step journey on the wall – the quickest path to the member's goal.
A detailed user-flow diagram built from the journey map.
The detailed user flow – where the member makes each decision.

Sketch

Participants came in with sketches based on the current-state pack I’d sent ahead. They each explained their work; I recapped every design and called out the key features, then ran the vote. Once the decider confirmed his pick, I recapped what won and why – important when there was no time to revisit it later.

Design-studio sketches pinned up for the group to explain and vote on.
Design studio – everyone draws, everyone votes.

Storyboard

Storyboarding pulled the decisions together and added the detail a wireframe needs – fields, display text, and the order things appear in.

A storyboard detailing the screens and fields ahead of wireframing.
The storyboard – enough detail to take straight into wireframes.

Wireframes

The wireframes were mine to build – the part I’m quickest at. I designed for the screen sizes used in the call centre and branches, kept readability and accessibility high, and cleaned up the old system’s ambiguous acronyms. The BAs started their process maps and user stories in parallel.

A mid-fidelity wireframe screen from the redesigned journey.
A screen from the redesigned journey, built at call-centre and branch sizes.
A mid-fidelity wireframe screen with clearer language.
Clearer language in place of the old system's ambiguous acronyms.
A mid-fidelity wireframe screen from the journey sequence.
Mid-fidelity screens, validated with the team as the BAs wrote up the process.

Prototype

The prototype mattered more than I expected. People will nod along to a wireframe, but actually clicking through the journey surfaced feedback we folded straight back in – and it doubled as the thing we showed stakeholders to sign the journey off.

What I took from it

A sprint is a set of rules, not a ritual – you bend it to the constraints in front of you and still get a tested journey out the other end. And a rough prototype earns more honest feedback than a polished wireframe ever will, because people stop critiquing and start using it.