Three - Omni-channel redesign
I was responsible for redesigning 4 major post-onboarding (‘In-life’) experiences for the Three app.
Our goals:
to turn the app into the primary channel– a simpler, more effortless alternative to physical channels.
proactively help new customers make the most of their product (checking contract timeline usage and offers) and improve self-service features to reduce pressure on call centre
upsell and cross-sell products, provide personalised and tailored recommendations.
Context
Team set-up
The team was split into squads - each of them would be looking at a specific stage of the customer experience (e.g. Join, In-Life, Leave, Help etc). Naturally, there were many overlaps and intersections. From day 1 I felt it would be crucial to continuously talking to the other teams in order to keep up to date with their solutions and challenges. Later on it it proved to be the right approach to take (I knowledge shared what I learn from the client about the add-ons; I’d constantly talk to other teams about the gaps in my knowledge and they’d typically have the right answers. I also encouraged peer reviews that eventually became part of our work flow.
Challenges
No ability to user test the existing app and its competition. I had to get creative in terms of engaging friends and family to access, study and analyse the competitors’ offering.
Lack of proper communication between team leads. Many patterns ended up getting re-invented over and over again (that was later solved with regular multi-squad catch-ups)
Temperamental version control software (Abstract). With over 20 people using it simultaneously we’d occasionally loose work due to software glitches.
Lack of developers on the project. I literally had to consult my professional network and software engineer friends
The client was still in the process of refining their product offering (specifically - add-ons) resulted in multiple iterations each time the client would make a change.
My process
Research & Workshops
Jobs-to-be-done
Flows
Templates
Wireframes
UI
Prototypes
Guerrilla testing
Research
By the time the final team was assembled, the research was done. Three provided a comprehensive set of documents such as of market data, vision and strategy documents, benchmarking document looking at the mobile network business in the UK and customer insights (there was some analysis of the main stages in the customer journey - “I explore”, “I join”, “I get help”,” I change my prop”, “I use” etc). The Bio agency had created the overall CX strategy document we’d refer to throughout the project.
Whilst digesting the overwhelming amount of new information on how mobile networks work, I’ve also been reflecting on the fact that access to mobile network is such a universal thing and what it may mean to the overall product design approach.
Workshops
Most of the research we had available was concerned with the strategy and customer journeys. However, there was very little explored around the mental models and the wider digital context of the Three customers. We ran a number of workshops and sessions looking at competition, patterns that would work with the customers’ mental models.
As a team, we ‘inherited’ a list of business requirements and “user stories” that were written by the team who drove technology behind that project but was taken off the project due to the lack of required expertise to deliver the product end-to-end.
Those user stories were dry and written from the technological feasibility point of view (they sounded more like a technical spec) without taking into the account any customer needs. Luckily, I had a chance to challenge some of those as they seemed more internally focussed and far too prescriptive leaving very little room for “transformation”.
As a team we run through the entire list, owning parts of it. I put my user tasks and requirements into groups (e.g. update payment method) and, using the jobs-to-be-done framework, translated what was more feature-focussed into user jobs and experiences. Those gave me freedom to explore different ways of solving customers’ problems, as they allowed more empathy and less technology/development driven approach.
Luckily, Cat, our team lead, was as fond of the JTBD framework as I was and it was decided to do it with all user stories.
On the back off the user ‘jobs’ I then created detailed flows for each user journey (Direct debit, top-up, add-ons, update plan etc), regularly checking in with my team mates to make sure my flows fit nicely within the overall customer experience and the journeys are intuitive.
Sketching
Once all flows were peer reviewed and connected, I jumped to sketching.
During the design and refinement stage I had to request some extra information like call centre reports, web and app analytics around top features and top tasks to make sure I surface the right content when the rest can be tucked away or be visually de-prioritised. I also heavily relied on the product offering breakdown that got changed by the client at least twice during my assignment, which made my process highly “iterative”.
All wireframes were expected to be high-fidelity and provide detailed annotation for the client playback. Once signed off, they smoothly transitioned into UI designs.
UI
Each UXer was paired with a UI designer. We worked together on refining patterns and components for the future design system, making sure the IA and the journeys are communicated in a usable and intuitive visual way.
Conclusion
Whereas it’s always a little sad to hand over the product to the client and the external development team which often happens in the agency environment, I still gained plenty of experience analysing, understanding and questioning big systems, working in a large team where good communication and work visibility was key. I also embraced the power of peer reviews.
To sum it up
High-fidelity
I produced a set of high-fidelity wireframes that offered detailed annotations as well as multiple variants (taking into account both happy and unhappy paths and scenarios).
Attention to detail
I was the go-to person on the team who could advise and explain the complex product offering and logic behind product combinations. I also broke silos when it came to sharing progress, strongly encouraging the team to run peer reviews. Those improved quality of our work and illiminated some issues early in the process.
Complex to simple
I made good use of my ability to process large data sets and analyse complex systems to translate those into simple and easy-to-use interfaces.