Designing a Sign Up flow: how hard could it be?
|
|
Every web app has a way for users to sign up and create an account. You’ve probably signed up to many yourself!
You could be forgiven for thinking that it’s an easy feature to code and design… just ask for an email and a password, and let people in.
Unfortunately, it’s not that simple. Designing a good Sign Up flow for a web app requires finding a delicate balance between usability and security, with a sprinkle of marketing on top. 😊
In this newsletter, I’ll share with you the wireframe we created to build the Sign Up flow for Balsamiq Cloud. We hope it will be useful to you if you have or are planning on building a web app, or if you just want to see how we use Balsamiq ourselves.
|
|
Here’s the complete wireframe for our Sign Up flow:
|
|
Pretty scary, huh? Don’t worry, we’ll go through it screen by screen.
One thing you can notice right away is that we have two main flows: one for username and password (with 5 steps), and another for Google authentication (with just 3 steps).
They both start with the landing page.
|
|
The landing page: make it frictionless!
|
|
There are many resources online that can help you design the perfect landing page for your web app, so I will only focus on the Sign Up section.
Here you have two options: create a dedicated Sign Up page, or make the Sign Up happen inside the landing page.
A dedicated page might look cleaner and might be easier to code, but it’s also an additional page for users to find, wait for while it loads, and learn how to use when they get to it. Also, a dedicated Sign Up page will probably lack some of the context that the landing page provides.
For these reasons, we suggest having the Sign Up form live inside the landing page. In fact, we do the same for the Log In form as well!
Now, there are different ways to have those forms on the landing page. Here’s how you might think of doing it first:
|
|
|
Clearly, that’s a terrible UI: it’s a wall of form fields which is both confusing and intimidating.
Is this really the first impression you want to give your potential customers? 😊
Let me show you an alternative:
|
|
|
That’s it! 😊
Here are some of the tricks used on this design:
- The Log In and Sign Up features are visually very different – one is a link, the other is a form. This makes sure people won’t confuse the two.
- The Log In link is in the top-right, where people expect it to be, and it’s far away from the sign up form. Again, this reduces the chance that people will confuse the two features.
- Most importantly, it moves the two scary-looking Log In and Sign Up forms to a second step, keeping the landing page nice and clean.
Together they make quite a difference, don’t you think?
Let’s proceed.
|
|
The classic: username and password authentication
|
|
Let’s start with the most common authentication method: username and password.
You’ve already asked the user for their email on the landing page, now it’s time to ask them a little more info.
Once your prospect clicks on Start Trial on the landing page, this dialog pops up:
|
|
There are a lot of micro-interactions here that are worth exploring:
- Every field shows the little red * which means this field is required.
- The Email address field is pre-populated with what they already typed – no need to make them type it again! It also gives them context, it’s something that ties the previous screen with this one.
- There’s no separate Username field: the email is unique and descriptive enough to be used as the main unique identifier for each user.
- The focus is automatically set to the Full Name field, which is the first field they’ll have to fill in. This lets users start typing, without having to use the mouse to click on the right field.
- The TAB key lets people navigate between the different form fields – good for accessibility, and to help your power-users sign up quickly.
- Having a single Full Name field instead of separate First and Last name fields is more inclusive… there are large parts of the world that don’t use first and last names. In Balsamiq Cloud we require both right now because Stripe requires them… but we plan on improving this in the future.
- There’s only one password field. Forcing people to confirm the password is annoying, and it’s not necessary. Instead, give users the option to show the password in clear, with a little eye icon toggle inside the password field. If they mistype the password, they can always reset it easily – assuming you design that flow well, of course. 😉
- There is a password security policy, but it’s a very simple one: a minimum of 8 characters. That’s easy to understand, easy to comply with, and provides plenty of security on its own. Asking for anything more complex increases security moderately, but increases user frustration massively. 😊
- Once the user types 8 or more characters, the at least 8 characters text turns green, to give them some feedback that they passed this small test, and can move on.
- If the user tabs or clicks away from the password field without entering a valid password, the border of the text field turns red, to show an error.
- Last but not least, you have to show the standard Privacy Policy and Terms of Service checkbox. The links should open in new browser tabs, so that they don’t interrupt the Sign Up flow.
- There is a Continue button, that stays disabled until all the fields are filled in correctly.
- There is also a Resend Verification Email link, in case they never got the email and want to try again. This is a good spot to hide this link, because this is where they entered their email address in the first place, so they should be able to find it again while they scramble to try and complete the Sign Up process.
|
|
OK so they filled in the small form, and clicked Continue.
Unfortunately, you can’t just create their user account now and let them in. You have to make sure they can receive your emails. This is critical, because that’s how they’ll be able to reset their password if they need to, and how you’ll send them important communications about their account.
In the past, several web apps would let users in while the email got confirmed, but it’s confusing – you have to add the concept of unverified user, which makes everything harder. It also has security implications: I could sign up with your email address, and thus prevent you from doing so in the future!
Instead, most web apps now make confirming the email an integral part of the Sign Up flow, like this:
|
|
That’s it: not a lot of text. It shows the email address so that they can confirm it is spelled correctly, and just tells them to go check their email to continue the process.
|
|
A quick aside: the Resend Verification Email dialog
|
|
Here’s what it looks like:
|
|
Nice and simple: you pre-fill the email with what they typed before, you put focus on the Email field, and when they confirm you show them the email address, and give them an easy way to contact support in case they’re stuck.
|
|
Back to the main flow: time to check email!
|
|
First of all, you need to make sure your back-end system ensures a very high level of deliverability and speed for transactional emails. This is much easier said than done, so we rely on Postmark for this.
|
|
Let’s look at the anatomy of this email message:
- It comes from Product Name <support@yourdomain> – no hostile no-reply crap! Make it easier for people to reply to it, and for your support team to help them!
- It includes your product logo and name – this ties the email to the landing page, it makes it feel part of the same flow.
- It has short text and a clear call-to-action button.
- It shows the verify URL both as a button and as a link. This is useful for old email clients, or if people need to copy/paste the link instead of clicking (it happens more than you’d think).
- In the footer, it tells people what your product does and how to contact support. This is mostly useful if someone receives this email by accident, but it also provides some context, and shows that you’re approachable and happy to support them.
|
|
Almost there: confirm with a login
|
|
Once the user clicks on the Verify Account button or link, they're almost done!
Again, you can’t just create their account quite yet, it’s not secure. Instead, show them a login screen like this one:
|
|
A few things to notice:
- The title says Please Log In to Complete Email Verification, which ties the login to the email they just clicked on.
- The Email address has focus, but it’s not pre-filled this time. It’s more secure this way, and plus what you’re really doing is training your users on how to log in! You’re showing them a form they’ll have to use again in the future, so the more it looks like the standard Log In form, the better.
- There is space in the form for errors: the classic one is Wrong email or password. Please try again. which intentionally doesn’t tell them which of the two fields was wrong. It’s a bit annoying as a user, but it prevents information from leaking to potential hackers.
- Another error to handle here is when someone tries too many passwords quickly. It could be a hacker or a very frustrated user. In this case, the right message is something like Too many attempts, please contact support@yourdomain – which both stops them from trying again, and shows you’re happy to help them via email.
- As usual, the button is disabled until the form fields are filled in correctly.
Once they log in correctly, you can finally create their user account in your database, and let them in!
|
|
I know, SO MANY CASES TO THINK ABOUT!!!! Argh!!!! 😊
Alright, let’s look at the other flow.
|
|
The shortcut: Google authentication
|
|
Using Google authentication makes the process much much simpler, both for you and for the user.
Why? Because Google already verified their email address when they first signed up with Google! You don’t need to do that, we can just rely on Google doing it for you.
Look at how easy the flow becomes. On the landing page, the user clicks on Sign Up quickly with Google authentication and is taken to the standard Google OAuth screen:
|
|
Note: this is a Google screen, you don’t have to code it! 😊
With one click they can choose their account, and Google will send your web app their full name and email address… just like that!
Notice how Google’s screen also links to your Privacy Policy and Terms of Service. This is very handy, but since we’re fanatical about privacy, we don’t think that’s enough of a notification, so we add this step at this point:
|
|
This helps us really make sure the user has read and agreed to our terms – or at least they said they did by clicking on the required checkbox.
It only takes 2 clicks, and the new user is in!
|
|
So smooth… OAuth is a bit of a pain to code, but when it works, it’s such a smooth experience for users.
We only offer Google authentication because many of our customers use it. Talk to your customers to see which one they want. We’re also adding Single-Sign On SAML authentication to Balsamiq Cloud, because some of our enterprise customers are asking for it. It’s a pretty smooth process as well!
That’s it. I hope this overview of the Sign Up flow of Balsamiq Cloud was useful to you.
Because you’re part of our inner circle, we want to share with you the source file of the wireframe above. You can find it on WireframesToGo or get it directly from inside Balsamiq Wireframes (just search for Sign Up Flow).
We’d love to get your feedback on it before sharing it more widely. Are there any screens we forgot? Do you do anything differently? Reply to this email and let us know!
|
|
Product news
|
 |
|
|
In case you missed some recent updates, we wrote a summary of what we shipped in Q1 this year.
At the moment, we’re working on A LOT of different product-related projects: features, chores, and bug fixes. We finally have the bandwidth to address some long-requested features, so we’re really excited. 😊We can’t wait to share more details with you in the next few months.
|
|
Wireframing Academy news
|
 |
|
|
Some highlights from this past month:
- We re-recorded our popular Udemy course – Getting Started with Balsamiq Wireframes – to show the latest Balsamiq Cloud version, and put the whole course on YouTube, so you can watch it without signing in/up for anything.
- We are working on a series of articles about how copywriters use wireframes to craft their written messages within the context of the UI. Our first step was to re-publish an article from a few years ago called Bridging the Gap Between Content and Design With Wireframes. Stay tuned for some in-depth articles from experts in the field.
- We need just a few more participants to wrap up our User Research study. To help us learn how to create better material for our Wireframing Academy site, please complete this survey. It’s quick!
|
|
Our company is a product in itself, which needs constant evolution and improvement, so we continue to work on how we work together.
Right now we’re working on defining what we mean when we talk about different leadership roles. It’s an intense but important process! 😊
We had a wonderful virtual retreat, filled with fun activities. We'll tell you more about it in a future post.
I am guest-hosting the Bootstrapped.fm podcast for a few weeks! I’m having a great time, but it’s a ton of work! 😊
Sponsorships and raffles: this month we sponsored the Women in Tech World Series Online Fest, UX Fest, Design at Scale, and many more!
Notable recipients of our Free Software Program:
- MITRE Engenuity: a tech foundation that brings industry together to apply state of the art cybersecurity innovation for the public good.
- RadioSiamsa: an all volunteer radio playing Irish folk music. Delightful!
- Doctors without Borders: We’re longtime supporters of MSF, but now we’re helping them with their Operational Center Brussels Intranet, too!
|
|
That's it for this month!
|
|
Before we go, one more question: would you be interested in another newsletter in the future dissecting the Log In flow of a typical web app? Shockingly, it can be about 10 times more complex than signing up!!!! 😬
See you next month, with more behind-the-scenes news from your friends at Balsamiq!
|
|
 |
Peldi for the Balsamiq Team |
|
|
|
|
|
