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 main UX Designer of the project, my duty was to facilitate a Design Sprint and later design and prototype different versions of a CRM, whose aim was to make our partners' subscription models handled by them, unblocking one of our Devs Team.
- Role
- Main UX 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 creating a CRM 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 Design Sprint was organised over four days to allow sufficient time for each of the key phases that take a team through a focused problem-solving process. These phases being:
Understand
Define
Sketch
Decide
Prototype
Validate
Duration
4 Days
Team
11 participants
PM · UX Designer · Dev team
Tools
Miro
Figma
01 / 06
Understand
For the Understand phase, we made use of ideation techniques.
Why?
This tool allowed us to understand what we needed to solve and why.
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.
Why?
With this exercise, we defined the metrics that would ensure we were delivering the right solution to our partners.
03 / 06
Sketch
The Sketch phase is all about generating visual ideas and the first tangible solutions. Essentially, I just put everyone to draw.
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. 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.
(Given the complexity of the project, and the many great ideas everyone had, we had to filter further the results obtained at the Do Now section)
Why?
Deciding together kept the whole team bought into the direction, rather than one person picking the winning idea on their own.
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?
Prototyping and testing with real users helps ensure the solution meets actual needs, reduces assumptions, and drives informed UX decisions.
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!
5 teams
2 members each · 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
5 people
2 Tasks
Create plan · Edit plan
Success
They confirmed we were delivering the right thing, but also gave us valuable feedback:
Please don't mind the typos in the post-its, notetakers were in a rush!
Feedback
Originally we included a Help button in the Plan Edition flow. Some users didn't even notice the Help button at the Edit plan screen. Wasn't really needed so we could get rid of it.Feedback
At Plan List page, we divided the sections between Anytime/Midweek Passes. Some struggled to find the section in the scroll. We would need to find a better way of displaying both.Feedback
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.03
The Next Steps
Agreement on the next actions after the Design Sprint is finished:
- Iteration based on Feedback
- Ideate the features that weren't included in v1
- Testing with the real target users
Extra: some pics from the Design Sprint!
*Quick disclaimer: the prototypes made here were approaches. I had to prototype myself later in Figma using the components from our Design System, making "more real" what we agreed on in the previous exercise.
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
We 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
We added visual layers to the sections. This cleared the screen and allowed more plans to be displayed. The addition of a header let us 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
We remade the whole confirmation dialog, using components from our library to better display the changes. We also made the information look cleaner thanks to the new information architecture.
Plan Transition
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:
- We added the Transition option in the Plan cards
- We added a Wizard popup flow, to explain the process, as it might not be necessarily obvious for everyone
- Added a confirmation screen with the changes in the plan
- Included an "On Transition" section at the Plans page
05
Testing Time
For the testing of this iteration we followed this criteria:
11 people
Potential users
3 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.
Sadly I don't have access to the amount of Success/Failure data anymore. But I have nice insights and comments that were gathered during this testing round.
06
The Final Version
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
We would need to think of a way of displaying them and allowing comfortable selection.
07
Acting On Feedback
A lot of the feedback received was positive, but we had some things to fix:
- The first level Tabs were confusing. People didn't understand the concepts
- Users were confused why the Start/End date of the plan didn't correlate with Plan Duration
- Users didn't understand why they couldn't edit the price of a Plan while editing
How we fixed these
Taking into account the latest feedback received and requirements shown above, here are some of the resulting final screens:
And an eagle (pre)view of the complete flow, a rough overview of how the actual final flow, ready for handover, looked like!
08
A Wild Ride
Thank you for reading until here! You deserve a promotion! But let's leave it here with the last bits:
Learnings
- Learned about Design Sprints: their tools and how to moderate them
- Improved my collaboration with Devs, we had to take the lead at some point even!
- How to prioritise what can be done in the given time, even more with the piling requirements
- I learned about Design Systems out of my comfort zone, even the namings can vary a lot!
Skills demonstrated
The Challenge
This project was really intense, given many things:
- I built, moderated and participated in a Design Sprint
- For the solution, I had to use a Design System I was not familiar with
- The requirements we got over the course of the project made us rethink and rebuild the information and structure of the solution many, many times
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
