UX Case Study for a Web Application Login Page
Overview
In autumn 2018 I started redesigning the web application Facility Scanner from Solutiance AG. A new project like this needs to start somewhere. Sometimes it's a first few at a workflow inside the application, sometimes the first overview after a login. Due to the process of user research and requirement gathering not being finished yet, I decided to start the redesign with the login process. This way the product team would have a head start on the application, certain design questions and UI components until more insights were available.
Problem Statement
The login page and process already needs to answer a few questions on how the following application should look and feel:
What layout do you use?
How do you style the form fields and the buttons?
What sign up and sign in channels do you want to support from a business standpoint?
The login process needs to ensure that the user actually uses the application.
Users & Audience
The web application would serve as an interface to display information to our customers, that our internal users and service providers analyzed and prepared. As such the application has to major user groups, that would be forked after login: Our customers and our internal users.
Our Customers:
The product is geared towards businesses managing (their own) buildings and facilities, like facility managers for corporations etc.. Generally these users have used analogue methods to manage their facilities and are looking for a digitalized and edited analysis of their stock to minimize their own work load.
Our Internal Users:
To produce the expected results our internal users sort and evaluate the documentation send by our customers using their specialized expertise on certain topics. Later on I expanded our internal users in more groups depending on their area of work and expertise.
Roles & Responsibilities
I was the UX and UI designer for the application. My main responsibilities were to create a cohesive and understandable design out of the user requirements and to provide the developers with visual, functional and/ or textual input on UI functions, components and presentation. To achieve both I worked closely with the product manager, who would provide me with the user input and requirement, and the developer team. The user requirements were gathered in Confluence and also divided into Jira tickets by the product manager. I used pen and paper as well as Miro for gathering input and structuring content, Figma for low definition wireframing and user flows and in the later process Adobe XD for finalizing the interface design as well as providing the developers with a simple interactive prototype, design assets and design specifications. The finalized designs, design specifications etc. were documented in Confluence again.
Scope & Constraints
Many of the follow-up requirements after the login process were not yet available, when I started working on this project. Additionally the product team wanted to deploy a MVP version as quickly as possible, which lead to cutting a few features and functions. Stylistically the application would need to orient itself on the Corporate Identity of Solutiance AG. This meant using a flat design with minimal frills and whistles letting form follow function. Additionally the application needed to fit into current visual design trends while still maintaining classic functionality and interactive elements our customers were used to from other applications. The architecture of the application would follow the principle of closed of workflows for specific tasks, allowing for modularity when adding more workflows, products or services later on.
My Process
Research
To better understand the rules and constraints of a typical login page and process I researched and read up on the best practices as well as examples on the current web. There is a wide range of login possibilities ranging from logging in with various social media accounts to using two factor authentication.
Results
For an optimal user experience a login page provide a clear understanding where and as who the user is logging in. Additionally security measures depend on the content behind the login: Important, sensitive or confidential information usually needs stronger security then superficial or public content.
The UX community is somewhat split on using social media accounts as a login option: On one hand most social media accounts by definition are a great way to identify a person and serve them relevant content. Using one central point of logging in also means people do not need to remember as many login credentials. On the other hand however you loose security over login information over various platforms and using this method of login is a large invasion of privacy.
Possible login wireframe sections
Interface and interaction components need to be structured. The most common way to do that is for the user to chose their preferred way of identification (or simply inputting it in the form of an email address) and authenticating that identity via a password or similar. If two factor identification is used the user would then be required to fulfil the second authentication method. Additional features for a login page can be the ability to reset authentication methods (eg. password reset) and contacting user support if other problems arise.
Final login wireframe
Knowing our user group and security requirements I chose logging in with an email address for identification and password as one level of security. Through our sales funnels we already acquired the contact email addresses for our customer users. Additionally I found that in our customer base email addresses provided both a name for the specific contact and usually the corporation said contact person worked for, making it easier to identify a person. The level of security provided by logging in with only a password would be enough for now, as long as the necessary security precautions are taken.
User Flows and Wireframes
I created user flows with low definition wireframes. Those flows include the first login after registration, where the user sets their own password, the basic login, resetting the password both via the login page and after login via the user account menu and authenticating the password change after an email notification.
Possible user flow for login functions
After discussing the user flows with the product team we agreed to an MVP of the login process, cutting it down to just the normal login page with some of error feedback, when the login credentials fail.
Minimal user flow for login functions
Outcomes & Results
My main concern when creating the high definition designs for the needed functions was finding the best hierarchy for functionality, visually defining the UI functions such as form fields to help the user understand what they are supposed to do and especially providing feedback when and where errors happen.
Default login page
Page Structure and Layout
The application logo helps the user know where they are logging in, since there is no prior application page or website to explain it. The main focus of this page is naturally the login form.
Form field states
Form Anatomy
The form fields include a label/ placeholder to indicate the type of input supported visually by and icon in the field. The constraints of the field is shown by its bottom border, distancing on field from the other.
Filled form fields with labels/ placeholder displayed
Placeholder and label
However instead of removing the placeholder/ label of a form field after user input I decided to still display the placeholder. This way the user would still keep any necessary information on how to fill the form field.
Feedback message for creating a password
Form Field Error Feedback
The main error feedback necessary for a login page are errors for specific form fields and errors indicating authentication issues after sending the form. Form specific errors need to displayed in relation to their form field, eg. email address not following the correct format. However we can only check for format specific errors on the UI layer.
Error feedback for wrong login credentials
Credential Error Feedback
The authentication, of a user with specific credentials exist in our database can only happen after sending the form and the user needs to receive feedback either by getting forwarded to the application if the check was successful or seeing an error message on the login page if the check was not successful.
Deliverables and Acceptance Criteria
After the designs got approval by the stakeholders I started a styleguide for the components. Since the finalized designs and the styleguide were built in Adobe XD I used the included functions to create an interactive prototype to show the user flow through the login process and the developers could use the included design specifications to work on the components. The links to the online design file could then be added to the Jira tickets for the product manager to add the technical requirements and acceptance criteria.
Adobe XD online view