My Capstone Journey
It started with a holiday back home, seeing how differently the generations in my family decide what they will watch on TV, from my Granda that has a handwritten list of channels that he likes to watch, to my little sister with iPad in one hand and hours of recorded TV shows to catch up on. I came up with my initial idea for a new TV app — an app that would connect to your TV and help you manage all the options, from your favourite channels, to your recordings to being able to search with your mood as the main criteria.
Needfinding
With the idea in my head, I started out on my needfinding exercises. The best way to find out what a user does and what needs they might have is observations. In addition to spending some more time with my family, I reached out to some friends and colleagues — it was an easy sell, they just watch TV as normal, and I’ll bring the tea and biscuits. For my observations I sat with each person for 30 minutes to 1 hour, firstly just watching them interact with the technology that they use to select the TV shows that they want to watch, but asking them to also describe what they are doing — it seemed a bit of an eye opener for them as well as me, with a few ‘I don’t know why I do that moments’ from everyone.
At the end of each session I spent another 15 minutes asking them questions about why they use the methods and technology that they do, and what they would like to see work better. I was surprised at points that some of the participants would skip over the inbuilt functionality that their TV Service provided, to carry out the tasks in a more ‘manual’ way — when I asked about this, for most it was a case that although the functionality existed, the process for either initially carrying it out, or the process to get the results had too many steps and especially for those less technology inclined it all seemed a bit difficult.
The ‘blue sky’ ideas were sometimes insightful; ‘…if I’ve recorded something, why would I want to see the Ads…’; and at others a bit fanciful; ‘…it should read my mind to know what I want to watch…’.
Ideation
Following the observation sessions, I had a large list of ‘things’ either that I picked up or that the participants had commented on as we carried out the sessions. The task now was to break these down into a manageable list of User Needs, as I started reviewing it became obvious that a lot of the participants had the same frustrations and similar ideas, all just expressed slightly differently. Lining these out give me a starting list of 17 User Needs:
1. User needs a buttons to be large so that they are easy to see and select to avoid mistakes when selecting the options
2. User needs to be able to see only the channels that they have access to view to reduce the frequency of selecting a channel that they do not subscribe to
3. User needs a simple user journey for specifying the channels that they watch regularly to allow this to be done quickly and easily by users who are not tech-savvy
5. User needs a way to watch a show from the start when the tune in late so that they do no miss the beginning of the show
6. User needs to be informed of the next episode/showing of a programme they are watching so that they are aware of the next time that they can catch up and if they will not be able to watch the show they will be able to record it for later viewing
9. User needs to be notified when a number episodes of the same show have been recorded so they do not get to a situation where there are numerous recordings that they have forgotten about.
10. User needs a way to be reminded of available recordings when they are ‘channel surfing’ to give them the opportunity to catch up on recorded shows that they have not remembered about
13. User needs to be able to search for shows based their current viewing mood to allow them to find something that they want to watch
16. User needs a way to be informed of new programmes that they would be interested in to allow them to find shows that they were not previously aware of
17. User needs a way to know if a recording is going to be deleted with some advance notice to give them the opportunity to watch unviewed episodes.
With my ideas in place, I needed to come up with the Point of View that I would use throughout the rest of the project. This is a statement that I would refer back to repeatedly during the project, to remind myself of what I was hoping to achieve and the user journeys that I wanted to accomplish:
People often watch television to relax and take great enjoyment from the shows that they watch all the time. With changes in technology the way that people watch television is changing, for some the simple task of finding a show is daunting with remotes having too many buttons and on screen menus having too many options. For some even knowing what channels that they have access to is a regular struggle and frustration with new channels becoming available every day and old favourites being taken off the air. For those with a better handle on new technology and functionality frustrations still exist with these improvements, from ending up with too many episodes of a show to catch up on, or services deleting old recordings before you have the opportunity to watch them. People want to be able to glance at the tv guides and decide what they want to watch, they want to be able to glance at the remote and easily select an option.
Finally I needed some additional inspiration — what colour palette should I use, what functionality had I seen work well elsewhere, any layouts that I liked
Prototypes
Next up, it was time to break out the pens — starting with the storyboard.
Storyboards allow you to think about the “Setting, Sequence and Satisfaction” that your app will achieve — where is this going to be used, who is involved and what are they trying to do; what makes someone decide to use your app, what is the sequence that they will use; what was the end result, what was the motivation for the user. This is a process I enjoy, not just because I love any excuse to break out the markers, but once again it helps you to really consider how your app will work:
With the storyboards done, Paper Prototypes were up next. Paper Prototypes are the first stage of the design of the app, by creating these on paper, instead of creating a wireframe in a design tool, means that the first prototype can be created very quickly. It stops me from focusing too much on making every element line up exactly, or worrying about the style or finer layout details. The prototypes allowed for two tasks that tie to the Point of View created earlier in the process. For each prototype I created a couple of screens that would allow me to mimic the process that a user would go through to carry out the tasks. I find the Paper Prototyping to be a really useful step in the design — it gives me a change to think about how to make the layout work, and how to make completing the task as easy as possible for the user.
Heuristics
Once the prototypes were in place, my next task was to get some feedback on the work I’d done so far; after spending some time going through the paper prototypes, and making sure that the pages were in order, I asked a friend to walk through the prototypes for me. As the prototypes were paper based, a little bit of imagination was needed, as my friend ‘clicked’ and ‘swiped’ around my app, I was switching out pages and pop-ups (even employing the sound effects, that I’m not sure improved the experience). During and after the session I made notes of the feedback my friend gave, as they ‘played’ with the app. Once this session was over I spent time reviewing their comments and matched these up against the Nielsen Heuristics. The Heuristics are a list of 10 general principles for interaction design, which when applied to a design can assist in improving and making a better user journey — you can find more information on these heuristics at: https://www.nngroup.com/articles/ten-usability-heuristics/
In addition to getting the feedback from a friend, my paper prototypes were also reviewed by 2 peers completing this project. They provided me with additional feedback, again based on the Nielsen Heuristics, including a severity, which helped me set some priorities around the items that I would change as the app moved through future iterations.
Going through the full list of feedback I was able to consolidate a lot of it, while some of the feedback had been similar, people had rated it with different severity based on how they would expect it to work. Not only did I have a list of potential changes to make, but I also had gained some more user insight on how others would make use of my app idea.
The last part of this weeks task was to create the first wireframe for my app, I started with the Homepage — what the user would see after logging in:
A Plan and a Skeleton
With all the feedback received to this point, I was now in a position to really start working on a full prototype for my App, with 5 more weeks to go, I had my timeframe, but I still needed to make a full plan of how to achieve everything I wanted before this final deadline, while including the set tasks that also had to be included each week, bring on the excel file…
Into my plan I started with the key milestones (as set by the weekly assignments for the project) and then tried to plug in the changes I wanted to make to my prototypes from all the great feedback I’d received, and the estimates included for each task.
The Skeleton navigation for the app also needed to be mapped out; not just to give clarity to what I was going to try and achieve, but to also help map out the User Journeys — what screens would a user have to navigate through to complete each of the tasks available on the app. I found that this, which at first thought, can see like quite a simple task, can easily stretch and take a lot of time. You need to consider the points in the journey that the user might decide to change the task they are carrying out, or that they want more information. It’s this point where you have to think of the less obvious paths, the ones that you never expect a user to take (which in my experience ends up being the main path that all users use)
After the navigation I started to work more on the prototypes, I am already quite familiar with Visio, so I decided that I would create my wireframes there and would then use InVision to allow me to create something that became interactive for the user — they can click around the application, using the created hot-spots (this was the big ‘Wizard of Oz’ technique I employed for the project, InVision allows you to upload images, and link them together using hot-spots — these hot-spots can mimic user actions, such as clicking and swiping, and gives the user the feeling of the app actually working — all without having to plug in the code to make it really work).
I enjoy this part of the process, as you can really start to see your idea coming together, but it is a time consuming part, especially if like me you need everything to be properly aligned and to sit correctly together. By the end of the week I had created several of my key screens.
Ready for Testing
For the next week I concentrated on creating the wireframes for the rest of the pages on the app, as well as continuing to make some of the improvements that had been taken from the Heuristic Evaluations. As the app started to take shape, I often found myself going back to previous pages to make little changes that tied in better with the design of the other pages I was working on. In addition to this I started to plug all the wireframes into InVision. Using the functionality of InVision my app started to feel more realistic, with the ability to create overlays, and specify how the pages changed, add swiping and scrolling. Even having some experience with InVision already, it was a time consuming task — changes to the wireframes would mean that the hot-spots needed to be moved to make sure that they continued to sit over the correct area of the screen, and making sure that the overlay items remained in the correct area of the screen.
During this week I also had to start thinking about the first round of User Testing — I had to define some tasks that I would be asking users to complete
Test Your Prototype
This week my app was getting handed over to strangers for some testing, having spent the last week tidying up the wireframes and the InVision prototype, I was starting to feel the nerves.
To make sure that everything remained fair I created a ‘script’ that I would use during the tests. This script contained the overview of what I was hoping to achieve, and the tasks that I wanted each user to carry out. It also gave me some boundaries around what I would help the user with and what hints I could give when they were stuck. Each Participant would be asked to complete a consent form, giving their agreement for details of their session to be shared and allowing me to take their feedback to make improvements.
With everything prepared, I set out to find some users — there was a local food fair on, and I thought that would be a good place to start. Following my earlier success of tea for assistance, I knew that I could reward any participants for their time with a cup of tea and a tasty local treat. After approaching the first table of people I had 3 agreeing to participate in the test.
InVision allows you to text a code to someones phone, so that the prototype can be tried out in the expected environment, only two of my three volunteers had their phones with them, so I sent them both the prototype link. I sat with each one individually, so as not to allow one to gain extra knowledge by seeing the tasks completed by the first participant. During this time, the participant was asked to complete the 3 tasks I had set, while describing to me what they were doing and thinking as they navigated through the app.
At the end of the session I had some new feedback, the participants had some more tea and cake, and I returned home ready to break out the pens again, to come up with some additional changes to the app.
The next action item for me was to start to plan the A/B tests — with the feedback from the live user testing I had a couple of scenarios to try out.
Results
The task for this week was to run the A/B testing, as per the terms of the assignment I used the UserTesting website to achieve this. It was a site that I has used in the past, so I had a couple of teething problems, but finally a working prototype to test out these final ideas. Within an hour I had my results — unfortunately they weren’t as clear as I would have liked. Out of the users that had picked up my prototypes none were familiar with InVision and how it worked, and because of this, the feedback wasn’t great. For each user, a lot of the time was spent working out what the ‘blue flashes’ (i.e. the hot-spots) meant, and how to get around.
I hadn’t foreseen this being an issue — but lesson learnt, next time make sure to provide a bit more detail and explanation on what the prototype is, where it is hosted and how to navigate around it.
Thankfully, the testers pressed on, and started to review the prototype, but from the original 4, only 2 managed to complete the tasks that were initially set. Despite not being able to fully analyse the A/B testing, each of the users did make the effort to give feedback on the pages that they got to, and from what they could see they were giving feedback on how they expected the application to work. And to my delight a lot of the feedback was positive.
The feedback meant a few more tweaks and changes to the prototypes. With these complete, the ‘TV App’ is now ready to move onto the next stage — sharing it with the big wide world, though this post, YouTube and social media. Maybe someday soon you will be able to download the shiny finalised version from your mobile app store. Until then, feel free to have a look on InVision: https://invis.io/J78A4UDK6
