HPiD

The initial HPiD create/sign-in experience.

Initial Testing

Using analtics data to assess assumptions of what customer pain points were, we developed multiple iterations of potential design solutions. These options were fleshed out into prototpyes of the complete Create experience for each. These prototypes were user tested along with a prototype of the existing experience understand intuitiveness, ease of use, and all around "best" experience, as well as to get feedback about what was not working about the existing experience. This feedback was used to choose a path forward for the redesign. Each prototype featured a particular difference based on a perceived pain point: the first divided the required information in to two screens to reduce cognitive load, the second removed the requirement of the mobile number to reduce the number of inputs, and the third compressed the inputs to reduce user scrolling.

New HPiD experience options for testing as well as the current design.

Findings

Users first navigated through the existing HPiD experience and asked for their impressions. The majority agreed there were too many form fields and too many password requirements. Most users struggled to find the option to sign in with an existing account and had confusion as to whether they could make an account without a mobile number, reluctant to include their number and risk corporate texts or having their information sold.

The feedback from users directed us to our next steps. Users preferred having fewer fields to fill out when creating an account because it allowed them to get through the flow faster. They felt including their name was unnecesary, but liked that their email address (or mobile number) would serve as their username so they would not have to remember additioanl information to sign in.

The first iteration solved many of the problems voiced by the user testers. First, the toggle between "Sign in" and "Create account" was moved to the top so users would not have to scan the page to find their preferred path. Second, the number of fields for the initial Create flow were reduced as much as possible: Mobile phone number and Region were moved to a third page, and the inputs are optional. Region was also autoselected with the user's metadata to reduce the fields the user had to fill out. Finally, the Verify flow was reworked to deprecate the visibility of the verification code input to encourage users to use the button on the email, which is a quicker and more seamless experience. While the Name fields were felt to be unnecessary by users, the Support stakeholders were not swayed by the data and insisted they remain. Due to technical limitations, we were also unable to implemented a single Email address/Mobile number field for the Sign in experience; instead, we added a toggle link in the context of the field so the user would see the ability to change the input. To address the multiplatform issue, the experience was designed on a card that would stay the same size regardless of format. This would keep the experience consitent on web, tablet, mobile devices, and as multiple partners integrate the experience into their applications (which can appear in the app window or within a webview). The background image on desktop and tablet could be customized based on the partner's preferences.

Once this design was implemented, the number of abandond account creations fell by 12% and the number of successful sign ins increased by 15%.

The next step for HPiD was to incorporate new technologies into the experience. We researched mutiple options and decided on One-Time Passcode (OTP) as a first option, with the end goal to integrate Passkeys. I attended the FIDO Alliance Authenticate 2024 conference to speak with designers from other companies and learn about their implementations of new sign in experiences. Back at HP I worked with a UX strategist to develop a plan for multiple user testing sessions that would increment us to the new design, testing flow, different designs, and variations on wording.

For the MVP release of OTP, we added an additional option to the Sign in screen and used added Optimizely to offer two different messages to users to gather data about users' understanding of the phrases. Our concern was if users were unfamiliar with OTP technology they would not use the option, which offers a more easy and efficient experience. The A/b testing was enabled for a month, where 50% of users received "Use one-time passcode" and the other 50% received "Send sign-in code". We received data that guided us to use "Send sign-in code", as users were overall more successful at completing Sign in and Account Recovery flows with the more user-friendly wording.

Users that choose OTP process for Sign in: 33%
Forgot passsword link usage dropped ~18.36% after OTP enabled
Invalid credentials error dropped ~ 13.89 % after OTP enabled
OTP Sign ins
• "Send sign-in code": 53%
• "Use one-time passcode": 47%

The main test aimed to understand what the most optimal integration of the OTP experience within the Create experience would be. I developed two flow options: one that was more of a "Balanced" redesign of the existing flow, and one that was a more aggressive simplification of the options in the flow. I created two live end-to-end prototypes that were shown to 28 users, half seeing "Balanced" first and the other half seeing "Aggressive" first. These tests were moderated walk throughs so we could see and hear the users' feedback and pain points as they went through the flows.