Adding new Functionality to Twitch
GA UXDi — Project 3
Project 3 of the General Assembly User Experience Design Immersive is the first group project we have had to deal with. Split into teams of three, we were each given a company that was looking to add a feature to their existing site — as opposed to the previous project where we were creating a brand new micro-site for an existing company. My group and I were given the company Twitch, and our brief was as follows:
Twitch wants to increase customer engagement by introducing a feature that allows users to upload video game walkthroughs.
As always, we started with discovery, and whereas with previous projects we were familiar with the brands already, this time around we needed to research who Twitch were, what they offered, and what standards or principles they live by.
Now, I already game in my spare time so I was aware of Twitch and knew that it was a place where gamers can stream videos of themselves playing games in real-time. The main screen would show both the video game and the person playing, and any other members of the Twitch site could view the videos and make comments as they were watching.
They describe themselves as:
The world’s leading social video platform and community for gamers.
It was this sense of community that we would have to build on when implementing our new feature — video game walkthroughs.
What are Walkthroughs?
To properly implement the feature, we first had to understand what walkthroughs are, where gamers currently find them, and any pain points they suffer currently when using them. We found they are broken down into two main styles. Text-based walkthroughs, and video walkthroughs.
Who uses Walkthroughs?
Having had a fair amount of experience with video games, gamers and the types of people who would use walkthroughs, I built three assumed personas that we would look to validate through our research:
- The gamer who uses walkthroughs at the same time as playing a game.
- The gamer who reads walkthroughs prior to, or after playing a section of game in order to prepare for the next time they play.
- The gamer who watches walkthroughs as a type of review, to see if they would like the game enough to buy it.
To find people who currently use walkthroughs, and who would benefit from the new feature we implemented, we created a screener survey — a series of questions that would either qualify or disqualify respondents from being contacted for further interviews.
Our red lines were :
- Respondents had to play video games regularly
- Respondents must have used a walkthrough in the past month
- Respondents must be willing to be contacted
We also needed a distinct group of users who had created video content regularly and uploaded it to a video sharing site in the past. To ensure that we had a good response rate we spent a lot of time working on the tone of the survey to make sure it sounded light, and would appeal to our target audience. The original title for example was ‘Video Game and Internet Usage Survey’ which was far too dry. ‘Video Games and You’ was much more enticing, especially when accompanied by an explanation that assured those taking the survey that it was only seven multiple choice questions, and that they would get a coffee if they were interviewed further.
We set the survey up using Google Forms and you can take the survey yourself here.
We shared it on our own social media platforms and the GA slack channels and waited for the responses. When we had a good amount of responses — we ended up with 42 — we started to filter through them and look for potential interviewees judging on the criteria listed above. We ended up with a list of fifteen people to talk to and started to schedule interviews in person, over the phone, and on Skype for those across the Atlantic.
The key takeaways from building a survey were :
- The more specific your questions are, the more likely it is that the response will be useful
- If the question is overly specific the respondent might just answer the way they think they should, rather than being honest
- You will always need more responses than you think, as a good chunk of them will not be useful
Once we had our interviews set up, we split them between us so we could cover three times as much ground in the same amount of time. This was a great opportunity to glean as much information as we could without having to worry too much about time pressures. We found that our interviews would last around thirty minutes on average, which was enough time to get a good amount of information without the interviewee feeling as though they had been there a long time — though free coffee obviously helps.
Our interviews were based on a loose structure, but we always started by asking about the last time our interviewee either uploaded or watched a video game walkthrough and asking for a step by step analysis of their process. We were really trying to find out where they remembered being particularly pleased or frustrated with the process without prompting any of our own assumptions. After conducting our interviews, we came back together to pool our findings and decide what we would focus on when creating our solution.
The key findings from this stage were:
- Gamers find their walkthroughs almost exclusively through Google and then Youtube
- There is a big difference between when gamers will use video walkthroughs or text walkthroughs. The choice will be based on what type of problem they are looking to solve
- The main wish gamers have is for an easy way to skip to relevant parts of a video, and to know that they won’t be exposed to spoilers (plot exposition) without warning
- We needed to make sure that anybody uploading a video was aware that they would get more views and likes if they were giving the viewer what they wanted — as listed above
We had challenged our assumed personas with the research, and we were left with our two primary personas — one for the consumer or viewer, and another for those uploading content and they can be seen below:
Devon is our primary consumer of walkthroughs as he represents the most common problems and needs from our research. Devon’s current situation is as follows:
You can see from the journey above that the main areas to work on are making sure that the videos are relevant to his problem in the game, and that don’t leave him disappointed with what he’s watched. We would need to design a system to protect Devon from spoilers, and provide him with a search that only shows the most relevant results for his problem. But to do that we would need to make sure that our upload process was right for our primary uploader; Paddy.
Paddy was our representative for the responses we had from those uploading content. His primary goal is to get as many views as possible on his videos to increase the likelihood of earning money through the existing donation and subscription options on Twitch.
Paddy’s current situation is as follows:
As you can see from the journey above, the problems Paddy faces is that his videos are not getting as many views and likes as he wants, and that he feels that stems from not being able to have the content of his videos be reflected accurately in the search results.
We had a useful situation where we would need to keep in mind that our proposed solution for Paddy would have a direct effect on our proposed solution for Devon and vice versa. So whilst we would be working on both problems individually, they would be inextricably linked.
The purple boxes above are additional steps we would add into the upload process that would solve both Paddy and Devon’s problems at the same time.
Our solution had to allow Paddy to upload videos that contained descriptive tags that would make the video easy to find through the search function on Twitch. There should be ‘timestamps’ by the video, which are links that skip the video forward or backward to the relevant topics. Finally the videos should contain a warning if there are spoilers in it.
Before we could start building anything, we needed to decide on the principles that would inform our design decisions moving forward.
Design Principles & Studio
In designing our solution, we pledged to abide by the following design principles. Our designs would be:
- Consistent with the existing Twitch design elements
- Focused on visuals in place of text wherever possible
With our principles in mind, we engaged in a “design studio”, in which we developed concept maps and sketches for how to transform a particular aspect of our solution — from point in the user flow to visual representation. In this case, we focused on how our user persona, Devon, was going to search for or find a video walkthrough; and what it would look like for Paddy, our video game walkthrough creator, to edit his walkthrough and make it easily findable on Twitch.
This studio was very helpful in developing our first set of screen iterations, and each of us had input on how the features we were developing — search, tagging and time-stamping — would look in Twitch. Once we had a full set of screen sketches to match our consumer and creator user flows, we developed a series of user scenarios to guide our testing. We met with a range of people — including those both familiar and unfamiliar with video walkthroughs and how to find them — to have them test the screens and give us feedback.
Our key findings from testing our sketches included:
- Adding a “Walkthroughs” button on the homepage to make this new feature more visible;
- Deleting the “advanced edit” button from the time-stamping page (in the upload process) as it was confusing to have it adjacent to the “next” button and unclear as to what a user would find behind “advanced edit”; and
- Moving the “spoiler alert” button from the general video description of the video (in the upload process), to the comment feature attached to an individual timestamp.
Wire-framing and More Testing
We then developed a set of wireframes — first agreeing on what elements we would keep consistent and visual in our wireframes, and then each taking a portion of the screens to wireframe in Sketch. With our wireframes in hand, we again tested the flows, asking testers to pursue the goals of uploading, editing or finding a walkthrough and then we made further iterations based on this feedback.
Prototyping, Tablet & Presentation
At this stage in the process we divided up the remaining work, each taking the lead on various pieces — so that we could keep within our designated timeframe for finishing the project. I worked on the high fidelity website prototype, Lara created the tablet screens, and Alex developed the presentation. As we worked on these pieces, we provided each other with feedback to enhance aspects and meet a high and consistent standard for delivery.
For our presentation, we approached it like a story — taking our audience on a journey through our process and the solution we developed while keeping it lighthearted and engaging.
Our next steps include developing the “advanced video editing” feature in our solution (which will enable gamers to add elements like text and transitions to their video) and suggesting changes to Twitch’s global navigation. Currently Twitch relies heavily on gamers using the site’s “search” functions to find exactly what they are looking for and the key information architecture can be confusing in its structure and use of labels. This is ok if you are a user very familiar with Twitch and its services and less acceptable if you are a new user.
We were proud of our work and learned as a team that it’s vital to:
- Develop and agree upon a strong project summary and project plan that you refer to throughout the process
- Communicate openly so we can ensure we stay on the same page
- Respect and listen to each other’s opinions and ideas — a good idea can become even stronger through collaboration