While at blinkbox books, I drew on Service Design methods to review the original Mobcast service (bought by Tesco), define the customer personas, define a customer lifecycle, and spot immediate potential for pain points and ‘wow’ moments. This work was incredibly useful during ideation and added depth to the user workshops that kicked off the project, plus some options for cross-channel work involving Tesco stores moving forward.
I built profiles from original TGI segmentation data, then once I’d done a review of the existing Mobcast/Uncuva service, combined the requirements of these profiles with the review to create experience maps and a draft lifecycle journey, upon which further research and design work was based. I then refined the lifecycle journey once this had been further validated with stakeholders and customers (in workshops and research).
I was the first member of the design team to join blinkbox books, which until that point had utilised developers and the business team to create their product. Up until the merge with Tesco this was called Uncuva, an app which was quite happily ticking along with an acceptable number of users. While Uncuva was by no means a design horror, there were some obvious changes required, and a general need to look at the service through the eyes of the user, rather than just following design norms or business needs.
I was lucky enough to work with some extremely talented, experienced designers while at blinkbox; and I owe much of what I know to their mentorship. Having previously made an unusual leap straight into contracting as a junior, I made the most of my permanent position by absorbing as much as I could, until I felt comfortable heading back out into the freelance world.
We took a UCD (User Centred Design) approach, rapidly iterating and testing often with users through various methods – whether that was standing on a street corner trading chocolate for guerrilla tests, or hiring a state of the art research lab for usability testing. This didn’t mean that we never experimented or took our own initiative; but every design decision was validated by our users, across the target segments.
This timeline shows some of the main activities I was involved with – and highlights those that I led:
Very large – opens in a new window
As mentioned, we followed a UCD design approach. Initial research was conducted to create segments, and those segments were used to create profiles and recruit users for experience design workshops. Some of those workshops even involved co-design exercises, though mostly they were to find out what was a necessity for users, versus what was nice to have, which then fed into the design of the service.
We followed service design principles, considering the eBooks service as a whole that was greater than the sum of its component parts. Here’s an example of one of the personas created to ensure designs always met our users’ needs:
…we completed thorough reviews of the end-to-end overarching journey (plus more detailed journeys for different personas)…
…and used quantitative research to understand the different possible scenarios that could arise at each step of those journeys.
We used our insights to better understand the emotional state of the users at any given moment in their journey, and considered how this might affect their goal – or even just the concentration or effort they were willing to put in at the time. I used this diagram, which was originally developed by Matt Watkinson.
I worked closely with the developers to ensure that I was designing viable solutions – and while the process wasn’t entirely lean, there was no need for completely detailed specification documents due to the close, interdisciplinary teams and open plan working environment; we all knew what we were doing, and there were no barriers to talking to one another!
In order to create the designs, some detailed background work was required. I focused specifically on the “buy an eBook” and “manage your account” journey stages, and started by creating information and state models to better understand how all of the component parts fit together. Doing so meant it was just a case of ticking off the different states and information and making sure it was all covered in the wireframes. I additionally created a task model which detailed every possible action a user might want to do – based on our own understanding and the insights from consumer research – which helped us to understand which features were necessities and which were nice to have, prioritising accordingly.
Very large – opens in a new window
Of course, the next step was to produce wireframe designs which covered the information, tasks, states and user needs identified throughout all of the previous work. Below are some examples of those wireframes. I designed for Apple and Android, on both mobile and tablet (portrait and landscape), taking into account OS conventions – plus the difference in licensing agreements which meant that eBooks could not be bought through Apple devices. I also looked into what the confirmation emails could look like, though these were to be produced in a fairly rigid system that did not allow for a great deal of creativity.
I was very pleased to become the designated copywriter on the project. This was, in part, because we didn’t have one – but also the tone of voice I’d used in my wireframes worked well and once I’d agreed a style with the brand director, I took over the copywriting for the service.
Two approaches were trialled for this: first, professional but friendly. This is quite typical of popular brands like Apple, Amazon and so on – where it’s fine to use contractions, use simple language and have a friendly tone, but this remains professional and could be expected of a conversation with someone in the office. The second approach was more of a ‘fun’ tone of voice – cheekier, jokey, and a little more colloquial (though nothing too extreme!).
While the first approach tested well, I was keen to experiment with the second given our funky brand colours and the style of other apps that were popular with our segments. Unfortunately I left the company before I was able to see this tested.