The Making of Viki Responsive Web
Last November, we launched the Viki redesigned website and made it truly responsive for the first time. In fact, this was the first major web redesign for Viki over the past few years. It was an evolutionary step in improving the user experience as well as internal development processes.
In this post, I thought it’d be a great time to highlight some of the process, experiences and also lessons that we learned along the way.
Contents
- Part 1: Strategy & Goals
• Business goals
• Technology goals
• UX & Design goals - Part 2: UX and Design Process
• Viki design principles
• Identify the problems
• Who is the persona?
• User scenario flows & customer journey mapping
• Information Architecture
• Layouts and UI elements
• Usability Testing
• Prototypes - Part 3: Failures and Lessons
• Users feedback
• Failures and lessons - Part 4: The Results
• Overall performance and results - Part 5: The Team
• The people behind the project - Part 6: Resources
• Reading materials
Part 1: Strategy and Goals
The main goals of the project were broken down into three sections:
- Business Goals
- Technology Goals
- UX & Design Goals
i. Business Goals
Google SEO Ranking
On April 21, 2015, Google announced that they will be punishing sites that are not mobile-friendly. They’ve updated a new SEO ranking system that will basically monitor your site and adjust your site’s search ranking based on whether your site works well on mobile devicecs or not. Some SEO gurus even coined it the “Mobilegeddon”. We actually noticed the site’s search rankings have dropped too.
The Rise of Mobile Traffic
At Viki, 22% of all web sessions on average are from mobile devices. 66% of the mobile traffic comes from organic search. 89% of the mobile traffic lands on these key pages: Homepage, channel page and video page. At the same time, we noticed that these three pages are facing higher bounce rates on mobile. In conclusion, the sheer increase in mobile traffic means that it was time to adopt a responsive design to ensure a quality experience across multiple devices.
ii. Technology Goals
Improve Performance
We wanted to decrease the page load time, to make sure that core content was loading as quickly as possible even on the slowest connections.
Manageable & Scalable Code
Apart from the overall performance, moving towards responsive web design also benefited us in terms of reduced code and increased manageability. Code that is flexible makes our designs easier to adjust during development or prototyping.
iii. UX & Design Goals
Focus on What Matters to Users
This is the basic UX principle — to find out what the user needs. This is part of the ‘discovery phase’ of the project, meaning that we will reach out to the users and gather insights from them (surveys and user testing) before everything else. You will read the details of these process in the later chapter.
Mobile-First = Content First
By focusing on Mobile-First forced us to plan and prioritize content meticulously. At the end of the day, it is the content that is what the users are looking for. Hence, being focused on content will directly lead us to be user-centered.
Clear CTAs (Call-to-actions)
Make clickable elements obvious to the users. From the qualitative research findings, many users failed to identified some of the call to actions on Viki sites.
Improve Discoverability of Shows
UX Design refers to the overall experience that a user gets from using a product. For Viki’s case, we need to make sure that our users are able to discover and watch a show easily.
Similarly, the word ‘discoverability’ can be also referred to as “learnability”. So, from the UX perspective, our tasks are all about improving the clarity and offer less steps for them to achieve their end goals.
Introduce new design language codenamed Moonshine
Apart from user experience, we also used this opportunity to revamp our Viki design language and user interface style guide.
Atomic Design for Scalability
Atomic Design originator Brad Frost defines molecules in UI design as “groups of UI elements functioning together as a unit”. Molecules combine atoms to form components, for instance, a search box or an image with caption. We set out to define some key components which will form the basic building blocks for the Viki responsive website.
Part 2: UX & Design Workflow
Our design principles
- Simplicity Driven
Clear call to actions. Users should always have a clear next step to take. - Research Driven
We use data to inform our design decisions.
There are two underlying principles that inform how we approach the UX and design decisions. Focus on what really matters to the users. Clear call-to-actions, they should always have a clear next step to take and must be able to achieve their goals easily.
Design Workflow Diagram
Who are we designing for?
A persona is a representation of a type of user. At Viki, we have three types of personas: the In & Out, the Active Fan and the Super-Subber. For this particular project, the Primary Persona is the In & Out user. We named her Clara.
What are their main goals?
Primary Research Methods
At Viki, we use different types of research methods, depending on the available budget, project timeline and context:
- Intercept Surveys
- Click Tests
- Remote Usability Testing
- Web Analytic
What is his/her problem or pain point?
We needed to fully understand our users, what their pain points were, and what they did with the product. Hence, talking to the users was the first step during the discovery phase.
From the findings, we’ve identified some key issues:
Scenario flows diagram for ‘In & Out’ users
Customer Journey Mapping for Viki
Arranging the Content
When a user visit a page, they already have specific goals in their mind and they expect to achieve the goals easily. Our job is to make this information as easy as possible to be found and understood. For instance, a basic video page can be broken down to into smaller groups like ‘Video Player’, ‘Video description’ and ‘Episode listings’, etc.
In order to see the hierarchy of information from a bigger picture. We did a few group sketching session using just post-it notes.
“What does the user wants to do on this page?”
“What is the one thing that this page cannot live without?”
What action do you want the users to do?
By focusing on users’ end goals. We were able to identify that both video player and the ‘Play’ CTA Button are the most important information on the page. We do not need research or data to back this. Here, the hierarchy of the information is very clear, Play CTA first then followed by the Player. Logically, both of them should always stick together. If we took the rest of the content away, users still able to watch the show, that’s their end goal.
As for the rest of the information, we re-arranged them based on the number of clicks by referring to Google Analytics (GA). Pictured below here is the completed information hierarchy arrangement for all the screen sizes.
We did the information hierarchy planning for our Container Page as well. Let take a closer look at the picture above. As you can see, the most important information for our Container Page are:
- The Play Now CTA [bright pink post-in]
- Image thumbnail
- Title
- Subtitle % completions
- Total episodes
- Cast list
It is also important to make sure that our content arrangement is in alignment with one of our business strategy goals, which is to get users to spend more time watching shows on Viki. By having clear call-to-actions and better information hierarchy is crucial.
Ideation: Sketch-Storming
After done the information hierarchy arrangement, we proceed to the ideation phase.
Ideation: Iterations and refinements
User Interface Refinements
More Refinements
We always make sure that each round of prototype is designed to solved one particular problem, and once it’s solved, then only we’ll move on to the next stage.
Variations and Iterations
Feedback: Usability Testing (Remote)
Feedback: Click Testing
Click Testing can tell us if the users are able to find what they’re looking for quickly and easily when they view the screens, and if not, where they click instead.
Here are some of the tasks we asked the participants:
- If the CTAs on container page are easily spotted by users?
- If users know where the subtitle language is?
- If users are able to find an episode?
- If users understand what is the episode switch icon for?
- If the ‘follow’ icon is known to users for getting updates on the show?
“Your friend recommended you this new Korean drama to watch and you are now on the page of the drama. Where would you click to start watching the drama?”
“You searched for “I Order You” (Korean drama) on Viki and landed on this page. You have forgotten the number of episode that you last watched and wish to continue now. Where would you click to continue watching?”
“You would like to re-watch episode 7 of this drama because it has the best scenes. Where would you click to watch episode 7?”
“You have watched all the latest episodes of the drama and want to be updated on the upcoming episodes. Where would you click to be updated?”
Complete Invision Prototypes
Bringing designs to life. View our high-fidelity prototype below. The mock-ups are linked, you can explore its journey and main functionality right here.
Scenario: You heard about this KDrama titled, ‘I Order You’ from your friends. You are curious to learn more about the show and perhaps watch it online. You quickly bring up your mobile phone and google the title ‘I order you’…
More Usability Testing
QA (Quality Assurance)
QA testing for selected mobile devices, the goal is to make sure that the pages work before they are released to the world.
Prototypes for both Tablet and Desktop
Click the thumbnails below to view the prototypes in InVision.
Part 3: Failures and lessons
In product design, failure provides invaluable opportunities for us to learn and deepen our understanding for the users. With each round of feedback and iteration, we learned something new. Here are some of our main learning points:
‘Bigger Size Video Player’
In our first release, we optimised the Video Page for better episodes discoverability. Hence, we placed the episode listing card side-by-side with the video player. However, most users were furious over the small sized video player. They prefer to have the video player in bigger size like the version before. At the same time, they do not want to go into 100% fullscreen mode, because they still want to read users’ comments while playing the video. Hence, we iterated the design back to its original size after receiving some backslash from our passionate community.
“The grey/black background was perfect to watch and the size used to be great — I loved how the video used to fill most of the screen and then you could scroll down if necessary.” — User
“I liked the mid-size screen, with the option for full screen. Also the old screen was surrounded in black, which made it easier to watch.” — User
‘Show me the Community Wall!’
Many users, particularly the superfans, complained about the truncated Community Wall. For those who are not familiar about the Community Wall, it is the main place for community managers to do their members recruitment.
When we designed the layout, we did not specifically put these group of users as the priority, because we were mainly designing for the casual users. So, the lessons we learned is that when designing for a solution, do always keep in mind of your primary and the secondary personas!
“I’ve done more than 100 designs for Viki Community Walls and now they’re just like ‘f*** page designers, let’s go with something more like Dramafever’. Great viki…not!”
“I used to like how everything was on one page and totally displayed (now to be able to see the community wall we have to press a button again!)”
‘We need the thumbnails’
Users rely heavily on thumbnail images when looking for specific scenes or episodes to watch. By going minimal with just numbers, they don’t have any cue that can help them when scanning through the episode list. At the end, we killed this minimal design idea and keep the current thumbnail image listing.
Failure of an initial idea doesn’t have to mean failure of the entire project — as long as you take what you’ve learned to inform your next move. — Eric Ries
Part 4: The Results
We monitored a list of metrics like usage data, traffic patterns and web sessions across the board. Ultimately, the measurement should support the business goals that we’ve stated earlier. Here are the results after the launch.
- Overall number of web sessions improved dramatically
- Our site passed Google’s mobile-friendly test
- We created a robust front-end style guide
- Our design and engineering workflow improved
The site is not perfect, and it is something that we will continue to iterate and improve on. Still, it was a pretty great start!
Results: Overall Mobile Web Sessions
Results: Overall Desktop Web Sessions
One of our key KPIs for this project was the number of web sessions. A session is a group of interactions that take place on your website within a given time frame. From the graph below, we saw positive uplifts on Desktop right after the launch. Simply put, users are spending more time to interact on our newly designed pages.
Results: Google’s Mobile-Friendly Test
This is the tool that shows you if Google considers your page mobile friendly or not. If the tool says “no” then the page will be pushed down in the mobile search results in favor of similar pages from other sites that are mobile friendly. As you can see it here, after the launch, Google gave just a ‘thumbs up’ on being mobile friendly.
Results: Google PageSpeed
Results: Post Beta Site surveys results
Results: Robust Front-End Styleguide
After the first release, our dev team compiled and created a CSS style guide specifically for the web. It is a collection of components and elements like action buttons, input fields and card placeholders.
They were all coupled with code snippets for all developers to copy-and-paste as needed to implement those elements for future projects. Big thanks to Aysha for the initiative.
By having this front-end styleguide, the Engineering Team and Design Team were able to:
- Move faster
Having a style guide can greatly speed up the development process. In addition, it allows us to spot where the design breaks. We also get to check how components adapt to different view ports and test for browser compatibility. Developers don’t have to guess what the designers want. - Avoid ‘Design Smell’
The term ‘design smell’ is plain simple — we build everything based on the style guide and not just ‘feelings’.
Part 5: Our Team
A successful collaborative project is only as good as the team behind it. Feel free to get in touch with them!
Part 6: Resources
We referred to a couple of books while working on this project.
- Real-Life Responsive Web Design by Smashing Book
- The Laws of Simplicity by John Maeda
- Creative Confidence by Tom & David Kelley
- The Elements of User Experience by Jesse James Garrett
A reminder
This post isn’t for those who are looking for a clear set of guidelines or best practices for their next project. The goal for this post is to share our learnings, experiences and process with the UX community.
Until today, we are still making small iterations on a regular basis depending on new business goals and the changing needs of our users. So, some of the page layouts in this post may have changed since we launched.
I do hope that you enjoyed reading through this post. 😀
— Teo Choong Ching
