Stop registration from being your web app's largest barrier to entry
By Darian Moody 03 Aug 2011.
0 comments
Here at the theTeam we've recently been working on a few internal projects/web-apps designed to further aid in the companies everyday activities; whenever possible we like to create tools that will help us with process & workflow - it helps keep us more organised and our projects on-track which is very important in the world of a busy creative agency.
One problem any company will face when creating internal tools is uptake - as in, actually getting the intended audience to use them. There are many ways to solve a problem such as this; just touching the surface would include training, usability & design of the application. However, this article will be focusing on removing 'barriers to entry' by 1) decreasing the effort involved in any given registration process and 2) utilising existing data and infrastructure to perhaps forgo the need for a registration process at all.
Reducing your apps' largest barrier to entry: registration.
If you absolutely cannot do away with registration then the barrier to entry can still be lowered by simply reducing the effort involved in signing up. Nobody, and I really do mean that in the global sense, wants to see a form with 20 fields to fill in just before they can even utilise the function or feature that the web app had already promised. Alfredo has already touched upon the benefits of being a lazy developer and I strongly believe applying that mindset to being a user works wonders for fostering activity, conversions, community, etc.
So what can you do? A short list:
- Try and implement a way for users to utilise your site with the majority of features without having to register; this can lead to up-selling the opportunity with extra features once they have already started using the site. This also works for e-commerce checkouts, ask the user to create an account *after* the checkout/payment process; by that stage you should already have all their details and account creation is merely a click away rather than a big wall a user has to jump over before getting to the till. You end up with the same result but with a much higher conversion rate.
- Reduce your required (and displayed!) registration fields to an absolute minimum. Even if none of your 20 fields are required, their mere existence will still scare off many a user. I'm talking email, password and perhaps username here; a bare minimum, you can ask the rest later.
- Pre-fill registration forms with sensible defaults or known data. A half filled out form is better than an empty one.
- Kill multi-page registration processes unless absolutely necessary. If they are required, give a good estimation as to how long they'll take and what stage the user is at throughout the entire process.
- Reduce the amount of copy surrounding your registration procedure. Sure text is informative, but in this context large chunks of it can be seen to have an off-putting effect. Do you ever read that EULA/T&C text? No..? You're no different to 99% of people wanting to use your registation form.
- Validate in-line. Don't wait until the user submits the form to tell them that the username they chose is already taken - by that stage their password fields would have been cleared causing extra time and frustration as they desperately hope their next choice is free so they don't have to do it all over again. Make your forms for an impatient world because that's how the web is.
So, that being said, what did we do?
Utilising existing infrastructure
Before we started a recent internal project which would require registration to use, we sat down and drilled out the minimum information needed so that they could register an account and use the tool. On looking at the data, we quickly realised it was no different that the standard data you provide on joining the company and therefore if we already had already taken that data at some stage, why on earth were we asking for it again?
After a quick conversation with our IT department, we realised that this was indeed the case and all the data was already held within the group's Microsoft Active Directory system which utilises LDAP for single sign-on throughout the company. After implementing LDAP sign-on within our application we just reduced what would have been a 5 minute registration process into a simple login with email & password; provided the user has already set up an account with IT, they are ready to go.
and.... how?
Integrating Django with Microsoft's Active Directory
Luckily, due to the abundance of 3rd party modules/packages in the Django & Python ecosphere, integrating with our parent group's LDAP server was a relatively painless process. django-auth-ldap is a custom authentication back-end for Django written by Peter Sagerson which simply plugs in on top of Django's shipped authentication back-end and provides a rich set of settings and method designed to make integrating your Django project as easy as possible. It's built on top of python-ldap and therefore the OpenLDAP libraries.
If you'd like to read more about the technical details and exactly how we managed it then you can get a more in depth article at my site here: Getting Django going with Active Directory's LDAPS.
Photo credit to tompagenet.
