Sign Up in a Mobile Context – Part II
Missed the first part? Read it here.
Problems, Needs and Misconceptions
The first question we should ask is: Should we introduce a signup barrier to our product? Please do not confuse this question with “Should we have a signup process at all?”, as they are completely different points. You should have a signup process because it will allow for the creation of an identity to a user within your system, that will provide you with continuous information about that particular user, which in turn gives you a competitive edge, commercially wise, regarding that user. The signup barrier i ask about can be easily perceived as the additional and intentional step we add to the user’s experience when the signup process occurs. Usually, the signup (and login) process halts the application’s execution and flow which is intrusive and may lead to the users being frustrated and possibly angry (how many of us decided to uninstall an application after our first use of it, simply because we could not be bothered to complete a tedious signup procedure?). So the first commitment we need to uphold is to do our very best about creating our apps experience and make every effort not to compromise.
Although the mobile app development environment has matured over the years we still see problems arising from bad design choices, mainly on the UI and UX front, wrongly focused on desktop orientation. This is reflected on the mobile registration flow stage as well. Most user signup procedures rely on making users fill forms. Forms are a very common and used mechanism in websites that require user input. Theoretically, forms allow the capture of a considerable amount of user data (names, contact information, addresses) in one go, which can be used in several different ways and with many different purposes (targeted marketing, shipping destinations, etc.). However, forms are not suitable in a mobile context. Let’s go over a few problems forms introduce in this context:
- They make users type too much
- Forms are inherently full of text input fields and typing has not quite the same experience on a mobile context. We have a very different experience when typing in a virtual keyboard (in the mobile context) versus typing on a physical keyboard (in a desktop context). This leads to clashes with users expectations / desires:
- Mistake proneness while users expect correct inputs;
- Reduced speed while users want to type fast (here we need to factor time to correct mistakes as well as typing speed);
- Haptic interaction “disability” as users usually use big keyboard keys in order to type but on mobile they are forced to use tiny virtual keys that do not match their fingertips size;
- Typing is perceived as multiple pushes to action buttons (virtual keys) which go against native user experience style which is based around taps and swipes (few action buttons clicks and gestures) [although this has been partially resolved by some soft keyboards allowing swipes to type].
- They contribute to users developing a short tolerance for mistakes
- As stated in the point above, the usage of forms within a mobile context usually means users need to input data on compressed spaces without the precision and comfort of a physical keyboard or a mouse / track pad and this makes it a pain to correct mistakes and moreover it makes the whole process inefficient. This will eventually lead, once again, to user frustration and possibly anger (which is definitely not good!).
- They ask too much information at an inappropriate time
- Forms require the user to input a big chunk of data at once. Should this be the norm? Is it really necessary to ask for all that information at once, especially in a mobile context? Let me provide a simple example: a user opens your app for the first time, attempts to signup and on the signup form you ask for an email address. Is this particular piece of information critical at this stage? Is the app going to send an email to the user immediately after the signup is complete? If not, then this example illustrates a situation where the email address was asked at an inappropriate time (and made the form longer unnecessarily).
- They are restrained and force fragmentation
- Mobile devices have limited size displays, which means that when forms ask for too much information, they introduce the need to be fragmented in order to try and ease their filling and submission. The common solutions encompass the usage of multiple “screens” or tabs which then make the application’s navigation cognitive load bigger and more complex than it should really be.
- They encourage Copy & Paste
- Copy & Paste is a very popular and used operation on desktop applications. However, just as stated above, it can be a pain in a mobile context. It can even be considered unnecessary. Let me provide a simple but common example where forms encourage Copy & Paste usage: a user is asked to input a password for his / hers brand new account. In order to achieve this, the user requires two (usually consecutive) inputs of the password, one on the account password input field and another one on a confirm password input field. This is extremely inefficient and overall unnecessary within a mobile context (although this example has already been mitigated by using the popular two-factor authentication approach, which made more usual for users to input the password in clear text and eliminate the need for double password input).
To be continued in Part III.
Paulo Ribeiro
Hardworking and passionate individual keen on learning and clearing any challenges coming his way.
Working in such a fast paced industry as Application Development, Paulo always aims to try and learn new technologies and new ways to perform his work, either through optimization or efficient process management. He is always open to embrace projects as long as they represent a brand new challenge and learning experience for him.
Latest posts by Paulo Ribeiro (see all)
- Splash Screens – useful or not needed? – Part 2 - 28/07/2017
- Splash Screens – useful or not needed? – Part 1 - 27/06/2017
- “Davos for Geeks” – The Sequel - 03/02/2017
Previous Post
Next Post
