Designing a better authentication system for Screendoor respondents
Last month, we rethought the way that respondents to our customers’ hosted forms authenticate themselves. Previously, we required respondents to create an account, which adds unnecessary friction. We redesigned the system to deliver all of the benefits of account creation with none of the downsides, taking cues from the “passwordless authentication” movement.
We wanted to give you a look into the problems we identified with our old system, the design process we used to iterate upon user flows, and how we migrated to the new system with minimal impact to our users.
But, first, if you want to try out the new system, check out one of our sample forms to see it in action.
We noticed a few recurring problems with our old authentication system.
Respondents were forced to choose whether or not to create an account to respond, which added unwanted friction. If respondents did choose to create an account, they would be creating the same type of DOBT account our customers log in with, which means they would be taken out of the customer’s branded experience onto a DOBT-branded page. And if they didn’t create an account, they wouldn’t be able to resume submissions in progress unless they remembered to click a link in the form. Furthermore, respondents would often forget which choice they made, returning weeks later only to forget whether they needed to sign in.
Also, we were making our customers choose whether or not to require registration from respondents to a given project. This was a confusing choice in our UI without a clear user benefit.
Once we defined the pain points above, it was pretty easy to figure out our intended outcomes for the solution. Respondents should be able to easily resume submissions in progress without the hassle of creating an account, while staying inside our customers’ branded pages.
We found it helpful to start by coming up with a few design principles, to function as broad acceptance criteria for whether or not a given solution would pass our muster.
Respondents should be able to complete a form as quickly, and with as few steps as possible.
Respondents shouldn’t have to create and remember a password to yet another online service.
Respondents should have easy access to their submissions, while safely assuming that their information will be securely protected.
To meet our design outcomes, we brainstormed a few authentication paradigms, but eventually converged on something similar to existing “passwordless authentication” systems.
We created a few diagrams in flow shorthand to account for all possible states and edge cases.
Once we agreed on a flow, we began the long process of removing the old behavior and coding the new system. Most of the interactions and visual design were already well-established in existing Forms.fm design patterns, but we still refined the copywriting and aesthetics by iterating in code through a Github pull request.
This was one of our largest efforts to date, with thousands of lines of code both added and removed.
How it works
When a respondent starts to fill out a form, they’re asked to provide their name and email address. These fields are at the top of all Screendoor forms, but admins can also customize the fields to display in another location, or with different labels.
Then, we set a session cookie, which tells us the respondent can view their submission until they close their browser window. This ensures that we meet our users’ expectations for privacy – once they close the browser, their information will no longer be accessible, even if they’re on a public computer and a new user goes through the computer’s browser history.
We also set a cookie with a much longer expiration. This cookie doesn’t allow the same level of access, but it tells us who the computer likely belongs to. This is useful because, when a respondent returns to a project after closing their browser, we can show them a “Welcome back” message.
When they click “Resume draft,” we ask them to verify their email address. Then, we send them an email with a “magic link” taking them to their saved draft.
Measuring the results
Like any large change that we make to Screendoor, we defined a key metric that would tell us whether our changes were having the desired effect. For this feature, we decided to track the number of support requests from confused respondents who weren’t how to resume progress on their submissions.
We’re happy to report that this number has decreased significantly. The only remaining support requests we receive are when a respondent does not receive our email with the “magic link,” usually because it’s in their spam folder. (This is a lot easier to remedy than if the respondent doesn’t remember whether they created an account or not!)
We’re confident that this new behavior will make your Forms.fm pages easier to use and more secure, all while ensuring that every aspect of your respondent’s experience is white-labeled with your custom branding. We’re working to improving Screendoor every day for respondents and administrators alike, and we continue to appreciate your business!
Adam Becker is a co-founder of The Department of Better Technology.