Single Sign-On for MongoDB
Business Goal
This is the first step towards MongoDB’s Cloud Unification. By tackling unifying the core functions of our product: login, sign-up, user profile, and update password flows we’ll be beginning to introduce to our users the idea that MongoDB is one single platform. And in turn, we will be making it easier for them to do those basic core actions without having to remember their information for each MongoDB property.
Objective
Single sign-on will allow users of MongoDB products to be able to login to Cloud, Support, and Education with only 1 set of credentials and login prompt.
Priorities
Login flow
Sign-up flow
User account/profile page
Update password flow
Forgot password flow
Roles
Lead Product Designer
UX Researcher
Team
Product Manager
Tech Lead
Lead Engineer
Program Manager
Timeline
Design: 4 Months
Technical Implementation: 8 Months
UX Goals
Users can log into Cloud, JIRA, Support, or Education with SSO.
Users can easily switch between platforms without being forced to login again.
Users not prompted to log in to any of the other platforms until their session times out, or they manually sign out.
Migrate all Cloud users to a single authentication system.
User Stories
As a user, I can sign-up for MongoDB Cloud, University, and Support through mongodb.com.
As a user, I can log in to MongoDB Cloud, University, and Support with the same email address and password.
As a user, I can reset my password for MongoDB Cloud, University, and Support.
As a user, I view a single user profile for MongoDB Cloud, University, and Support.
Constraints
The engineering stakeholders conducted an early investigation and evaluation for which identity provider would be best to use to handle the SSO and Authentication. The decision was to use Okta as the identity provider.
Okta provides a Okta’s login widget that can be customized to suit your needs. I worked with the Lead Engineer to dive into the documentation to understand the depth of customization we could achieve.
We needed to make sure that Enterprise users can log in through their own IdP, so we would need to account for a separate redirect to an external IdP
User Information Collection: Audit
For this project we were aiming to unify 3+ different platforms that all had different signup and login forms and experiences. Before even jumping into designs I conducted an audit of the existing form’s to understand and identify the differences between the data collection each platform conducted. I used this diagram to drive conversations between the stakeholders on Cloud, Support, and University around what we could/couldn’t include in the unified forms. Each platform would need to continue to capture that information in their own way and through conversations and ideation sessions with stakeholders, we were able to devise a plan to account for these platform-specific user settings in their platform.
Wireframes
Taking all the information from the information audit, I started sketching out the user flows and forms we would need to maintain the information we captured during login and registration. The team met regularly, in team design reviews, lead by myself and held almost weekly I walked the Tech Lead, Product Manager, Lead Engineers, and other team members through the user flows. Their feedback allowed me to discover more scenarios, edge cases, and legacy flows we’d need to support.
Past projects have taught me that user flows and engineering architecture maps are akin to one another, serving different purposes but communicating a similar message: the user experience. So for these low fidelity user flow diagrams I included information around when our identity provider, Okta, would be making API calls to capture user information, redirects, or metadata. This information shared to the team allowed all of us to clearly understand what user flows we’d need to account for and give engineering a starting point to jump into code.
User Testing
With every project its vital to user test the designs and ensure that the flows, UI, and overall experience is easy-to-use, intuitive, and delightful.
We were planning to introduce multiple new concepts to uses: a single MongoDB Account, a single login page to access multiple products, a unified Account app, and a global user menu to allow users to SSO into another platform. And through user testing, we wanted to understand if users understood these new features, that the features were intuitive to use, and if there were ways to make the experience even easier.
Using the RITE method, I quickly tested and iterated upon the designs over the course of a 2 week period. Each user offered insightful qualitative data that validated the overall user experience and the set of features we were planning to rollout.
Round 1
Date: March 1, 2018
Number of Users: 5
Method: remote, usability
Round 2
Date: March 7, 2018
Number of Users: 5
Method: remote, usability
Solutions
Login & Sign-Up
For the unified login and registrations pages, we decided on creating a single URL for all platforms, MongoDB Cloud, MongoDB University, MongoDB Support, and eventually more to point to for sign-in and login, account.mongodb.com.
Registration Form, completed
Account
The MongoDB Account app single application contains all shared user-centric account information, and can scale to accommodate more in the future. It acts as a jumping off point for users to discover all that there MongoDB Account can give them access to.
Looking Back
This project was the first opportunity to make a huge impact on a piece of the first-interaction a user has with MongoDB. It involved numerous business, product, and engineering stokeholds across 6 different teams within MongoDB. What I learned on this project was the importance and challenge of cross-department communication. We relied on stakeholders and engineers in different departments to execute along parallel timelines to make our launch date. Now looking back, I realized that there were opportunities that I could have taken to better document and share out information related to the design process. This can come in many forms: Wiki pages, weekly emails, slack channels, etc, and all would have had different pros and cons to keeping all the stakeholders informed.
Moving forward I aim to always help document, distribute, and share the design process with more people within the organization.
Forward-Looking Goals
Looking towards the future, we’re aiming that this product and experience help grow the cross-platform adoption of MongoDB’s suites of products. We’re already in the works on improvements to some of the shared elements we first introduced in this project. Through more user testing, feedback from internal employees, and implementation we’ve discovered ways to improve the functionality and look/feel of some of the common components we introduced in Single Sign-On.