All the MongoDB
I joined MongoDB's Product Design Team in February of 2017. The Product Design Team is composed of about a dozen designers all dedicated to one or more product at MongoDB. I was assigned to MongoDB University. Since I was their first dedicated digital designer, I was tasked to build the design processes on several products under the MongoDB University umbrella, including their online-learning application and their documentation websites. For this casestudy, I’ll focus on designing MongoDB University’s online-learning application design system and process.
TL;DR? Watch this video tour
MongoDB University & my role
MongoDB has a training arm (like Oracle, Intel, and Cisco). Ours functions a bit more like an online-learning application (like Udacity, Lynda.com, or Coursera). The difference is that MongoDB University offers free online courses with exercises, videos, and labs curated and taught by MongoDB employees. Over 950,000 students enroll in these courses from all over the world to strengthen their knowledge of our technology.
My role as their dedicated Product Designer was to work with stakeholders, product management, and engineers to facilitate user-centered discussions around features, determining the design process, design feedback, and implementation. Being a full-stack designer also means taking on user research as part of the process, so I also helped organize, facilitate, and analyze the user tests.
MongoDB University users
MongoDB University users live all over the globe. Our highest concentration of students outside North America is in Spain, India, and China. But most of them come to MongoDB University because they're:
- trying to learn MongoDB on the side to advance their career.
- interested in becoming MongoDB Professionals.
- learning as part of their company or school training.
- testing the software but are skeptical about the technology.
Regardless of their background or reason for coming, we know that learning a new skill and technology takes commitment, and most of our users are learning on the go. What we want is to get out of the way of their education and provide an intuitive and seamless experience whether it's at their computer or on their commute.
MongoDB University's Challenge
23% of the support questions from a single course involved confusion over the UI
Before I had even touched Sketch, I sat down with the stakeholders and Product Managers. I dove into their concerns with their application and the feedback they were getting from users.
1. Create a scalable design solution.
First, we needed to address how we were going to collaborate. Since I was the only product designer on the team, there was concern that I could potentially be a bottle neck while we had so much to design. Instead of designing one static view after another static view, we decided to focus on building a process and a Design System.
2. Stop frustrating the user.
The highest priority for the team was to update the UI. Users felt the interface was functional but often times confusing. Many would turn to the help desk for instructions on how to complete assignments and quizzes. 23% of the support questions from a single course involved confusion over the UI, and those were just the users frustrated enough to speak up. This made it so users were unable to advance in the courseware or prepare for upcoming homework/exam deadlines. I also conducted user tests and feedback sessions at our user conference.
Our goal for this redesign was to create an intuitive and mobile friendly user experience that would allow users to easily navigate inside the courseware and clearly communicate the course's deadlines, where the resources were, and how to interact with the quizzes, lectures and homework assignments.
From our research and user feedback we were able to understand that our courseware was functional and met the basic expectation of a user trying to watch videos in order to learn about MongoDB. But the learning curve for the software showed in our support ticket queue. The more we tried to fix the application, the harder it became. It was inhibited by all the design debt that built up from ignoring visual hierarchy, responsiveness, and a user flows. In essence, our software was functional but we wanted it to be user-friendly and delightful.
We identified these parts of the UI as the highest priority in elevating the design of our application. We hoped it would address the pain points of our users trying to learn quickly and on the go.
These issues caused the most support cases:
- Finding Resources.
- More screen real estate.
- Homework submissions.
The Design Process
The rhythm we found worked for us
When I first started on the team, they were just getting used to the idea of having a full-time product designer. There were a lot of unknowns and design was an unfamiliar and uncomfortable topic for many of the engineers I worked with. Slowly we found our rhythm as we strengthened our process. After nine months of trial and error, honing pen and paper for wires, Sketch for mockups, Invision for prototyping, and Zeplin for design<->development communication, here's the process we found worked for us:
Based on the information I received from the stakeholders and users, I started building out personas and user journeys. With this documentation and user feedback, we decided to start with the core part of the product first – the lectures, navigating through the chapters of a course, and taking tests within the application.
As I approach each new feature, I assess what design research I need to do. If it's a fairly large and complex problem, I generally start with a Design Studio. (I find this is the best way to understand where the engineers, line-of-business managers, and users are coming from.)
Take that feedback on design solutions and analyze what common UI elements surfaced during our session. I then compare them against our competitors, documenting and screenshoting how they solve similar goals, such as onboarding, completing assignments, and progressing through a course. I do this bit of research to make sure we're complying with a standard UI expectation and not reinventing the wheel.
I then take the sketches from the design studio and my design research and start wireframing with pen and paper. Once I have the wireframes signed off, I go into medium-fidelity mockups in Sketch and I test them using Invision. If they pass all the tests, I go into hi-fidelity mockups and test them again. This is to ensure that there aren't any glaring usability issues.
Once the designs are tested and approved, they move on into Zeplin or a kickoff meeting with the engineers. From there we have demo days or UI tweaking sessions to make sure there isn't anything lost in translation until launch day! Designing and iterating is a never-ending process.
Once it's launched we continuously keep an eye on anything that was a concern and make time to iterate based on feedback from users in our forums. If there are multiple edge cases we didn't anticipate, we categorize and then prioritize the ones that need the most TLC and start the design process over.
I should take a step back for a minute and explain how we managed to explore all these different layouts while not blocking engineering. Before I began exploring designs, I met with the team and we made a game plan. While we were user testing and ironing out the layout with user tests and design research, the engineering team would build out the reusable components (I'll go further into detail on how we determined those components in the next section). To stick with the Atomic analogy, while I was researching which Lego architectures worked the best, the team was building the Lego pieces. So by the time we could come back together, we could assemble the tested usable designs with already defined and built Lego pieces. All without missing a beat.
User Interface Solutions
There were some obvious usability issues off the bat. There were missing hover states and you couldn't differentiate between a Chapter and a lecture link. The more subtle issues were the various areas in which you could navigate. There's the side nav, the courseware's nav, and the Video, Problem, and Text nav, which wasn't always consistent with the lectures.
We made the outline of the Chapter available on the left side rail, allowing for more real estate inside the main content of the lesson. We also made the courseware's nav consistent and available at the top. We also made Chapters selectable with a dropdown, cleaning up the visual hierarchy. When we tested navigation within the courseware, we saw that the users found the left-side nav intuitive and easy to navigate around. They also appreciated the icons offering a high overview of the content.
Lessons and lectures sometimes requires a user to download a zip file or multiple files of handouts, which could include code or data sets. There were some files that applied to the Chapter as a whole, and some files that were only required for the lesson. Users were confused when and where they should download them.
We knew we wanted a central location for the downloads that users could access at any point in the Chapter. We tried several solutions to address this problem. We tried a pull up tab located at the bottom of the nav and A/B tested the label. We tried a toggle state with just an icon. Users would consistently miss that area of the side-nav and were unable to complete the task of finding a list of handouts or download handouts. Ultimately what users ended up liking and using was a toggle state with the label and icon right above the outline. It made sense to put it in an area that users went to for Chapter navigation.
More screen real estate
We wanted users to focus their attention on the video lectures and lecture notes, which users frequently missed. In the original courseware, it was obscured by multiple levels of navigation and a restricted grid system. We decided to open up the grid more by minimizing the height of the nav, rearranged the visual hierarchy of the other navs and made the side-nav collapsible.
There were a lot of complexities to how our team grades problems. First, there were various types of problems such as multiple choice, text submissions, etc. There were also restrictions around the problems such as deadlines, limited number of attempts they were allowed to submit their homework, and whether the user was a paying customer or if they could submit a question over and over until they got it correct. There were well over 15 states that could be accounted for.
When we tested the older UI, many users were confused by whether or not they were able to attempt a problem a certain amount of times. They were also confused by the type of problem they needed to answer. They weren't sure if it was a multiple choice or if they had to choose the best answer.
We did a few things to engage the user everytime they made a submission. We redesigned the prompt so it was apparent what they had to do in order to answer the problem correctly. We also redesigned the button shapes to aid in letting a user know whether it was a checkbox or a radio button. To fix the confusion over how many attempts they had, we added a fun attempts tracker that would animate whenever they got a problem correct or wrong.
Our challenge with a mobile friendly application was that we had a lot of older code that didn't consider responsive designs, very specifically the navigation. All three of the navs would stack on top of each other. The user would have to scroll past the main nav, the courseware nav, and past the course outline. Our reasoning was that most users couldn't complete assignments on their phone. It was a poor experience, so poor that our bounce rate was over 65% on mobile.
When I redesigned the navigation for the application, I did it mobile first. I wanted to make sure that the site navigation was intuitive and didn't obscure anything. So I made the decision to have a tab nav that a user could use to scroll through different parts of the course and a collapsible nav that acted the same way on desktop as it did on mobile.
We established a grid system very early on and defined our vertical rhythm based off of 8px very early on. So we based our grid and responsive designs in multiples of 8px. This took out a lot of the guess work of how anything should breakdown, stack or how padding would work.
Now we have to build it
We identified the issues and edge cases. We researched, conducted user tests and interviews. Discussed how we would solve each problem and mocked it up. It seemed like we were at the end of the journey, but we were just getting started. Now we had to implement it and make sure it fit together. We were, however, still unsure of where to start. Swap out the entire nav and take it onto existing screens? Only update part of the screens? We decided to take the modular approach.
Solving implementation and language barriers
It’s very tempting in a huge redesign, to throw the baby out with the bath water. We didn’t want to do that. Especially since our usability tests showed our software was functional, it just wasn’t very pretty and caused confusion. I thought if we wanted to build a modular user interface, both in our codebase and in our design files, we would want to take the Atomic approach and define all of our components and design patterns. So I looked through all of our screens and designs to see how many variations of things I could find, how many undocumented design patterns snuck into the codebase.
Spacing & Type
There were over a dozen varieties of spacing and error messages, type, buttons were all over the place.
Why was this important to have for University?
- So many undocumented styles so we had to always start from scratch
- Lack of consistency so we weren't establishing any patterns
- A lot of untested and custom CSS
- Design and development were silos and launches were surprises
What were our goals?
- Pick something and stick with it, whether it's px vs. ems or tabs vs. spaces
- Commit to color utilities, layout utilities, typography, spacing, and grid
- Have a single source of truth or at least a shared portal of designs/component, not millions of Sketch files or custom CSS
We started by documenting all of the current components and screens. As explained above, my design process helped me understand the design solutions for the UI. Once the designs had been user tested and confirmed, we took stock again. Patterns and repeatable components became evident and we started our components library there.
Design System Sketch File
The University Design System is always evolving and changing, but you can see the latest changes on MongoDB's Design Systems website.
Pretty soon we were able to organize our Sketch files in a way that made it easy to put a UI together in under 5 minutes.
As each phase of the UI components became more and more complete, I partnered with the UI Engineers to build these components out in our Storybook, a UI component library that runs outside of your app so you test, run, and develop without dependency issues. This further reinforced repeatable design patterns and reusable components.
Not only did this get the developers and designers speaking the same language, it allowed for anyone to come in and peruse our library and reuse our components. It made it much easier to test, iterate, name our classes and organize our files, the eternal struggle of engineering.