What constitutes a simple sign up page on a Web App?
snowpal.com: Your end users will spend about a second or two on your public sign up & sign in pages, yet they need to be designed to be simple and reflective of your secure pages.
“Genius is making complex ideas simple, not making simple ideas complex.” - Albert Einstein
A sign up page is not complex so this quote may not necessarily be applicable to it. However, we’ve seen one too many public pages that ask for a few too many things before a user can sign up, and there are others that look like they were built in the last century.
So, as “unimportant” as this page might be from a Unique Selling Proposition standpoint, they are the first points of interaction for your potential or existing customers so you need to ensure that they are both simple and reflective of your product (read: unique enough).
What you see below is Nth iteration of our Sign Up (and Sign In) page on snowpal.com.
Sections
1. Download Apps from the App and Play Stores
We offer Native Mobile Apps, and one of the first things we would like for our users to do is download the apps. So, we positioned the App buttons at the top, left corner so they are not missed.
2. Social Media Sign In
We started out by supporting Facebook Sign In, and when we launched our Mobile Apps, we learned we had to support Apple as well (if you support *any* social media sign in on an iPhone App, you have to support Apple Sign In as well). So, we switched our priorities a bit and implemented Apple Sign In on mobile (and therefore, on the Web as well).
While I do not know the exact user base of Facebook compared to Gmail, we see a disproportionately higher number of sign ups via Google compared to Facebook. We had a feeling this would be the case and therefore, added supported for Google Sign In (in hindsight, we should’ve done this as the very first item).
Last but not least, we also added support for Microsoft Sign In because, why not, right?
3. Email/Password Sign In
Well, when business users sign up, they prefer to use a pretty standard mechanism and so, this method ought to be available (given that we do not yet have SSO support with Identity Management systems like Active Directory — not yet).
4. Preventing bot sign ups
This turned out to be quite an issue and while I am unable to divulge what all we did to eliminate, or mitigate, this issue, it should suffice to say that we had to do more than one thing to control bot sign ups. When you implement such a page, do not forget to deal with this potential (almost guaranteed) issue.
There’s more to this page but you get the idea.
For instance, we also have API and Education buttons because our business has many products, and we take the opportunity to socialize our other products with users who land on this page.
What this means is that even though every app has a sign up page, it still takes a tiny bit of thinking before you arrive at a page that’s a reflection of your product. It is iterative so if you do not get it right on your first or second tries, do not fret. You will get feedback from real users soon enough and can make necessary adjustments (so long as your Security Architecture is flexible enough).
Snowpal Products
Backends as Services on AWS Marketplace
Mobile Apps on App Store and Play Store
Web App
Education Platform for Learners and Course Creators