Secure Requests in RememBear

Improving password sharing for freelancers and tech professionals

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.

Speculative personal project—UX design challenge

UX researcher & designer



The Challenge

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:

  • Take into account the dual needs of the two users in the info sharing transaction
  • Meet industry security standards
  • Fit seamlessly into RememBear's simple and playful UI

When your clients and coworkers cannot or will not manage their sensitive info securely, how can you take control?


Research Goals

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?

Subject Matter Expert Interview

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.

User Interviews

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.

Interview Participants
  1. Adam: Graphic & web design, IT
  2. Chris: Graphic & web designer
  3. Leilani: Graphic design intern
  4. Sean: Creative director & multidisciplinary designer
Read Full Interview Report
Key User Stories
Affinity Mapping

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.

Key Insights
  • Personal security habits: All participants take their personal online security seriously, and either use a password manager, or keep sensitive info offline out of a general mistrust of internet-connected products.
  • Client/colleague behavior: All participants experienced working with people whose security habits are poor. Most common themes were emailing/texting passwords, and storing passwords on unencrypted spreadsheets in local or cloud storage.
  • Consequences: Consequences of lax security in participants' professional settings ranged from major security breaches to lost account access.
  • Feelings/desires: Participants feel anxiety in the workplace and frustration toward their clients/colleagues; wish they could encourage safer behavior. Clients/colleagues overwhelmingly value convenience and speed over security.
User Persona

I also synthesized the insights from the interviews into a typical user persona for easy visual reference.

Empathy Map

I then further visualized the insights into an empathy map.

Competitive Analysis

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:, 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.


  • Free to use
  • Easy to use
  • Browser based, no downloads
  • No signup required


  • Open source means little attention is paid to the UI
  • Do not exude a feeling of trust
  • Extra step for the request initiator to add the info manually to their password manager


  • Keep friction on the client/colleague side this minimal, but instill confidence via UI
  • Syncing would remove friction for the request initiator

UX Design Process

Feature Proposal

Armed with extensive insights from the research process, my proposal for the RememBear Secure Requests feature includes:

  • Self-destructing link to a secure form that can be sent to anyone via email or link sharing
  • RememBear user can partially fill info; remainder syncs automatically when client/colleague fulfills request
  • Multi-level security checks and assurances
  • Notifications upon fulfillment of request
  • Easily accessible request status
User Flow

The Secure Request is a 2-user flow. I've used color to indicate where the flow passes between users.

Mid-fidelity Prototype

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 & Iteration

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.

Test Objectives
  1. Rate User 1’s ability to initiate the secure request without difficulty
  2. Rate User 2’s sense of confidence and security upon receiving a request for sensitive information

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.

Usability Testing: Round 1

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:

Usability Testing: Round 2

Based on this tester feedback, the prototype was revised prior to continued testing:

  • Feature name changed from “Secure Drops” to “Secure Requests”
  • Unnecessarily robust and confusing feature tour removed; replaced with a simple popup modal drawing attention to the new feature in the menu
  • Improved Secure Requests landing screen with intuitive and learnable blank state, much more prominent CTA
  • 2 options in the request flow: send email OR generate link
  • Simplified confirmation screen, all CTAs completed in previous steps
  • Push notification + popup modal on request receipt; consistent color relationships on Secure Requests screen

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.

Prototype Iterations
User 1 (RememBear User)

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 (Request Recipient)

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.

Key Takeaways

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.