PROJECT TYPE
New Product Development
Mobile App Design (Android & iOS)
B2C
SKILLS USED
Design Sprints
Product Strategy
Wireframing
UX Writing
Prototyping
Usability Testing
UI Design
Visual Design
TOOLS USED
Figma
PROJECT DURATION
1 Year 3 Months • January 2020 - March 2021
Flex is the no contract, SIM only product from EE.
Discovery
EE introduced Flex to target a younger customer cohort who are not interested in long contracts and financing a phone purchase. This demographic is buying their phone outright and getting a sim plan to complement. Customers like this care mainly about data usage, are digitally native and expect instant fulfilment.
I worked with the analytics team to triage existing user feedback. There were several problems; the most overwhelming was the length of the journey and the hard it was to complete. To start, I ran through the existing Flex journey and found several touch points causing significant friction and likely causing the poor conversion rate.
The time to complete the journey was 16 minutes and required 46 clicks; this is an unacceptably long journey for a customer segment that is used to on-demand delivery.
User Research
USER INTERVIEWS
EE had kicked off the project relaunch to attract a newer, younger generation of mobile users who are digitally native.
We conducted user interviews to understand better this younger generation's behaviours, their relationship with subscriptions, their current mobile plans/relationship with their provider and what they value.
Participants placed the most value on controlling various aspects of their plan/contract. In particular, they tended to like the ability to cancel, pause or leave on demand. The current 'norm' of being locked into an agreement for 12 months (when circumstances can quickly change during that period) was deemed unacceptable.
Participants all had digital subscriptions/services such as Spotify, Netflix, and Prime, which they pay for monthly, can be cancelled or paused on an ad hoc basis, and see as the new standard.
We asked the participants what their understanding of Flexibility was:
Ability to start and stop the contract at will.
Ability to change their contract at regular intervals.
Usage patterns to suggest the right plan or the ability to "pay only for what you use."
Data Usage Insights
Spare data was strongly associated with ‘peace of mind’ and not having to worry about hitting a data limit. Users tended to go for large data plans and often for far more than they used. Some mentioned having over 25GB left at the end of the month.
Participants tended not to check their data usage actively. They associated checking data with anxiety and something they did not want to happen. The primary touchpoint for learning about reaching their data cap was alerts and messages when they had reached 80% or the limit.
It was prevalent for users to need to buy a data boost (or more than one) in a month. Some mentioned running out of data in week 1 of a month.
The results helped us to validate the proposition of Flex and uncover some new insights that we could feedback into the product.
User Testing
After the interviews, we took the users through the current Flex customer journeys in the lab to understand the existing experience's usability and their feeling about the execution of the product against what they expected.
Key problem areas from this testing were;
The order of the steps and length of the journey was frustrating to all participants
Confusion and anxiety around porting their number
Several people commented they'd prefer to register on the app rather than on a website.
Design Sprint
Having understood Flex as a current product in the market, we then kicked off the redesign project with a design sprint to develop a new approach.
We invited our experts to give us a more in-depth overview of the product and market, sketched out the customer journey map and tried to pinpoint issues and friction that could be removed or reimagined as opportunities for improvement with ‘how might we’ notes. We then sketched several different ideas before reaching a consensus on an approach.
Design Sprint Prototype
After voting on our ideas, we agreed on Flex being a mobile app-only experience that offered a 30-day free trial. We made this decision based on the insights we gleaned from our user interviews, particularly regarding data usage.
Data in gigabytes is an abstract concept; we clarified this with previous research at EE showing how users struggle to understand what gigabytes usage means in real terms (e.g. how many hours streaming music).
The problem with framing usage in this way is that it still requires a cognitive load of understanding your data usage (e.g. how many hours of music do I stream a month? I have no idea!)
Our solution was to allow users to use their phones naturally for a month during the free trial; we would then evaluate their usage and offer them a plan tailored to their usage. This offer gave users a reason to download the app and for us to be a mobile app-only product.
Please note: The following prototype was created in less than 8 hours and is very rough and ready!
Design Sprint Testing
For the final day of the design sprint, we took the prototype into the usability lab to get feedback. Feedback was overwhelmingly positive, both on the product's usability and the concept. There were several key insights that we would use when developing the idea further.
Most participants understood and liked the free trial. They often referred to "not knowing what data they needed" and other brands that offered similar free trials like "Netflix and Amazon Prime."
All participants wanted to keep their current number. These participants were concerned about having no connectivity while waiting for their new sim but understood there could be a delay.
Overall, this proved that the idea and execution were moving in the right direction.
We presented our findings to the business, who told us we couldn't offer the 30-day free trial; however, the mobile app-only network product was well-received, and EE green-lit the project.
MVP Planning
With the project green-lit, we set up an offsite to start planning our approach. I ran a user journey mapping session with the team to help decide what features we needed to include in our MVP.
Due to the complexities around integrating with the external network and back-end systems, we believed that in three months, we would be able to design and build out the MVP for an alpha release, then release a public Beta after six months.
We broke out the scope of the original MVP into three epics:
ORDER JOURNEY
Users can download the app, create an account, choose a plan, order a SIM card and set up payment.
ACTIVATION
Users can activate their SIM card and plan once it arrives.
MANAGE
Users will be able to check their data usage, change plans, payment and change account details.
Order Journey
Now that I understood what we would need to offer in our first release, I could create the first wireframes for the app.
Given how well the design sprint prototype had tested, I wanted to try and keep the simplicity to which the participants had all reacted positively.
By testing this prototype, I wanted to understand whether users could complete the order journey without assistance. In particular, I wanted to see if they understood that we would check their data usage to recommend a plan and if they could use the new feature to transfer their number without requesting a PAC code themselves.
Prototype tasks:
Browse the landing page and explain the proposition
Download the app
Choose a plan
Register a new account
Order a SIM
Keep current number
Activate a SIM
Order Journey Testing Results
CAN THEY UNDERSTAND THE PROPOSITION AND CONTINUE?
Most participants understood they needed to download the app to select a flex plan and proceed. Some participants struggled to find how to download the app; these participants interacted with the product card and download emoji.
CAN THEY UNDERSTAND THE ONBOARDING EXPERIENCE?
Most participants scrolled through the onboarding screens pausing to read about how their plan would be personalised. All participants understood that they'd be able to keep their existing number.
CAN THEY SELECT AND UNDERSTAND THE RECOMMENDED PLAN
All participants understood the benefit of selecting a plan based on their previous data history. Some participants struggled to understand why the recommended plan was less than their usage, not realising the unlimited social media.
"I like it; it's honest. It's not trying to upsell me."
CAN CUSTOMERS SEAMLESSLY REGISTER?
All participants could seamlessly register their details.
CAN CUSTOMERS KEEP THEIR NUMBER?
All participants opted to keep their number. Those with prior knowledge were aware of the timeframes associated with the switch. All participants understood the PAC code text process being abstracted and remarked positively.
With the insights gleaned from this round of testing positive, I was happy I would be able to address the issues during the visual design phase, so I moved on to creating the wireframes for the manage section of the app.
Manage
An essential user need for the manage section was monitoring and understanding data usage over time. We heard this throughout our testing, which was a key reason for users choosing a flexible contract option like Flex.
Another recurring insight from our interviews was that users didn't trust mobile networks. Conditioned by years of bad experiences, customers always expected to be upsold, regardless of their situation or actual needs.
Because of this, I wanted to make transparency a vital pillar of the Flex app's experience. We had achieved this in the order journey by recommending a plan based on actual data usage, and we wanted to extend this functionality to the management experience. We did this by clarifying why we were suggesting a plan by showing the calculation of their average usage over the last three months and allowing users to cycle through and see their previous data usage in previous months. We would also crucially recommend a less expensive plan if that suited their needs better.
The original Flex product had advertised features that tested well, such as being able to change your plan at will. However, the existing execution of these promises was very far from meeting users' expectations, so I made it as simple as possible for users to pause, cancel and edit their plans.
EE told us early on that Flex plans would come with unlimited social media usage, allowing users to use popular social media apps for free. In the usage section of the app, I wanted to clarify how much of a user's data usage was on social media to demonstrate the value of this perk and continue the theme of transparency.
Manage Prototype
For the next prototype, I wanted to understand if Flex customers understand their usage and manage their Flex plans. To do this, I broke out the prototype into several stages according to time using Flex: on activation day, after one month of usage and after three months of usage, simulating how usage would happen over time and the different states.
The critical fork in the prototype was whether users allowed notifications. If they did, we'd notify them when we'd found a better plan; if not, they'd have to be in the app to see.
Mapping out the prototype in Figma
Prototype tasks:
Activate your SIM card and account
Choose to accept notifications - explain the choice
Understand data usage after zero, one and three months (time simulated as moving forward by closing and reopening the app)
Manage Prototype Results
UNDERSTANDING USAGE On the day of activation
All participants could understand their data usage, although some users "expected to see how much data they had used" instead of how much data they had remaining
All participants understood social media usage was free
A few participants questioned the relationship between the data wheel and two usage bars
UNDERSTANDING USAGE after three weeks
All participants could effectively understand their data usage after three weeks
After some exploring of the interface, all users understood the relationship between the data wheel and two usage bars
UNDERSTANDING USAGE after three months
All participants could effectively understand their data usage after three months
All participants understood how to view previous months' usage
All participants understood the average monthly breakdown charts
SWITCHING PLAN
All participants understood their recommended plan, recalling it was based on their "usage" so far
All participants could effectively switch to a recommended plan and were able to purchase acknowledging the plan start date
There was a 3 to 2 split between customers who opted to get notifications about a recommended plan
Notified: Easily understood the benefit and wanted the "ease of mind" that they were being "looked after" as long as it was "honest" and "transparent"
Organic: Easily understood the benefit but were conscious about the frequency of notifications
Visual design
The branding question hung over the project from inception. There was a strategic debate about whether we would be a distinct sub-brand of EE or more closely aligned. At the start of the project, we worked under the impression that we would be a different brand, but later, we were given brand guidelines that led us to be much closer to EE.
Our remit was the same EE fonts and colours but used more yellow than aqua.
I worked on some concepts before we reached a consensus on a dark mode version of the app that allowed for yellow to be the primary highlight colour and did not lead to any accessibility issues that would come with using yellow on a light background.
A showcase of the app’s visual design
Below you can click through a prototype showing most of the journeys created for the manage section.
Prototype feature order:
Integrating with EE
With the decision that we would be much more closely aligned with EE than we had previously thought, a big integration piece was working with the login team to understand the relationship between Flex and EE.
We originally had only scoped for new users, but as we were now more tightly incorporated with EE we had to factor in how we would allow existing EE users to migrate over to Flex.
I mapped out all the eventualities in Figma and worked with various stakeholders to ensure we were catering to all our customer types.
I had to make some compromises for the design to work with existing EE services and for us to hit our launch target. One of these was the native sign-up and password-less registration flow I had initially designed, where a user wouldn't have to create a password and instead would log in via the link in their verification email.
Although this was on the EE roadmap, this would technically not be feasible for launch, so I needed to devise an alternative solution. We couldn't offer registration as a native in-app experience and would have to redirect users to an in-app browser where the user would need to either login or register with EE.
Because of this, I added a new onboarding screen to allow users to be prepared to log in to EE if they had an EE account; if not, they could create one.
Below is the prototype of the final branded app we demoed to the CEO.
The CEO was so impressed with Flex that he requested that the features I had designed be developed into the existing EE app rather than create a brand new one.