Building A Better User Experience

How helping users through their intended workflow pays off

By now you must be familiar with the experience of going to a bad website. You show up, just trying to order a pizza, and suddenly you’ve gone down the rabbit hole and are asking, “OMG, what is happening?”. Now, I’m a proficient user of the internet. I will edit the HTML of a website just to get around a bad user experience; and yet, I still give up trying to use all sorts of websites every day. It’s hard for me to even imagine how difficult and confusing some basic internet tasks must be for people who aren’t very comfortable with a computer.

Let’s talk about Cyril

My small product team works on the research site JSTOR and conducts fairly regular user interviews in order to better understand how the public perceives our site — part of the never ending quest to build the best product possible. Cyril was one of the users who I was lucky enough to observe using our site.

Cyril’s task was fairly simple: he was to go to www.jstor.org, create a new account, and then interact with a new feature we hadn’t yet released to the public. We wanted to learn what he thought of it and how well he understood the messages that we were trying to convey.

Cyril didn’t make it to the new feature, however. Instead, we witnessed Cyril struggle to create an account on our website for over 10 minutes. What was supposed to be an interview about a new product turned into a fascinating preview of the real struggles that some users face every day. It’s important that we don’t downplay Cyril’s experience or try to write him off as an edge case. The JSTOR registration page has a 40% conversion rate, meaning that there are thousands of people who leave that page every day without making an account.

The user is not to blame for a webpage they don’t understand—we are.

A better registration form

Instead of letting users like Cyril struggle to make an account, we decided to help them along the path. We observed that Cyril lost time (and a little bit of faith) each time he would complete and submit the form, only to find errors returned at the end of the process. So we changed it. Now, when a user navigates to our registration page, we provide fairly intelligent feedback to them as they are filling out their information. If they don’t make any mistakes, they will hardly notice a thing. However, if the user types in two email addresses that don’t match, they will see a little red box appear underneath the input telling them what the problem is so they can fix it immediately.

Since we added this client side validation for every required input on our registration page, we have seen registration conversions improve by about 12%, which is a large number in absolute terms when you’re talking about a website with millions of users.

Successful registrations on jstor.org increased by 12% with the release of client side form validation

In our agile environment, we know that this isn’t the the end of our improvements to the registration form. We are still actively playing with workflows on getting people to the form, the design of the form, the length of the form, and more. Anonymous metrics collection on the registration page show us how often specific fields are not properly filled out, and we will use that data to plan our next improvement.

Building this feature has been a great experience for me. Part of what makes our team—and our organization—so great is our use of data to make informed decisions. Each step that we take to improve our user experience has the opportunity to improve real people’s everyday use of JSTOR.