Dropbox:
Shared Link PW Strength
Discovery
We had existing functionality allowing team admins to require passwords on any links shared outside of their team. We were looking
to make an optimization to this experience by allowing admins to require the use of strong passwords. Our assumption was that this had two benefits:
1. Setting guardrails around the password (# or type of characters, case, etc) makes the password harder to guess/hack and better protects the team against data leaks.
2. Making strong passwords a requirement for shared links helps reinforce a team’s perception of their data being secure.
Methodology
The ability to set password requirements for link sharing is a data privacy setting that crosses over both the admin and team member experiences. As such, I needed a view of the current end-to-end flow so I could begin to call out potential pains and work with my PM on further defining acceptance criteria.
The setting starts at the admin level. In admin console, admins can toggle a setting that requires all team members to attach a password to links shared outside the team. If we were going to make it a strong password requirement, we needed to consider whether all passwords would need to meet a standard level of strength (based on industry standards), or if the admin would be allowed to dictate the minimum level of strength based on pre-set “tiers”.
When a team member opens the sharing modal, their top JTBD is to quickly share a link. If the admin required a password, existing behavior allowed a team member to meet this requirement with just a single character. Not the most secure way of protecting company IP. Introducing this strength requirement meant introducing friction, but maybe we could lighten the load by making it as easy as possible to create a password on the spot.
When a team member sets a password on a shared link, how do they go about sharing the password with the intended recipient? What would be the right point in the journey to enable this? Does the password need to be stored for later use?
Competitive auditing gave me a view of how our competitors were tackling this problem and whether there would be any aspects we could tout later as advantages. Because this was a universal pattern, it allowed me to explore outside of competitors, giving me broader awareness of what expected conventions around this feature might look like/how it might work in other products. NNg also proved a useful reference in this case, for awareness of best practices around the password strength pattern.
At minimum, we needed to give the user visibility as to how strong their chosen password is. It would be ideal if we could give general guidance for how to make a weak password stronger so that users are aware of expectations ahead of time. A nice-to-have might be giving dynamic guidance that analyzes what a user has already typed and tells them what to add in order to meet requirements.
Solution & Outcomes
Breaking down each of our user stories, I did design explorations for displaying password strength, strength requirements, and how we might serve up guidance for making a weak password stronger. The final version was put through usability testing and showed clear comprehension of the conditions under which a password would be required, as well as the affordances used to determine password strength.
All participants in the test expressed a need to store the password for later use, though there was variation in how they might carry this out. There was consensus that it needed to be somewhere “separate” but also secure. This gave us signal about potentially integrating with a password manager that was in beta, owned by another team. Having a tested solution in hand, our next steps were to get the project funded by an engineering team and explore growth opportunities with the password manager team.