Project Description
Design Task for Pinger. Download the document here: http://bit.ly/pingeruxtask
I will be documenting the specs for data collection during sign up process for a mobile app for Pinger.
This documentation will benefit from the inclusion of wireframes and some UI references, but have been kept to a minimum as they are beyond the scope of the design task.
The wireframes shown below have been designed to be different microinteractions on a single page – separating different parts of the data input so as to not overwhelm the user with too many form fields at once during their onboarding.
Process Flow
The process flow for the onboarding screen of the App is required to collect certain information from the user. The order of data collection is such that wherever possible, we try to leverage system information to pick the most probable value for a particular input. Additionally, it is suggested that we use the device camera to automatically populate most of the data in the form.
The laziest user flow will require a user to only enter their email address and password (in case of iOS only) and take a photo of their country ID.
Android users can benefit from selecting an existing account on their device to use for registration, and avoid having to type anything at all!
01 START: The flow begins with the data collection screen presented to the (new) user.
02 Detect Country: The system detects the user’s country based on the network (internet or cellular) or geolocation (prompt user for permissions as appropriate).
03,04 Successful?-No : If the user is doe not allow access to required permissions, or if there is an error with detecting the user’s locale, then system presents the user with a dropdown selection box to allow them to select their country. User selects their country.
05 Successful? – Yes : If the system is successful in automatically detecting the user’s location country. User still has the option of correcting the selection. System proceeds to next step in the onboarding process.
06 iOS / Android? : At this point, the way the app is coded will dependon whether it is an iOS app, or an Android App. iOS users will directly go to step 09
07 Android: Autodetect email addresses on device using Android Account Picker. Present these as options to the user in a dropdown list, with an extra option for “Other Email Address”. If possible, we should leverage the Google OAuth for the registration here, and skip steps 12,13 for Android users altogether.
08 Existing Email Address or Other Account: This step, the (Android) user is able to select an email address from the drop down list, or select to input another email address.
09 Email Address Input textbox: is displayed to the user
10, 11 Email Address input + validation: The user inputs their email address. System performs basic validation to check for well formed-ness of the email address, and if the email address already exists in the system. If the email address already exists in the system, or if the format is wrong (missing @ symbol, missing domain name, presence of spaces), then the input text box is highlighted in red and an error message is displayed below the text box.
12, 13 Password input and validation: The user enters the password, and this is validated against the password rules. Like with the email address validation, any errors will be indcated by a red border around the input box, and error messages below the text box. For password rules, I will recommend that we enforce only a 6 character minimum for the password strength. “Repeat password” is not used. In case the user does not remember what password they entered, they can initiate password recovery. Making very strict password rules usually hampers usability for a product. I will be more comfortable making a recommendation for stronger rules only once I am better informed about the security considerations in the app.
14 Scan ID / Enter Data Manually : Once the email address and password entry is done, the user is presented with the option to either scan their Country ID to auto-populate information the app needs, or to enter it manually. Since the layout of a Government issued ID is standardized for a country, we can develop an Optical Character Recognition algorithm to read the required information from an photograph that the user takes using their camera, or leverage existing APIs. (Subject to availability of dev resources)
15 Scan: Start Camera : System initializes the camera in a special UI to guide the user about taking the photo of their country ID.
16 Take Photo: User takes photo of their Country ID.
17 Image Recognition: The system reads the required information from specific areas of the image, and converts them to text that is used to populate the data fields. If there are any errors with detection, the user is able to retake the photo after seeing the detected text in step 19
18 Validation: This validation block will sanitize the input from the image recognition engine as well as handle the data input manually by the user in step 19.
Note the validation required for each input:
– First Name, Last Name : should not contain numbers. May contain the apostrophe ( ‘ ) and hyphen ( – ) characters. For country specific localization, this article is a good resource to begin reading. Errors with the validation will be indicated with a red border around the text box.
– Age : This is converted from the date of birth value read from the image, and it’s value may not be less than 13 (or as required by law in the country where this app is deployed.
– Gender : This should map to “Male” or “Female” or “Other”. The use of “Other” may not be culturally acceptable for some countries, so implementation of this option will require some market research.
– Country ID: This has to be of the format of 8 numbers followed by an alphabet, with no spaces no special characters.
20 Submit : Once a user is satisfied with their data entry, they can submit the information and be taken to the next stage.
In Conclusion
This Spec document has been prepared with a few gaps in understanding why the regulatory information is requested, what are the user’s perceptions about being asked for this information, and how do users usually handle their Country ID document. I strongly recommend implementing a system to use the device camera to read the information required from the user, as well as preserve a copy of their Country ID on file, if required by regulators as well. A well planned usability study with a basic prototype will validate all the design decisions made, and will result in better conversion for Pinger.
This documentation will be further enhanced with annotated mockups of the screen and a definition of the interactions on every UI element, which is beyond the scope of the assigned task.
The suggestions I have made for the user flow have been specifically designed so as to not dissuade new customers from signing up. Rather, than overwhelm the users with a lot of form fields all at once, they are presented with low effort data input at first, and then with a high effort data input (Country ID). Even so, this input has been made much easier with the option to scan their ID with their camers.
If the microinteractions involved in this user flow are implemented well, it well get users started with the new Pinger App with minimal friction.
About this Document
This document was created by me for the UX Design task for Pinger in May 2016.
This is the problem statement (property of Pinger Inc.):
You can download this document here: http://bit.ly/pingeruxtask