FOSSA — Product Design

Reimagining Authentication

September 2020 – March 2021

When I first joined FOSSA, it was early days — the company itself was still very much in “startup-mode” and focused on honing in the core value offering for a handful of customers.

By 2020, we were maturing and starting to acquire more large enterprise customers (companies with 100+ users, often 5k+). These new customers were obviously very critical to our growth, but from the moment they began rolling out FOSSA internally they were blocked by a number of difficulties with entry into our product (authenticating, getting into their org, etc). Simply put, it was time to upgrade the “front door” of FOSSA.

Process

Initial insight

From a series of internal interviews, I gathered that our support team was being flooded by entry-related tickets each week and spending a substantial amount of time manually resolving the same issues over and over (often requiring the assistance of the engineering team). Overall, this was hurting us threefold:

  • Eating up a significant amount of internal bandwidth
  • Limiting the speed at which new customers could start getting value
  • Harming the first impressions of our product

After some time reviewing support tickets, speaking with customers that had gone through the rollout process, and mapping the user journey a few underlying problems were clear.

Login/sign up was death by 1000 paper cuts

From their first interaction with our product, users were met with confusion and questions like:

  • “Why are there two different sign up pages? Am I logging in or signing up here?”
  • “Should I enter my email or company? Which input are these buttons connected to?”
  • “Does it matter which email or auth method I use to sign up? Can I use my Google account to sign in if I originally signed up via email/password?”
Old login/sign up flows
Old login/sign up flows

Updating our welcome mat

I recognized that this was a well established feature – not an area where we wanted to differentiate ourselves. Our users wanted something familiar and seamless so that they could jump into our product and start getting value. With this in mind, I leaned on industry best practices and design patterns to improve this part of the experience.

Updated login/sign up flows
Updated login/sign up flows

Authenticating into the correct org was incredibly difficult (especially at scale)

  • Org admins could hardly operate at scale: SSO support was problematic, and if you weren’t using it, inviting users required manually entering each email address by hand
  • Highly error-prone: manual assistance was often required because an account was created without entering their org’s subdomain (ie. didn’t join org) or the incorrect auth method was used to sign in (ie. created duplicate account)
  • Confusing setup UX: if you didn’t have an invite, you were forced to go through the daunting org setup experience (shown below)
Old org setup flow
Old org setup flow

Improved Single Sign-On (SSO) Support

Enterprise customers wanted to use this powerful method for auth, but our implementation was limited — it lacked basic security features and was extremely hard to configure (especially if you needed to switch over from a different auth method). We fixed this with the following:

SSO-only Option
SSO-only Option

Often a security requirement at large companies, this feature restricts auth exclusively to SSO, disabling all other methods (eg. email/password)

Auth settings redesign
Auth settings redesign

Configuration made easy — added guard rails to prevent mishaps, helpful setting descriptions, and a unified location for everything

Migration support
Migration support

Dedicated path for switching between auth methods, complete with emails for users on how to login with the new method (shown below)

Migration support made it easy for large enterprises to start using SSO
Migration support made it easy for large enterprises to start using SSO

Intelligent Redirection

With this feature, users are automatically redirected to authenticate with SSO if their email address matched a “claimed” domain. This resolved almost all of our issues related to users joining the wrong org or creating duplicate accounts.

Deprecated Org Setup Flow

We removed this flow altogether — it was an enormous burden placed on all new users, adding unnecessary friction before they could start using the product. Admins that needed to configure these settings could do so after creating their account.

Solution

[object Object]
Sign up (live version)
[object Object]
Sign in (live version)
Authentication settings
Authentication settings
System emails: New email templates for claiming a domain and auth method migration were added, and all system emails got a fresh coat of paint
System emails: New email templates for claiming a domain and auth method migration were added, and all system emails got a fresh coat of paint

Closing

The launch of the new experience was a success: feedback from our users was almost universally positive and related support tickets dropped to nearly zero. The functionality continues to shine as FOSSA grows and is now used by over 50k users each month.

Going forward, we planned on exploring ways to improve all the steps between initial usage and first realizing value — making them more educational, user-friendly, and streamlined.