Freelance designers and developers, along with tech professionals who work in not-so-tech-savvy organizations, often find themselves in situations where they need access to sensitive information, but the person providing that information does not have a way to transmit it securely. For this UX challenge, I posed and tackled the question: how might we be able put the recipient in control of the security of that transaction? I explored the answer by proposing a new feature to my password manager of choice: the simple and delightful RememBear.
Skip to prototype
Project:
Speculative personal project—UX design challenge
ROLE:
UX researcher & designer
YEAR:
2021
Insecure transmission of sensitive information of course poses major security risks, but countless people are nonetheless reluctant to take the necessary precautions to protect themselves. In work settings, this causes tech professionals a lot of anxiety—whether they are the ones responsible for cleaning up after breaches, or, in the case of freelancers, they are liable for handling clients' information securely. The unique challenge here is that the password manager user needs to modify someone else's behavior to solve their problem. A solution must satisfy the following objectives:
I sought to answer the following questions via SME interview, competitive analysis, and user interviews:
What are the technological and legal considerations of a password request feature?
What are the password sharing habits of people who do NOT use password managers?
What methods currently exist to send information securely without signing up for an app or service?
What are the pain points of working with people who don’t take online security precautions?
My first concern prior to starting the development of this feature was if a password request is even legally viable, or if there might be too big a risk that it could be abused by phishing scammers.
I contacted Eliot, a developer currently working on a password manager app, to clarify the legal and technical considerations of this feature. His response:
Generally, as long as you're not trying to trick someone into giving information to you (either by saying it'll be used for something else or by pretending to be someone you're not), you should be in the clear. From a technical perspective as well, there's ways to allow for only the person who gave the password in the first place and the receiving party to see the information. For example, there's no ability for us as employees to look into our database and figure out what someone's password is. There's a bunch of math that goes into the encryption that prevents us from doing something like that. I'd expect a tool that works in the way you describe to work in a similar way."
With this expert’s sign-off, I was prepared to call the proposed feature viable.
The target demographic for this research is users who use password managers for professional pursuits but may work with people who don’t—namely freelance designers and developers, and those with tech roles in non-tech focused organizations. I recruited and interviewed 4 such professionals, and summarized their key stories. I also added my personal insights from my extensive history as a freelance designer.
I found that taking an affinity mapping approach to categorizing the interview insights was an excellent way to bring some clarity to the differing needs and pains between the password manager user side and the colleague/client side.
I also synthesized the insights from the interviews into a typical user persona for easy visual reference.
I then further visualized the insights into an empathy map.
Since secure receipt of a password or other sensitive information from a third party is not, according to my research, currently a readily available feature in competing password managers, I see the unusual competitor in this process as a genre of simple, mostly open source websites that generate self-destructing links for sharing any type of “secret” you wish. Examples include: 1ty.me, BriefLink, One Time Secret, and PrivateBin. All serve the same purpose and function the same way. User research suggests that one common workaround is to suggest that clients/colleagues use a site like this to send sensitive information.
Strengths
Weaknesses
Opportunities
Armed with extensive insights from the research process, my proposal for the RememBear Secure Requests feature includes:
The Secure Request is a 2-user flow. I've used color to indicate where the flow passes between users.
Using mid-fidelity wireframes based on RememBear's existing UI, I created a prototype of the feature proposal. The initial prototype, naming the feature “Secure Drops,” included a robust new feature tour and one request method (link generation) based on the hypothesis that these would optimize usability.
Testing was comprised of two user flows, each with one simple task. User 1 (the RememBear user) was tasked with sending a secure request to a client. User 2 (the client) was tasked with completing the request once received.
Testing was conducted with 5 professional digital designers in the 20-40 age range. All participants had experienced clients sending them sensitive information, such as login credentials, via insecure means (email, text message, etc). Some participants were password manager users, some were not.
Although multiple rounds of testing were not planned, it became immediately obvious after two testers that significant revisions to the prototype were needed. Following is a summary of each participant and the main pain points of the task:
Based on this tester feedback, the prototype was revised prior to continued testing:
Additionally, the test moderator’s introductory script was revised to provide more background on the product and a more clearly defined scenario for the task. This allowed testers unfamiliar with password managers to perform the task with a clearer understanding of their goal, while still lending their valuable beginners’ insight to the testing process.
The impact of the changes to the prototype was immediately noticeable with the remaining three testers.
With some final tweaks made after the second round of testing, the Secure Requests feature became much more intuitive to the User 1 flow testers.
User 2’s flow was very simple: receive request (via text or email), consent to knowing the sender, and fill a simple form. Testing was conducted primarily to gauge the testers’ feelings of confidence and security toward the request.
Initial result and problem: Although there was no hesitation or difficulty once the request link was opened, testers expressed that they would feel reluctant to click the link that was texted to them. The initial prototype relied entirely on User 1 to provide context and make their client feel confident and secure.
Solution and implemented fix: Append header text that would appear along with the link when copied or emailed, with a RememBear-branded “signature” for added confidence.
This UX design challenge was a rigorous exercise in setting aside my own biases and instead relying on insights gained through talking to people to make design decisions. As a RememBear user myself, many of my assumptions were not intuitive to those looking at it with fresh eyes. While existing RememBear users may have navigated the first iteration with no issue, the feedback I received by including more diverse perspectives unquestionably led to a superior user experience.