UX: Solution Validation - Passkeys
What did we learn?
| Results |
|---|
| Overall, feedback to the proposed passkey management and passkey sign in experience was positive. We learned that passkeys is still unfamiliar to participants, so clear action, helpful descriptions and admin's ability to restrict passkey use for organization is necessary to include. We also learned that having all sign-in authentication options in one page is valuable to users, though additional validation is needed to help users easily navigate to this page. |
| See more detailed insights below or in dovetail. |
Task completion: 4/4 for admins, 3/4 for non admins.
We tested a total of 10 participants (5 with system administrator roles, and 5 with no system admin experience)
| Tasks | Admin | Non admin | All |
|---|---|---|---|
| Navigate to authentication page | 100% | 60% | 80% |
| Set-up 2FA | 80% | 100% | 90% |
| Add passkey | 100% | 100% | 100% |
| Signing in with passkeys | 100% | 100% | 100% |
Navigating to proposed "Authentication" tab is challenging to non admin participants but navigating to existing "account" tab is more intuitive to all participants
The term "authentication" was proposed as a new navigation tab for managing all sign-in options. This term is well understood for those with system admin responsibilities (100% completed the task) but 40% of participants with non admin roles were unable to complete this task. These participants either selected preferences or account or their avatar. To gain higher confidence in navigation recommendation, another test was conducted using existing "account" tab for all sign in options with 100% task completion rate.
There's a clear benefit to having all sign-in options under one page. All participants were able to go through each section with an understanding of how it would impact their authentication experience
Recommendation: Move forward with proposed designs to group all sign-in options under one tab and under Account as a first iteration.
One time password is still the preferred 2FA method because of its ease and familiarity
When prompted to set-up 2FA, only one participant chose passkeys citing it being the most secure. Majority of participants chose one time password because of its perceived ease, security and high level of familiarity. Participants who were challenged with making a decision on which 2FA method to use were more familiar with the specific app or device they were using, eg Google Auth, Authy.
Design improvement: Update description to include commonly used apps or devices to help with user's decision making when managing authentication methods.
Primary authentication is most familiar to participants, passwordless sign in and passkey credentials are less familiar.
| On a scale of 1 to 7, how familiar are you with | Admin | Non admin | All |
|---|---|---|---|
| Passkey credentials | 5.6 | 2.6 | 4.1 |
| Passwordless sign in | 6.6 | 4.6 | 5.6 |
| Primary authentication | 6 | 6 | 6 |
Only 50% of participants specified a device is needed for authenticating with passkeys
When participants were asked about how passkeys would change their sign-in experience, 10/10 participants understood it as "replacing passwords". Only 5/10 participants specified the need for a device, with 1/10 specifying biometric capable device.
Design improvement: Provide additional description in passkey section for device requirement.
Option to use passkeys for both passwordless sign-in and 2FA is confusing to participants
The proposal to give users an option to check how they want to use passkeys: for password replacement or for 2FA is confusing for 2/10 participants, verbatim include how this option "defeats the purpose".
Design improvement: Passkeys are used for passwordless sign-in by default (unless restricted by Admins) and make it clear that passkeys can optionally be used for 2FA.
Restricting passkey use rated of high importance by Admins
Admins noted that having a toggle to restrict passkey use would meet their varying policies and requirements, a few examples highlighted in the test were the preference for passwords over passkeys and using it to enable a global roll out of passkey use.
Recommendation: Ensure functionality is included as must have
Background
We have a proposal to support passwordless authentication out of the box for all users.
What are the goals of the research?
- Collect user feedback on using passkeys as a primary and secondary form of authentication
- Explore the usability content's structure and display
- Understand policy and enforcement requirements by user's administrators for authentication
- Gauge the familiarity of users with passkey, passwordless sign-in
What hypotheses and/or assumptions do you have?
- Participants will complete tasks successfully (success rate at 80%):
- Use passkey as primary sign in (tasks: create a passkey credential for password replacement, sign in with passkeys)
- Use passkey for two-factor sign in (tasks: administrator has restricted passkey for primary sign in and have required 2FA, create a passkey credential for 2FA)
- Admin restricts passkey use for passwordless sign in and requires 2FA for login (tasks: create a passkey credential for 2FA)
- It is a better experience to have all authentication methods under a single tab in User's settings
- Users are not familiar with passkeys and their user for passwordless sign in, therefore we need to include helpful links to help guide users to the benefits of using passkeys to secure their account
What questions are you trying to answer?
- Gain context on how users usually sign in to applications, what requirements and policies are enforced by their employer?
- Can users navigate to the Authentication tab to manage their passkeys?
- Is it clear to users how to enable 2FA and passwordless sign in?
- When looking at all available and registered authentication methods, what detail is most important?
- In looking at available authentication methods, can the user make a confident decision on what they need to enable to secure their account?
What research methodology do you intend to use?
- Unmoderated usability through User Testing
- When setting up a test, avoid leading words
What persona, persona segment, or customer type experiences the problem most acutely?
- Administrators managing user's access and security to their application
- All users logging into GitLab
What business decisions will be made based on this information?
- Can we move forward with the passkey experience?
- Discover usability and experience issues
What, if any, relevant prior research already exists?
-
https://gitlab.com/gitlab-org/ux-research/-/issues/2495+
- Participants in small companies place importance on ease and convenience
- Participants expressed pain points with setting up and managing multiple SSH keys
- Participants rarely used recovery codes and didn’t like they are difficult to find when needed
Who will be leading the research?
- @ipelaez1 (DRI), in collaboration with
- @hsutor - PM
- @beckalippert - PD
What timescales do you have in mind for the research?
Relevant links (problem validation issue, design issue, script, prototype, notes, etc.)
- Design issue
- Problem Validation
- Test plan
- Usertesting
- Usertesting - Navigation / Account test
- Solution Validation - Walkthrough
Checklist
-
Draft goals and objectives, review with collaborators -
Create test plan, review with collaborators -
Build prototypes -
Launch study on usertesting.com -
Analyze and communicate findings -
Close issue 🎉