Case study / 01
Subscriptions UI
A development team was spending almost all its time on subscription requests. I designed the tool that made those requests unnecessary.
Summary
Ocado Smart Platform (OSP) is an end-to-end eCommerce, fulfillment and logistics platform. I worked in the e-commerce area designing experiences for Ocado and grocery retailers. As the Product Designer of the project, my duty was to facilitate a Design Sprint and later design and prototype different versions of a self-service subscription management tool, whose aim was to make our partners' subscription models handled by them, unblocking one of our dev teams.
- Role
- Product Designer
- Timeline
- 4 months
- Company
- Ocado Technology
- Platform
- Desktop
01
The Problem
At Ocado Technology, we worked with a wide range of markets and features. Some of our clients integrated subscription models into their e-commerce platforms, usually related to order shipping. Due to the high volume of requests from these clients, both to adjust existing models and to launch new campaigns, one of our developer teams became overwhelmed, dedicating almost all of their time to handling these demands.
So we handed our clients the keys, and got a whole dev team back
This led to the idea of a self-service tool, the CRM as we called it, that would allow clients to manage these tasks on their own, in a simple and immediate way, without relying on our development team.
02
The Design Sprint
The CRM was the idea, not the plan. I proposed running a Design Sprint to get from one to the other. The people who had to agree sat in three different places, product, design and the dev team, and there was nothing built yet for any of them to react to. Four days in one room put them in the same conversation and ended on something we could put in front of real users.
I designed it end to end: I chose the exercises, built the boards, moderated the four days, and took part in the sessions myself.
Moderating and taking part at once is its own problem, because the facilitator's idea arrives carrying the authority of the person running the room. Most of it I handled through the exercises themselves, picking formats where ideas surface anonymously or all at once rather than one voice at a time. The rest I handled by staying out: I sketched alongside everyone else, but I kept out of the votes and the final call.
The Design Sprint ran over four days, enough time for each of the key phases to do its work and take the team through a focused problem-solving process.
Duration
Days
Team
PM · Product Designer · Dev team
Tools
- Miro
- Figma
Those days broke down into six phases. Here they are, and the rest of this section walks through each one in turn.
Understand
Define
Sketch
Decide
Prototype
Validate
01 / 06
Understand
For the Understand phase, we made use of ideation techniques.
For Understand I chose abstraction laddering, to settle what we were actually solving before anyone drew a screen.
Why?
Laddering forces you up to why and down to how from the statement you walked in with. A team that already has a solution in mind has to re-earn the problem first, which is exactly what I wanted before we spent four days building.
02 / 06
Define
For the Define phase, the goal was to establish focus, define outcomes and choose our metrics, for this we used a set of exercises with the whole team.
For Define I chose the HEART framework, to turn "make it easier" into something we could measure.
Why?
HEART makes you chain a goal to a signal to a metric in every category. You cannot stop at a better experience: it holds you there until you name what would prove it.
03 / 06
Sketch
The Sketch phase is all about generating visual ideas and the first tangible solutions. Essentially, we all got drawing.
For Sketch I chose Round Robin, to get a first set of drawn solutions out of the whole room in one sitting.
Why?
I personally like this tool because in such workshops, there are always people that are more shy. This tool encourages them to show and share their ideas without speaking. It also solved a problem of my own: passing folded sheets meant my sketch landed in the pile like everyone else's, without the room reading it as the moderator's. Thanks to it, we got the first visuals of the tool that everyone considered was the best to build.
04 / 06
Decide
The Decide phase objective is… well, to decide. We set the direction and find consensus.
For Decide I chose a decision matrix, scoring every idea by technical difficulty against user value.
Why?
Plotting those two axes put the tradeoff on the wall, so consensus was about where an idea sat on the grid rather than about who argued for it best. Deciding together kept the team bought into the direction instead of one person picking the winner.
05 / 06
Prototype
In this phase, we built together the prototype for the user flow and, with the help of a UX Researcher, we decided on what we needed to learn from the testings we would be performing on the last day.
We collectively decided to do it digital, that's why I prepared beforehand this really low fidelity "component library".
Once the flows were built and agreed, we decided on the Testing tasks and questions that we may still need answers for, as shown in this board here:
Why?
Low fidelity was the point. There was one day left, and what needed testing was whether the flow made sense, not whether the pixels were right. Higher fidelity would have bought nothing and cost the whole day.
06 / 06
Validate
With the prototype of our version 1, everything was set for some internal testing we would be dedicating the last day to!
Teams
Per team
- Moderator
- Notetaker
I divided the team into 5 teams of 2 people each, having a Moderator and a Notetaker. They would need to test the prototypes with users following a set script.
The results were encouraging
Participants
In moderated sessions
Tasks
- Create plan
- Edit plan
Outcome
They confirmed we were delivering the right thing, but also gave us valuable feedback:
01 / 03
Originally we included a Help button in the Plan Edition flow.
Some users didn't even notice the Help button at Edit plan screen.
Wasn't really needed so we could get rid of it.
Feedback
User didn't notice help button
02 / 03
At Plan List page, we divided the sections between Anytime/Midweek Passes.
Some struggle to find the section in the scroll.
We would need to find a better way of displaying both.
Feedback
He thinks that types of passes should be indicated clearer, maybe at the top
03 / 03
We added a confirmation dialog with the highlighted changes when editing before the user submits.
This wasn't noticed at all. We needed to find a better way of displaying these changes.
Feedback
Would like to see highlighted the one that has been changed
03
The Next Steps
Agreement on the next actions after the Design Sprint is finished:
Iterate
- Based on the feedback
Ideate
- Features left out of v1
Test
- With the real target users
04
First Iteration
With a solid base to work from, I started to iterate the tool with the help of the people who participated in the sprint, in successive catch-ups and stand-ups. Let's go through the changes and why's of the two main screens:
Problem
Anytime/Midweek are the type of Subscription models. We needed more differentiation and dedicated space given the amount of plans and info that would go in there.
Solution
I separated both types of plans (called Benefits) into Tabs, so each screen could comfortably display the information. This also ensured both types of plans were at the same level.
Problem
The information was too condensed. There was barely any visual separation between the states of the plans.
Solution
I added visual layers to the sections. This cleared the screen and allowed more plans to be displayed. The addition of a header let me include search, filters, and the Create Plan button visible at all times.
Problem
When editing a plan, the changes were not highlighted enough to be noticed. And the consequences of these changes were too heavy to be overlooked.
Solution
I remade the whole confirmation dialog, using components from our library to better display the changes. I also made the information look cleaner thanks to the new information architecture.
Plan Transition explained
Among the user flows that users could perform in our solution, there were mainly the Plan Creation and Plan Editing user flows.
But there was one that we could not contemplate in our Design Sprint, which was Plan Transition.
But what is a Plan Transition all about?
Imagine you created a subscription that lasts 8 months with a price of 5.99 pounds, and you have some users subscribed to it and enjoying its benefits. Then you realise this plan is not ideal and want to delete it or change some information like the price.
If you either delete or edit the plan, what will happen is that those users will be lost once their original plan expires and the edited one takes its place. Losing clients: not good.
So this was the result:
- I added the Transition option in the Plan cards
- I built a Wizard popup flow, to explain the process, as it might not be necessarily obvious for everyone
- I added a confirmation screen with the changes in the plan
- I included an "On Transition" section at the Plans page
05
Testing Time
For the testing of this iteration we followed this criteria:
People
Potential users
Tasks
- Create plan
- Edit plan
- Plan transition
There were still some things we needed to know from the Creation and Edition flows.
Creation flow
- Do they understand what's happening on Preview?
- Are the fields clear in the Confirmation dialog?
- Do they get where the new Plan went?
- Do they understand the different sections in the page?
Edition flow
- Do they understand what they need to do in edition to set it as future release?
- Do they notice the changes in the Confirmation dialog?
- Do they understand what Autorenewal implies?
- Are they confused with the Edit possibilities in the main screen?
Results were really good overall.
The success and failure counts stayed with the company when I left. What follows is what the round found, in the participants' own words.
Actions Based on Feedback
A lot of the feedback received was positive, but I had some things to fix:
Tabs
- The concepts weren't understood
Dates
- Start/End didn't match Plan Duration
Price
- Not editable while editing a plan
06
Late Requirements
As the development team worked on the implementation of the solution, a number of previously overlooked requirements emerged, as well as new ones from the retailers.
Context
Stores with the Subscription plans can be in different regions. And different regions can have different languages (like the case of Spain, for example).
Requirement
Clients need to be able to edit the language for all these plans separately, without influencing the information in other languages within the same Region and Subscription plan.
Context
Users that subscribe to a Plan can have a set ending date for their subscription, if they paid for a 1 month subscription for example.
Requirement
Customers need a way to schedule a message reminding users that their subscription is about to expire, at plan Creation/Edition.
Context
The amount of Subscription tiers and plans could be really huge.
Requirement
I would need to think of a way of displaying them and allowing comfortable selection.
07
The Final Version
How I fixed both lists
Taking into account the latest feedback and the requirements shown above, here is how I solved each one: the finding on one tab, the screen that fixes it on the other.
01 · Tabs
Six of the eleven participants were unsure what the two top tabs meant. Some asked for a line describing what a benefit group is; others suggested opening on the tab they actually used most.
02 · Dates
Seven of the eleven read the start and end dates as the plan's length, and expected the end date to land exactly one duration after the start.
03 · Price
Six of the eleven did not understand why the price was locked while editing. Three of them expected to be told what they could edit, what they could not, and why.
04 · Languages
Regions inside a single plan can run in different languages, and editing the copy for one could not be allowed to overwrite the others.
05 · Expiry notice
Plans that end on a fixed date needed a way to warn subscribers before their subscription ran out, set at plan creation rather than chased afterwards.
06 · Scale
The number of tiers and plans could grow far past what a single stacked page can hold and still be browsable.
And an eagle (pre)view of the complete flow, ready for handover
08
A Wild Ride
Four months, one Design Sprint and eleven regions. Here is what it came to.
Learnings
- Structuring and moderating a Design Sprint, and knowing which exercise each phase actually calls for.
- Working closely enough with developers to carry the direction of a project together when it needed carrying.
- Prioritising scope against a fixed timeline, especially with requirements still arriving mid-project.
- Designing inside an unfamiliar Design System, where even the component naming works on its own logic.
Skills demonstrated
The Challenge
Several things made this one harder than it looked:
- Designing in a Design System I did not know, on a timeline that left no room to learn it first.
- Requirements that kept arriving after decisions were already made, so the information architecture was rebuilt more than once.
- A tool whose users were our own partners, which meant every change had a commercial relationship behind it.
Halfway through the project, we lost our Product Manager, so the Dev team and myself had to take the initiative, organise ourselves, and do everything within our reach to deliver the best product we could.
Impact
Shipped · Ocado, later SwedenChanging a subscription plan used to take the development team and a release. Now the retailer does it themselves.
Unblocking an entire Development team whose capacity, until then, had been overflowed satisfying their requests.
Until the next project
Keep reading
