Design Case Study: MongoDB Cloud Navigation Redesign

Taking on a product redesign is always a lofty, ambitious goal for any company, but fundamentally MongoDB wanted to remedy some pain points we’ve been hearing from our customers and internal users around the hierarchy of our products. Over the past year and a half, we have been working on a redesign of our MongoDB Cloud platform that aims to solve customer problems and give us room to scale in the future when we release new products and features.

Problems

In the previous version of MongoDB Cloud, we had a single sidebar menu with content that would change depending on what level (organization or product) you were currently on. While that worked for a while, we heard from customers as well as from internal users that they were often confused by whether they were on an organization- or project-level page.

We also heard that it was difficult for users to find Stitch or Charts in the Atlas UI and that it was annoying to switch projects once they were in a Charts dashboard or Stitch app. Given these areas of friction, we decided in 2018 that it was time to take a hard look at the information architecture (IA) and navigation of our Cloud products.

Most of the pain points we aimed to fix centered around the hierarchy of organizations, projects, and products.

Motivations & Goals

Our VP of Design, Sean Kelly, often reminds us that the goal of designing products for developers is to “get out of the way” so that we can enable our customers to do what they are here to do: build elegant software using MongoDB. And while we recognize that the MongoDB Cloud platform serves many types of users, for this project we focused primarily on our Full-Stack Developer customer persona. This persona wants a sophisticated data platform and a tool that is easy, convenient, and straightforward to use.

There is also something to be said about having to design for multiple customer personas. In my own experience, this is one of the meatiest problems a designer will face and there is no simple answer for what to do. What we found is that we had to design for the platform as a whole by focusing on a single persona, and then we would focus on the most frequent persona for each of the constituent products: Atlas, Stitch, and Charts.

We had several goals for the first phase of our redesign, including:

  • To enable customers to easily discover all products in the MongoDB Cloud platform: Atlas, Stitch, and Charts
  • To enable customers to easily and quickly switch contexts between Atlas, Charts, and Stitch
  • To establish a product hierarchy that can scale for future product and feature releases
  • To clearly indicate the navigational hierarchy of each page in the platform

Constraints

People often say “Design without constraints is Art,” and I’ve heard it repeated in different ways at conferences, in blog posts, and even on Design Twitter. For this navigation redesign, we were constrained by the existing visual design and design systems of our Cloud products. We were already taking on a huge challenge of redesigning and unifying many different products, and our team didn’t have the bandwidth nor the resources to create a new visual design language and re-launch all of our design components at the same time

In addition, even today some of our components are built on legacy code that is really tough to change. So we had to find fresh ways to use our color palette, shadows, and spacing to make things feel new. Fortunately, our Visual & Brand team was growing and with more people, we were able to create a whole new system of logos and icons for Atlas, Charts, Stitch, Cloud, University, and Cloud Manager.

The redesign would have to take into consideration our future product vision and roadmap. Through close collaboration with our Product, Engineering, Design, and other key stakeholders we evaluated each proposed solution through that lens. We had to prioritize what we believed were the most important improvements to roll out: a new top navigation that clearly represents the hierarchy of organizations, projects, and products within MongoDB Cloud.

Furthermore, the final deliverable needed to be a set of reusable components that could live across the suite of MongoDB services and products. At MongoDB, we rely upon our Design Systems team to develop and ship these components to all of the engineering teams, so the future components from this project would also be used in MongoDB Cloud Manager and MongoDB Ops Manager.

The new navigation utilized a revamped color palette created by our Design Systems team.

Design Process

Combining our MongoDB Cloud products under a single platform has been on designers and product leaders' minds for a long time. It is thus difficult to summarize the full scope of the process that led to this point, or the events that lead to our navigation redesign officially kicking off. Even before I started working at MongoDB and on this project in particular, many other product designers had designed, researched, and tested early concepts for a new navigation for our Cloud products and services.

Concept Testing

In 2018, the Cloud organization was eager to pick the effort back up again. So ambitiously we created two high-fidelity conceptual prototypes of the new navigation and tested them at our MongoDB London event with participants on the conference floor. Looking back, those designs, while grand, gave us answers to initial questions such as:

  • What is easier for users to use, a top-level navigation or a side navigation?
  • What type of navigation gives the user the most context as to where they are in the hierarchy of products?
  • Would users understand that they could switch between products?
  • Did users expect to have to login each time they switched between products?
Early concepts we used to pressure test the idea of a MongoDB Cloud navigation redesign at MongoDB London in 2018

From there we took a step back, realizing that however exciting it is to jump into Sketch and UI design, we needed to understand the priority of use cases in MongoDB Cloud for different customers and our internal stakeholders. We brought in Julie McGehee, a UX Researcher here at MongoDB, to conduct an open card sort with follow-up, in-depth customer interviews, followed by a closed card sort online. From that study, we were able to discover the natural groupings our customers created for MongoDB products and services.

Data Model Ideation

After that study, we shifted gears to focus our energies on all of the new possible data models for this new Cloud navigation. We wanted to understand what the limitations and benefits of one data model would be over another. We projected what the platform would look like after introducing future features to ensure that our data model would scale to our product vision. After multiple rounds of iterations, meeting with stakeholders, and large format print outs from our handy in-house plotter, we landed on a final data model for a new information architecture.

A sampling of some of the hierarchy and data models we created during the design process to align stakeholders on the new MongoDB Cloud navigation system.

UI/UX Workshops and RITE

Once we had a data model, we could return to focusing on the UI and UX. We formed a core group of design stakeholders that were used to collaborate with, brainstorm, and solve nitty-gritty edge case problems with each design. There were many "can I grab you for a moment?" whiteboarding sessions during this phase that looking back were so much fun. I'm very thankful to the amazing, supportive product design team at MongoDB who made themselves irreplaceable resources.

At the low-fidelity level we explored different MongoDB Cloud navigation options and weighed the pros and cons with each of them.

At this point, we were ready to start RITE (Rapid Iterative Testing Evaluation) user research. Pairing with our UX Research team, we created low-fidelity concepts that we tested with one user, captured the findings, iterated on, and then tested with another user, and so forth. This iterative testing method allowed us to quickly capture findings and make changes to the designs while being in constant communication with our customers.

Visual Design

From the low-fidelity prototype, we were finally ready to start the visual design phase. Relying upon the talents across the MongoDB Design team, we held design “jam” sessions and invited product designers to take the low-fidelity concept and make it beautiful. This collaborative approach allowed us to utilize the diversity of the product designers at MongoDB who's strengths span across all skillsets of design.

To nail down the visual design we conducted design “jams” with designers across MongoDB to lean on their visual designs skills for the look and feel of the new MongoDB Cloud navigation.

Task Analysis

Once we had the visual design polished, we were ready for the last research phase: task analysis across MongoDB Atlas, Stitch, and Charts. We asked 28 participants to go through a clickable prototype with 22 tasks and report if they believe they completed each task, how hard they would rate them, and their thoughts around the way. This fine-grained method of testing enabled us to pinpoint areas of the design that were successful and areas that needed further iteration. We then took those learnings and made even more improvements to the final design.

Our task analysis research allowed us to pinpoint areas of the navigation we needed further iteration.

Lessons Learned

Over the course of this past year and a half, we spoke to a total of 101 customers across 5 continents and countless time zones. This effort could not have been done without our wonderful UX Research team and their willingness to take late-night or early morning calls to make sure we were capturing the point of view of our truly global audience.

What we learned throughout our multiple rounds of user research and testing was that nailing a user’s “mental model,” that is, a mapping of a product’s hierarchy in their mind, enables us to roll out new features and products more easily in the future. Once you can set up a clear mental model, customers can better expect and predict what will happen when they go a page deeper into your platform. And after everything, we had a design that met the goals of the project, created a simpler mental model, and was easy to use. It was then ready to be broken down into components by Design Systems and shipped to our customers.

The new MongoDB Cloud navigation allows users to switch between tabs to navigate to Atlas, Stitch, and Charts. Check out the designs on the MongoDB Dribbble!

Conclusion

We are a 1,500+ person company with dozens of teams, working on different projects, in different timezones, that are often on their own release timelines. This navigation redesign required collaboration across Engineering, Design, Product, and Marketing to align on and execute our vision.

I am so very grateful for everyone at MongoDB who worked on this year-and-a-half-long effort. This project would not have come to fruition without their tireless efforts, thoughtfulness, and imagination. We aim to keep improving MongoDB Cloud and continue to listen and learn from our customers, so if you have comments, suggestions, or ideas to further improve this new navigation and hierarchy please feel free to drop them in feedback.mongodb.com, underneath the “UI” section.

Special Thanks To:
Brooke Yalof, Design Systems Engineer
Sean Hanson, Full-Stack Engineer
Michelle Chiu, Product Designer
Diancheng Hu, Product Designer
Dave Hastwell, Product Designer
Jimmy Santill, Product Designer
Rashmi Srinivas, Product Designer
Tan Hsiao, Product Designer
Dan Zhu, Product Designer
Julie McGehee, UX Researcher
Thomas Tran, Design Lead
Andrea Morales, Design Lead
Harry Wolff, Lead Engineer
Sarah Kasch, Design Operations Lead
Kalie Patterson, Lead, Visual & Brand Design
Dan Brown, UX Researcher Lead
Dave McCarter, Design Systems Lead
Ben Cefalo, Director of Product Management
Eliane Kabkab, Director of Product Design
Fred Truman, Director of Product Design
Sean Kelly, VP of Design

Try MongoDB in the Cloud

Create a free account and launch a cluster in minutes!

Start Free
← Previous

Expand Your Horizons with Public/Private Connection Strings for MongoDB Atlas Clusters

MongoDB Atlas now allows customers who use network peering to connect to their clusters more easily with multiple connection strings.

April 22, 2020
Next →

Staff Engineering at MongoDB: Your Path to Making Broad Impact

Andrew Whitaker is a Senior Staff Engineer at MongoDB. His previous experience spans tiny startups to enormous organizations like AWS, where he held several different roles focusing on databases. Before joining MongoDB, he worked at a startup building optimized machine learning models in the cloud. Read on to learn more about why Andrew decided to join MongoDB in a senior-level engineering role and how his work is driving improvement within our engineering organization. Why MongoDB I have long been a fan of MongoDB’s products and services. MongoDB the database has always been a pleasure to work with – the system “brings joy” to quote a phrase. As a Python developer, I appreciate how the Python driver feels “Pythonic” in a completely natural way. The programmer interacts with the database using Python constructs: dictionaries, lists, and primitive types. By contrast, SQL databases force me to change my mental model, and the query language feels like an add-on that does not blend with the core language. As an engineer, I am always looking to expand my knowledge and grow my skills. The scope of challenges engineers face at MongoDB is what triggered my interest in the company. We obviously have people working on core databases and distributed systems. But, we also have teams dedicated to machine learning, streaming data, analytics, networking, developer tooling, drivers, and many more areas. It is very hard to get bored working at MongoDB. Finally, I would be remiss if I did not mention the people. Overall, MongoDB’s engineering culture prioritizes intelligence, low ego, and an ability to get stuff done. CL/CI (Continuous Learning, Continuous Improvement) Working at MongoDB has provided me with opportunities for continued learning and growth. Though I do not program as much as I did earlier in my career, I have recently been exploring the Rust language. I’m excited by Rust because it avoids the tradeoffs between predictable performance and safety. My work in the search space has given me exposure to the fast moving world of AI: vector embeddings, RAG, etc. For various reasons, I think MongoDB is uniquely positioned to do well in this area. On top of this, I’m working on some initiatives that are not fully public. I can say that one focus area is improving the sharding experience for our customers. We believe MongoDB sharding is best-in-breed. Still, the process requires more manual configuration than we think is ideal: customers select the shard key, cluster type, shard count, etc. We give guidance here, but I think we can raise the bar in terms of offering a seamless experience with less “futz”. I’m also working with the search team. We believe there is a natural affinity between MongoDB’s document model and AI/ML workloads. We have some features in the works that extend this integration in new and interesting ways. I also spend a fair bit of time driving quality improvements across our suite of products. Our CTO Jim Scharf frequently refers to our “ big 4 ” goals: security, durability, availability, and performance. These goals are more important than any feature we build. I’ve been working across the company to help teams define their availability SLO/SLAs. It turns out that measuring availability is a subtle topic. For example, a naive approach of counting the percentage of failed requests can underestimate downtime because customers make fewer requests when a service is unavailable. So, the first step is to clarify the definition of availability. Finally, as a lapsed academic (in a distant life, I was a graduate student at the University of Washington Department of Computer Science and Engineering), I’m always interested in finding ways to bridge theory and practice. I’ve been collaborating with some folks in our research team to drive improvements to our replication protocols. There are theoretical results that suggest it is impossible to simultaneously achieve low latency and strong consistency (“linearizability” in the technical jargon). However, we believe there are intermediate points in the consistency/latency spectrum that have not been fully explored. This work hasn't been made into a product yet, but stay tuned. Flexible working MongoDB is a hybrid company. Like many of our engineers, I work outside the company headquarters in New York City (I live in Seattle). I appreciate MongoDB’s approach to hybrid working and that company leadership, starting with Dev , cares about the well-being of their employees. It seems there are companies that don’t seem to trust their employees to make decisions, such as which days to come into the office, so I’m thankful for the autonomy I receive at MongoDB to work in a way that’s best for me. Remote work has its challenges, but I would say that the benefit for my work/life balance has been transformative. Final thoughts I have found MongoDB engineers demonstrate a strong mix of technical depth, pragmatism, and empathy. I have yet to find the “smart jerk” prototype that seems to exist throughout the tech industry. Overall, I have found MongoDB is open to change and growth at both the team level and the individual level. There is a willingness to evolve and improve that aligns with the company’s values and leadership principles and enables the success of our technology and people. Find out more about MongoDB culture and career opportunities by joining our talent community .

November 20, 2024