TU Go was a messaging and calling service that put your phone number in the cloud so you could use it on any device over Wi-Fi, to contact any phone number. Logging in to the app on iOS, Android, or desktop using a compatible browser, you could call, text 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.
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 a design concept to remote Product and Development Teams in Tel Aviv and later, Barcelona. In spite of the very tight timescales for delivering a robust concept, with careful planning and an innovative and thorough design process, we delivered prototypes for 2 design concepts with rationale, prototypes and a recommendation, along with a set of other concept explorations with the rationale for dropping them. We subsequently delivered detailed design, shipped the product and made several further iterations over a couple of years, adding functionality and enriching the user experience. Here I’m just going to talk about the initial design creation.
From the Product Team we had an MVP specification comprising 16 bullet points, four basic personas and a timescale of 1 week to deliver a design concept to hit the Development start date driven by team availability.
The existing designs for tablet and desktop were optimised for their native context. I wanted to explore what an optimal design for a web context would look like and was convinced we could do this and develop a concept out enough to have confidence in its extensibility and longevity in the time that we had.
Web is different to the other platforms…
…working on the premiss from Product that users accessing the web version on a mobile or tablet would be directed to the app download.
I’m more into flexibility, using what makes sense for the task at hand and gets you where you need to be than following a rigid process every time.
Here, the process was as lean as possible:
I wanted to explore the design window thoroughly, discovering and understanding the obstacles and opportunities there quickly. The team had varied levels of experience and different skills, we had limited time and I wanted to get the most out the process for the designers and the design. This required complete openness, objectivity and empowerment in evaluation sessions - no egos - and developing together the vocabulary and understanding to discuss why some designs worked and others didn’t. It’s all about the design, not ‘my’ design and the process drove this. I decided to keep designs paper only to avoid over-obsession on design detail and to focus on communicating design.
I ran a kick off planning session to…
Some of the session products - functional rather than polished
Product revised the MVP with design feedback and we got cracking with a series of time-boxed ideation sessions.
Ideation sessions were conducted as follows:
Design sessions explored the overall framework of the UX and 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.
Some sketches from a design session…
We reviewed these UX frameworks to identify the strongest candidate and developed 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 more conservative design building on the existing tablet client and a fresh design that more attuned to the desktop web usage context and the affordances of desktop browsers. The aim of there meeting was to reassure Product that we could do it, we were the right people for the job and to ensure alignment on design drivers and direction. Presenting all the alternatives demonstrated the breadth and depth of the design work, and avoided the ‘why don’t you just…?’ response you often get in this kind of situation, because we already had. The design process ensured we had the vocabulary and confidence to deal comfortably with the discussion.
Some of the alternatives presented…
Product agreed with our proposed 2 candidate designs for further development and appreciated being talked through the other avenues we’d explored. - the presentation was a success. The next stage was to extend the 2 designs adding functionality and detailing out features.
For some very focused areas of the UX, I conducted ‘sketchathons’ - 15 minutes of 2 or more designers sitting together generating as many sketches as possible around a particular concept, then reviewing to go over highlights, dead ends and to refocus. Depending on the results, we’d go again for another 15 - building on what we had, developing an idea sparked by another sketch or generating more until we were done or dried up. 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.
The structural animations in the designs were not feasible to portray in the tools available to us at the time. Our sketching muscles had been well exercised so it made sense to stick with paper - quick, easy to change and easy to extend. We made paper prototypes of both of the 2 candidate designs walking through the four highest priority use cases for each and captured interaction to produce a stop-motion video for each use case for both designs. Primitive though this was, it was easy to understand the concept and interaction from the video - critical, 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 as we had to negotiate with O2 to gain access to them. With a week to create a design and very little notice upfront, we relied on the insight gained from the rounds of user testing we’d done for TU Go 2.0 and did ‘show and tell’ sessions with the prototypes to non-tech people in the office and got a positive response. Full user testing was scheduled in for when the Development Team had built the first iteration which gave us enough time to recruit service users through O2.
Making the paper prototypes...
The project delivered results on many levels - design, process and team.
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.
The process achieved all the goals I had for it:
The Design Team and the wider team also benefited from the project:
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 Product to make a ‘Definition of Ready’ - what needs to be in place before a story can be considered ready to be taken into a sprint.
Following the initial MVP release, we continued iterating and improving the design and delivering new functionality, enhancements, bug fixes and eventually animations when the developers had developed the expertise and finally gave in to doing it, in fortnightly releases. These included features such as Group chat, Media sharing and Video calling through to 2017. Most recently we revamped the on-boarding process, redesigning tu.com, the homepage for the service, and adapting the registration process to be 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.