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.
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:
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.
From their first interaction with our product, users were met with confusion and questions like:
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.
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:
Often a security requirement at large companies, this feature restricts auth exclusively to SSO, disabling all other methods (eg. email/password)
Configuration made easy — added guard rails to prevent mishaps, helpful setting descriptions, and a unified location for everything
Dedicated path for switching between auth methods, complete with emails for users on how to login with the new method (shown below)
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.
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.
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.