Our client was a well-known technology company who is mostly known for their multi-platform video game engine.
The client wanted to revamp “Learn”, their e-learning website. My team and I developed two different platforms: the Learn 2.0 website where users ("learners") consume content and the Content Management System (CMS) that Content Creators use to upload tutorials.
1. My role:
UX Designer: During the first three weeks of the project, a Senior UX designer and I, worked together to kick-off the project. After that, I took full (UX) responsibility of the project.
Project duration: 5 months.
What I did: Customer Journey Maps, User Story Mapping, Ideation sessions, Whiteboarding, Wireframing, Site map, User flows, Prototyping and User testing.
2. Beginning: The project’s brief, customer's journey and the User Story Mapping
The client had drafted a product brief which included the overall goals of the project:
To increase user adoption of their software by making it easier to learn how to use their engine.
To make Learn 2.0 “the place” to go when looking for learning material about the engine.
To improve the client’s employees current experience with the Learn CMS.
To design a CMS that can be used by the client’s employees and, eventually, by any user interested in creating learning content.
The final goal was clear, and the client had a high-level idea of how to achieve this, we just needed to fill some gaps before moving into design. Our client's team provided us with personas that they had previously created, and we used them to have a Customer Journey Map (CJM) session; this allowed us to better understand the current experience of their users and their vision of the new website. We met with the project’s main stakeholders: the product owner, the head of design and the learning architect. Once we completed the CJM, we had another session to create a User Story Map (USM) with enough granularity to define an MVP.
The stakeholders of the project were located in different offices across the United States while me and my team were in Mexico, so we conducted the exercise remotely using Mural's platform; I took turns with my fellow UXer facilitating the workshop and taking notes. Here's the Customer Journey Map which later allowed us to create the USM:
We did this same exercise for the "Content Creator" persona. With the USM complete, we brought in the developers and discussed with the client what should be part of the MVP considering our resources and technical constraints.
3. Getting into it:
Ideation sessions & Whiteboarding
Powerful ideas come from many individuals collaborating. We invited our project manager and developers to an ideation session. I selected the parts of the project that I considered more challenging or essential and created “How Might We” questions. For instance, "How might we show users learning content they are enrolled to and their progress?". For each question, we did a “Crazy 8”. After that, we gave participants 5 minutes to work on the idea they liked the most. By the end of the exercise, we had between 4 and 6 proposals for each of the most challenging features. Finally, we had a discussion about the favorite solutions.
Based on the personas, USM and proposals from the ideation sessions, I had whiteboarding sessions with another UXer to explore and discuss components, hierarchy and the layout for the most important pages. I then proceeded to create the wireframes for the Learn 2.0's website.
Crazy 8 result sample
4. Learn 2.0 Website: the learner experience.
The website consists of 6 sections: Homepage, Search page, Tutorial Content, Project Info, Track Info and User Dashboard. Users can access to three types of content: tutorials, projects and tracks (projects are a curation of tutorials, tracks are curations of tutorials and projects). Users can also track their progress and save content to watch later. I'll talk about the Tutorial page to give you an idea about why and how we took certain design decisions.
The Tutorial content page
If you look at most e-learning platforms, they are video-based, this means they have a consistent layout throughout all tutorials. In Learn's case, tutorials may consist of one single video, a wall of text, images or all of them (that depends on the creator) so we needed a layout that worked for all cases. For instance, Content Creators can attach files for users to download. On other sites, these materials are just below the video tutorial, but in our case, if we have a very long tutorial, materials will get pushed down and get hidden. We couldn't have the files in the header either, as it would be too cluttered. Ultimately, we added a left bar for files and documentation. This way downloadable files won't get lost in the content and users can access them from the beginning, when they are needed. We took advantage of this menu an added the tutorial's outline so users can easily move between sections.
The tutorial's layout is divided in four sections:
The header, for basic information about the tutorial.
The left menu for files, details and the tutorial's outline.
The content section, for text, media and code snippets.
The footer, for related tutorials and navigation buttons, assuming the tutorial is part of a project or track.
Tutorial page wireframe
After I completed the website's screens, I moved on into the the CMS wireframes.
5. Learn 2.0 CMS, the Content Creators experience.
The content creator’s screens were easier to design. As opposed to the learners’ site, we had constant and direct contact with target users: the client’s employees.
There are four main sections in the CMS: the Content Creators dashboard, the Authoring tool (or Tutorial creation tool), the Curation tool for projects and the Curation tools for tracks. When users log in as Content Creators, they have a dashboard where they can manage their content. From there, they can also go to the authoring tool to create new tutorials. Let me show a little of how that works.
The Authoring tool
My first idea was to design a "What you see is what you get" editor. I created a draft and showed it to the development team. While attractive, we didn't have time to implement this option, we needed something simpler. The final result is a form divided in three sections: general info, steps (the content) and details and materials.
Even if the editor isn't a WYSIWYG, users are still able to know how their content is going to look before publishing. In a ribbon, at the top of the editor, I added a preview button just next to the save and publish buttons. The ribbon is sticky, so users can save and preview at any moment, and also to communicate that these buttons were universal, meaning they affected the whole tutorial.
Authoring tool wireframe
While I worked on the wireframes, one of our UI designers started working on the style guide for the project. The client's head of design wanted a minimalistic and clean style, close to Google’s Material Design. Our UI designer created hi-fidelity proposals for the Learner's website and, once the client approved the proposal, she created a symbol’s library. I used this library to create the rest of the mockups. The client pushed really hard for mockups, so testing came later than we were aiming for, but it was finally time.
The client wanted their team to conduct the usability tests at their offices, so I prepared the script and included instructions on how to set the testing environment, how to introduce the participants to the test, and how to interact with them. I had a meeting with the client’s head of design and their Product Owner to explain the script and the reasoning behind the tasks and instructions. I also inquired about questions they needed to include that were related to their business objectives and not necessarily usability.We mainly wanted to test the following:
Wording and structure: Did users understand what tutorials, projects and tracks were?
Discovery: Were users able to find content based on topics they were interested in?
Navigation: Were users able to move between tutorials inside a project or track?
Progression: Were users able to identify which items inside a track had they completed?
Testing showed us that we were on the right track but there were still things we could improve. For instance:
1. The learner’s dashboard was hard to find.
Users could only access this page through the avatar’s dropdown. The test showed that this wasn’t working so we added the dashboard to the top navigation menu.
2. “Continue learning”.
Users could continue tutorials they hadn’t finished by selecting them from their dashboard. However, most users expected to be able to do this also from the homepage. This feature was out of the MVP scope, but it was recorded as a priority feature for the project’s second phase.
All interviews were video-recorded and shared with us. I created a document with the insights and proposed solutions for each issue and prioritized those who were critical for the MVP. The rest was recorded so they could be addressed in the future.
7. Mockups and final results
Thanks to the usability testing, we know learners can easily navigate the platform, consume its content and track their learning progress. On the Content Creators side, users can create tutorials with all type of content, curate projects and tracks. The UI is user-friendly and is designed for users with previous experience as well as for new ones. In terms of usability we accomplished our goals. As for business goals, the platform hasn’t been launched yet, this means we will have to wait before we can see data about how Learn 2.0 is doing out there, in the real world.
Here's a glimpse of how the final screens looked:
Learner's website - Prototype with hi-fi assets
8. Challenges and learnings
Meetings and design decisions must be documented, always. This was a long project (5 months) so it was normal for the team to forget why we had taken a specific decision. Sometimes, the client challenged design decisions that had been made days or weeks before, hindering the team’s progress. Agreements and design decisions where done during meetings but many were just said, not written down. I started sending meeting notes and created a record of agreements, so we all were on the same page and, if we were not, to clarify any misunderstandings. This improved communication and sped up future discussions.
Some design decisions that the client didn’t approve during the wireframing phase, were brought back after usability testing. I realized two things:
Communicating the reasoning behind your designs is as important as crafting them.
We did usability testing too late in the project, had we done it before, we could have included these features from the beginning.