Formstack ID: SSO

We are moving more admin-type settings, like billing, account and profile settings, user management, etc to our platform-level admin layer.Because we had already moved user management over, we'd have to also move SSO over as some of our larger customers use SSO to create/edit users. Unfortunately, we couldn't move over all of our supported identity providers from the get-go. So we looked at which provider was most popular among our users — SAML — and we started there.

Since we were moving an existing feature to a new location, I wanted to use this opportunity to really improve the experience as a whole. I didn't have the time to do many user interviews, so I went through our support channel in Slack and searched "SSO" and "Single Sign On" to see where customers were getting confused or what they were frustrated with. I also spoke with our Solutions Engineer who was most familiar with this feature to get his insights since he dealt with SSO customers on a regular basis.

Two issues jumped out right away. The first was that customers were consistently getting confused by the metadata import process. They thought they had to provide a URL as well as a file, others weren't sure if they had either of those and didn't know if they could add the information manually. Another common pain point was around adding custom fields. The inputs appeared to be required, so users thought they needed to add information there, however those inputs are only required if you have custom fields you'd like to add. Take a look at the old layout below then keep reading to see how we solved these problems.

Once my Product Manager and I had a good list of improvements, we laid them all out in a spreadsheet and took those ideas to our dev team to see what was possible and how long certain ideas would take. Once we all combed through the spreadsheet, we had finalized on what improvements would be included in the initial scope and what would get pushed out for a later phase.

As usual, I started with a few different basic layouts just to get some initial concepts together. I constantly shared my designs with the other Product Designers as well as the developers on my team.

This project was another lesson in why constant communication and feedback is important. My initial designs had broken the steps out into different screens as I was trying to keep everything as simple as possible for the user without overwhelming them. However, after talking with one of the developers, he called out a technical challenge with the way I had it organized. After discussing it in more detail, we landed on a better approach.

As I got more into the nitty gritty, I talked with more engineers and got more feedback, constantly iterating on the designs.

One other thing that I had to continue thinking about was making sure this new experience would scale when we added more providers in the future. They all tend to require different information and they even call some of the same information by different names. It was important to keep all this in mind when designing.

Below you'll see the solutions to the two main points of confusion from earlier. Rather than show all the ways you could import your provider's metadata, I opted for a tabbed approach so it was clear how a user was to enter this information (with the added "manual" approach so users knew they could do it themselves if they wanted. As for the custom fields, I decided to disable that by default since it only applies to one of our products and most users don't need to add those fields. By disabling it, we removed the unnecessary confusion around whether or not it was required (you can see them in context with the rest of the redesign at the very bottom of the page).