Role
Product Designer
Client
Stena Recycling
Timeline
Aug - Sep 2024
Turning a manual improvement process into a trackable digital tool
A 5-day design sprint to design and validate a tool that helps Stena Recycling's customers track and manage improvement projects.
The challenge
Stena Recycling already had a structured method for running improvement projects with customers — reducing waste, cutting transport costs, lowering CO2. But customers had no visibility into it. Proposals arrived by email, progress lived in spreadsheets, and there was no shared place to track what was happening or what had changed.
What I did
I was the only designer in a cross-functional sprint team. I spent 1–2 weeks before the sprint doing desk research, stakeholder interviews, and getting deep into how SRM actually worked. During the sprint week I designed the prototype and led all five user testing sessions with real customers.
The outcome
The prototype was well received — customers responded positively in testing and the business team was enthusiastic about the direction. The project wasn't prioritised for development before my assignment at Stena ended, so I don't know the current status. What we validated was a clear concept with strong user appetite.
The goals
Business goal
Stena Recycling wanted to turn their improvement methodology into a digital product — something that could make the Stena Resource management (SRM) process more visible, more scalable, and more valuable to customers. The long-term goal was a customised offer that helped customers implement real operational improvements and meet their own sustainability targets.
Customer goal
Customers wanted to stop chasing updates. They wanted to see their improvement proposals, track progress, and understand the financial and CO2 impact — all in one place, without relying on back-and-forth emails with their Stena contact.
The problem space
The tricky part wasn't designing a dashboard. It was understanding a process that was entirely relationship-based and had never been made digital before. The process involved multiple actors — Stena's sales team, technical experts, and the customer — each with different needs and different levels of visibility. Before the sprint, I needed to understand how cases actually moved through the system: how a proposal was created, who decided to act on it, how progress was tracked, and what "closed" really meant.
What research revealed was that the process was more complex than it looked. Customers weren't just passive recipients — they wanted to set goals, track impact over time, and share results internally. And Stena's own team had a real risk: if they made their methodology too transparent, they could be giving away knowledge they currently charged for. That tension — how much to show, to whom, and at what stage — shaped almost every design decision in the sprint.
What success would look like
A customer logs in, sees what's proposed and what's ongoing, knows what action is needed next, and can show their own management the results. Stena's team spends less time on admin and more time on actual improvements.
Process highlights
Understanding the process before the sprint
Before the sprint started I spent 1–2 weeks getting up to speed. I reviewed existing SRM materials, talked to stakeholders internally, and mapped out how improvement cases actually worked end to end. The customer journey slide we built together became the foundation for Day 1 of the sprint — it defined the scope and made sure we were all looking at the same problem.
The customer journey map we built on Day 1 — it anchored the sprint and defined what part of the flow we were designing for.
Mapping and sketching
Day 1 was about alignment. We mapped the journey, defined the long-term goal, and identified the risks — including the real concern that making SRM too transparent could undermine Stena's value. Day 2 everyone sketched individually. I sketched several directions, including a "track and predict" view with a timeline and target, and a more action-focused list view. Having the whole team sketch meant we surfaced ideas from the business experts that I wouldn't have found on my own.
Everyone sketched on Day 2 — having the business experts draw their ideas surfaced assumptions I wouldn't have found in a brief.
Key decision - designing for the customer, not for Stena's internal team
Early in the sprint we had to decide whose perspective to design from first. We chose the customer — the person trying to understand what was proposed and what was happening. This kept the design focused on clarity and trust, not on Stena's internal workflow.
Deciding and storyboarding
On Day 3 we voted on the sketches and built a storyboard — three screens that would form the prototype: an overview dashboard, an improvements list, and a case detail page. The storyboard helped us see the gaps. The key question was what to show on the overview: too much data and it becomes noise; too little and customers don't see the value.
The storyboard from Day 3 - what was needed for the prototype
Building the prototype
I built the full prototype in Figma on Day 4. The final design covered four screens: an overview with an improvements bar chart and CO2/cost donut charts, an improvements list with status tabs and progress indicators, and two states of the case detail page — one for evaluating a new proposal and one for managing an active case with actions and deadlines.
Video showcasing the prototype built on Day 4 and then used for user testing
Testing with customers
On the last day I ran five user testing sessions with real Stena customers. I led all the interviews. The reactions were clear and consistent — people got it quickly, and several said it would reduce the back-and-forth they currently dealt with.
User testing session with one of us interviewing and the other taking notes in Miro
Overview page landed immediately — customers understood their improvement portfolio at a glance
Having everything in one place was the most common positive — customers described it as "really smart
Customers could see how it would help them involve more people internally and track their own goals
Needed clearer logic around who sees what — location hierarchy (parent/child sites) wasn't resolved
Time frame for CO2 and cost data wasn't clear — did it cover one year or all time?
The "Inspiration" section needed more definition — what cases would appear there and how?
WHAT CAN BE ADDED NEXT
Export functionality for graphs and data to use in internal presentations
WHAT CAN BE ADDED NEXT
Email reminders when actions are overdue or a new proposal arrives
WHAT CAN BE ADDED NEXT
CO2 sync — connecting improvement data to the customer's own sustainability reporting
Outcome
There was no pilot or launch. After the sprint, the business team was enthusiastic about the direction and the testing validated the concept clearly. The project wasn't prioritised for development before my assignment at Stena ended. I don't know the current status.
What the sprint produced: a tested, high-fidelity prototype and a clear picture of what customers actually needed — which is a real output, even without a build.
Reflections
Working in a tight cross-functional team made the sprint faster and sharper. With just four of us actively driving the work — me, the PO, the facilitator, and the business lead — decisions happened quickly. There was no room for ambiguity about who was deciding what.
The prep week mattered more than I expected. Coming into the sprint with a solid understanding of how SRM actually worked meant Day 1 was productive from the start. Without that, we would have spent the first two days just getting aligned on the problem.
Testing told us where the real complexity was. The overview page and the case detail worked well. What testing surfaced was the harder, less visible questions — location hierarchy, access permissions, CO2 data time frames. Those weren't design problems we could solve in a sprint, but knowing they existed was valuable.
I didn't have metrics to measure impact. The project didn't reach build, so there's no data on adoption or business results. That's an honest gap. What I can say is that five out of five customers responded positively and could articulate concrete ways they'd use it.
What I'd do differently. I'd have pushed harder during the sprint to define the location hierarchy and permissions model — it came up clearly in testing and would have needed design work before any handoff.
