the problem

Our product manages user authentication into apps and other resources. It had always expected these users to be added by an admin or imported from another system. This project was intended to allow customers to configure an enduser registration page.

the process

I started by looking at what things a user would need configure in order to specify how endusers should be registered. This included:

The mess of screens a user would need to visit in order to fully configure this feature.

I noticed that there were a large number of potential dependencies. Many of them required extensive configuration if you had not set them up yet for your instance.

I began exploring possible solutions, and found three basic approaches:

  1. Happy Path: Put in good defaults and hide the depencies/complexity. If a user wants to deviate from the defaults, they have to hunt for the other settings.
  2. Guided Expedition: Walk the user through all the possible dependencies and complexity. A user who doesn't want this will have to opt out of each step they wish to skip, but a user will succeed regardless of their needs.
  3. Mama Bear: Put in good defaults, and include easy ways to get to the other complexity.

the solution

The Guided Expedition added a lot of complexity and would be expensive to build. The Happy Path was pretty limited but would be cheap to build. The Mama Bear would have a bit of both and would also be expensive to build.

In the end, we realized that we didn't have a lot of data on how people would use this. We were going to use the beta to find out more about the types of configurations that would be common. So we started with the cheapest option.

We built the Happy Path first, and we added details from the Mama Bear as we confirmed that a setting was needed and that there was friction with it.

The simplified UI I designed for v1.