Formstack ID: SSO
UX/UI Design Case Study
Project Summary
We decided to implement Single Sign On into our Admin Layer so that more customers could utilize the feature. Up until this point, we only had SSO functionality in one of our products (Forms), but we wanted all products to have access. After chatting with customers, searching through previous support tickets, and interviewing our solution engineers, we were able to drastically improve the experience as well.
My Roles
+ Research
+ UX Design
+ UI Design
Main SSO Authentication Screen. The old design is the screen in the back and my new design is the screen in the front.
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.
The two main points of confusion — importing an IP's metadata and adding custom user fields.
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).
New solution for importing a provider's metadata.
New solution for adding custom fields. It's disabled by default to avoid confusion, but once enabled, it's easy to add your custom keys and labels.
Once we were in a good spot, I presented the design updates to the entire organization so that CX, Marketing, and Sales could see what changes were coming. I got a few more pieces of helpful feedback after that and made the final tweaks & changes.
Our dev team has been backed up so I'm still waiting on this project to launch, however we have received a lot of praise internally thus far. Once it's launched, my product manager and I will circle back to do some user testing with users so we can get more ideas on how to iterate and improve it going forward.
Comparison of the old and new ways to add/edit an SSO Authentication Provider (new design is in the front and is the second step of the process — which includes new settings)
