TU Go Web Client
TELEFónica Digital
Capabilities: UX Design, Team Leadership, User Research, Agile
Tools: Sketch, Invision, Illustrator, Design Sprint
Timeline: 2014-17
Background
TU Go was a messaging and calling service that put your phone number in the cloud. Log into the app on iOS, Android, or desktop using a compatible browser and you could call and text over Wi-Fi and view your communication history without the need for network coverage, or even your own phone. TU Go was available from O2 in the UK and from Movistar and Vivo in LATAM and had well over 1M users per month running 44M sessions.
Overview
Telefonica wanted to make use of Web RTC technology in a new web client for TU Go for desktop use. I led the design team comprising a junior UX designer and a UI designer to generate and deliver design concepts, prototypes and specifications to remote Product and Development Teams in Tel Aviv and later, Barcelona. In spite of very aggressive timescales for delivering a robust concept, careful planning and an innovative and thorough design process delivered 2 design concepts with rationale, prototypes and a recommendation. Discarded designs were also delivered with the rationale for dropping them. Detailed design followed and several further iterations were made in a fortnightly release cycle, adding functionality and enriching the user experience. This case study focuses mainly on the initial concept design phase, but iteration continued throughout the 3 years the product was live for.
Inputs
From the Product Team we had an MVP specification comprising 16 bullet points, four minimal personas and a timescale of 1 week to deliver a design concept to hit the Development start date driven by team availability.
The existing TU Go designs for tablet and desktop were optimised for their native context. I wanted to explore what an optimal design for a web context would be, but with so little time, developing a concept out enough to have confidence in its extensibility and longevity was ogling to be a challenge.
Desktop web is different to the other platforms…
Keyboard offers quick and easy text input and task switching
Device ‘sessions’ are likely to be extended rather than bursty
A large screen is usually available, but…
You can’t always count on the browser being full screen
Usage context for desktop web is different to existing TU Go clients and it might even attract different users
…working on the proviso from Product that users accessing the web version on a mobile or tablet would be directed to the app download.
Approach
Flexibility, using whatever tool or technique that makes sense for the task at hand and gets you where you need to be, rather than rigid adherence to a process.
Here, the process was as lean as possible:
Discussion, understanding and planning up front with just enough structure
Time-boxed stages in a clear path to deliver to the timescales
Focus on iteration and evaluation
Lean documentation - just enough to communicate concepts clearly to remote teams
I wanted to explore the design window quickly but thoroughly, discovering and understanding the obstacles and opportunities there. The team had varied levels of experience and different skills, we had limited time. To get the most out the process for the designers and the design required complete openness, objectivity and empowerment in evaluation sessions - no egos. We needed to develop together the vocabulary and understanding to be able to discuss why some designs worked and others didn’t. It’s all about the design, not ‘my’ design and the process drove this, loosely following the Design Sprint model.
Setting Up
I ran a kick off planning session to…
Review the inputs - MVP spec, personas and timescale
Define the stages we would work through to get to the final deliverables on time, starting with…
Key use case identification - to exercise designs early
Exploration of likely usage patterns and scenarios to contextualise design
Development of some design principles to focus design
Plan an interim presentation to keep the Product Team in the loop
Some of the session products as written up for the Product Team presentation - functional rather than pretty
Product agreed to revise the MVP with design feedback and we got cracking with a series of time-boxed ideation sessions.
Designing and Evaluating
Ideation sessions with all 3 of us designing were conducted as follows:
A brief outlining the session scope and aims
Individual designing and sketching, each design on a separate sheet, for a fixed time, usually an hour or so
Regroup and add all designs to a pile and shuffle
Recap session scope and aims
Each designer takes one third of the pile
Pitch/present designs to the other two. Originator can contribute if the presentation doesn’t do the concept justice, but the onus is on the designer to get enough down for any designer to pick up and present the concept
Vote on the design - 1 vote each - to put it in either Live on / Recook / Park piles
Discuss scope for the next design session - this could be further development or recombination of ideas from this or earlier sessions, or a new area
Design sessions explored the overall framework of the UX, responsiveness, access to functionality, behaviour of the communication history panel, how and where to display chat windows, chat window show/hide/switching behaviour, feature details, flows through use cases and microinteractions. We kept it all on paper as I wanted us to focus on communicating design rather obsessing over design detail.
Design Review with Product
We reviewed the UX frameworks from the ideation sessions to identify the strongest candidate and made a simple presentation of all of them with description, pros and cons for the Product Team. After 3 days planning and designing we presented all of the designs to Product along with the design principles, use cases, usage scenarios and some questions.
We’d identified 2 lead candidates:
A conservative design building on the existing tablet client
A fresh design that more attuned to the desktop web usage context and the affordances of desktop browsers
The aim of the meeting was to reassure Product that we were on track and to ensure alignment on design drivers and direction. Presenting all the alternatives demonstrated the breadth and depth of the design work, and addressed the ‘Why don’t you just…?’ response you often get in this kind of situation. Our thorough exploration of the design window and the design process ensured we had the knowledge, vocabulary and confidence to satisfy all Product feedback.
Some of the alternatives presented…
Design Round 2
Product agreed with our proposed 2 candidate designs for further development and appreciated being talked through the other avenues we’d explored. The next stage was to extend the 2 designs adding functionality and detailing out features.
For some very focused areas of the UX, we ran ‘sketchathons’ - 15 minutes of 2 or more designers sitting together generating as many ideas as possible around a particular concept, then reviewing to understand what works and what doesn't and hopefully to trigger more more ideas to explore. Depending on the review results, we’d go again for another 15 - designing out ideas that were working, sketching a newly sparked idea or coming up with new ones until we felt we were done. A final review would decide which idea to bring into the product.
Unlike Crazy 8’s, you get to go again, rather than stopping when you just got warmed up, there’s more time to design an idea out and build and you get to explore the space more thoroughly. These sessions really shook out ideas and let us stretch and test them. Although exhausting, they were a lot of fun and got us to robust designs quickly.
Prototyping
We made paper prototypes of both of the 2 candidate designs, walking through the highest priority use cases for each design. our sketching muscles had been well exercised so it made sense to stick with paper - quick to make, cheap to change and easy to extend. Paper also allowed us to incorporate the structural animations we’d designed to engage users and support understanding of the UX. It wasn’t feasible to portray these with the digital tools available in the time we had.
Photographing each stage of the interaction and animations, we produced a stop-motion video of each use case for both designs. Primitive though this was, it made it easy for viewers to understand the framework and interaction - we controlled the speed of interaction and could easily annotate it. This was very important given that our Product and Development partners were remote. It was also a lot of fun to do. The Product Team were very appreciative for getting such a rich picture of the design direction the project was taking.
Getting access to TU Go users for testing was difficult and slow at this point in the project - we had to negotiate with O2 to organise access to them. With a week to create a design and little notice of the project there wasn't time to get through the bureacracy. Instead we conducted ‘show and tell’ sessions with the prototypes to people in the office, getting positive feedback. Full user testing was scheduled in for when the Development Team had built the first iteration, which gave us enough time to recruit real service users through O2.
Outcomes
The project delivered results on many levels - design, process and team.
Design Outcomes
We’d delivered a robust and extensible design framework that we were comfortable could accommodate the functionality on the roadmap without the need to refactor the UX - we hadn't built in any UX debt. This was fortunate given the fact that there was zero scope to refactor UX as the Development Team had no front end expertise. We continued to build on the framework we’d designed for the next 3 years.
When we did user testing a few weeks down the line with an early implementation, we scored a 98.75% task success rate and received positive verbal feedback from users.
Process Outcomes
The process achieved all the goals I had for it:
Delivered the right design
Gave us a deep understanding of the space
Which made discussions with Product and Development Teams easier
Made production of detailed design specs easier and quicker
Engaged and motivated team members
Was very productive but still fun
Team outcomes
The Design Team and the wider project team also benefited from the project:
The thorough exploration of the design window, pitching and reviewing had made designers better at presenting design
Engagement and motivation to created detailed design was high
Communication within the Design Team significantly improved - the process fostered a more collaborative approach in the team
Product and Development stakeholders easily understood the design as the materials communicated it effectively, deepening the relationship
Continuing Design
Moving into agile delivery I spent time working with Development to determine the most expedient way to specify design, aiming to make it as easy as possible to implement and get what was built as close as possible to what we’d specified. I also worked with the Product owner to create a ‘Definition of Ready’, specifying what design collateral must be in place for a story to be taken into a sprint to ensure design enabled development as much as possible.
Following the initial MVP release, we continued iterating the design with new functionality, enhancements and bug fixes in fortnightly releases. Added features included Group chat, Media sharing and Video calling through to 2017. Eventually we even got the developers to build the structural animations after I managed to persuade them that they could actually do it and that it would add value. Most recently we revamped the on-boarding process across the service, redesigned tu.com, the homepage for the service (now off-line), and adapted the registration process to make it available from O2, Movistar and Vivo TU web pages.
TU Go service was discontinued at the end of 2017 as the mobile clients were superceded by native Wi-Fi calling.