Usability and interface design through sign up forms.
My Experience with SendGrid's Sign Up
I work in ecommerce design and development, and we recently started looking for a new email campaign provider. SendGrid looked like a great solution because we can integrate it right in with our data, plus since we don't need the WYSIWIG editing you get with more full-featured providers, it's a lot cheaper than the previous solution.
Unfortunately the sign up process isn't as nice as the service provided. I had some trouble with getting registered, and I wanted to make some notes here on how the process could be improved.
View the screencast below to see an explanation of my original problem, and then I'll go over some suggestions afterwards.
Screencast of Sign Up Problem
The Big Problem
After choosing a plan in a very conventional SAAS layout, you're directed to a registration form. While the length is a bit of a usability concern, the showstopper is the first two input fields.
SendGrid starts by asking for 'Username (in email format)'. Seems like it would be clearer just to ask for an email address, but ok, moving on. Next, enter 'Email'. Ok, now I'm confused. You're asking for two emails? What is the purpose of each one? There are no helpful tips on the page to explain what's going on.
I decided that, regardless of what they wanted (since I couldn't figure it out anyway), I had one email address that I wanted to use, and I entered that. After submitting the form, I'm returned to it with an 'Invalid Email' error.
Live chat was spectacularly unhelpful (another whole story) in figuring this out. I ended up deciding they must have an unstated restriction the two emails being unique, so reluctantly used my personal gmail account as the second one.
I couldn't use my employee's main email account as the 'Username' even though that was my first choice, because I didn't know which one they would be contacting me with and I don't have direct access to that account. This ended up getting me to the next screen, though I've since tried again with a single email used twice with no problem.
The big problem is that users have no idea why there are two different emails requested, and how they're going to be used. As it turns out, the Username email is for logging in and is used in setting up your use of the service via STMP (so if at any point you decide to change the address you log in with, you have to change your application code - not good). The second is used only to contact you, say for confirming the email address or for account alerts.
Further Usability Concerns
While I'm at it, there are several other ways to improve this sign up process though none nearly as important as the issue above. I started by making notes on this page with BounceApp.com.
Suggestions for Improvement
Here's the current two-step sign up process.
There's a lot I could say, but in the interest of keeping this page somewhat reasonable in length, here are my list of goals for reworking, and then the end result.
- Solve the 'two emails?' question. Ideally, remove the request for two. At a minimum, add explanatory text.
- Make each input request work hard to justify itself.
- Clarify the process and goal to the user.
This is what I came up with:
The new design only asks for what is necessary. One email address, to be used for log in and customer contact. The SMTP account email will be set up after registration is complete. Same with website, address, phone, etc. None of that is needed to get the account started. Even a billing address for credit card processing is most likely not required (check with processor) - we're not worrying about fraud with SAAS like you would with ecommerce.
I also addressed many of my smaller concerns brought up in the Bounce page earlier like process indication, information about the plan you've selected, and other tweaks to the page overall. I think this makes the form both clearer and less intimidating.
One of the problems with usability analysis from the outside is I can make assumptions, but I don't really know the requirements of the business. So I made an alternative version keeping more of the data inputs that still improves on the experience.
By dividing the form into sections and adding some clearer labeling and help text, we can shorten the form and make it clearer. The dual email addresses still don't make a lot of sense, but at least you understand what they're each for.
Finally
There are still plenty more ideas I could cover. The plan selection page could use some work (I have a nifty slider preview idea), and there are lots of improvements post-register you could do. The site markup makes me shudder. However, fixing the sign up form is now their biggest bang-for-the-buck. I hope this might help show some of the problems from an outside perspective.
SendGrid seems to have a great product - now they just need to make their sign up process match (and maybe work on that customer service issue).
Feedback? Talk to me on Twitter @vonlein.
John Lein, 08 January 2011