Road to recovery with forgotton passcodes
Lumedic Connect allows the patient to securely download their digital health records by connecting them with their healthcare provider using blockchain technology. To further the patients security, Lumedic does not store their personal information on a server that connects them back to their healthcare provider.
Product Owner, Engineers, Product Designers
Passcodes are used to protect the patients digital healthcare records on Lumedic Connect. If the user chooses to, they can also enable biometric security (FaceID or Fingerprint). In the scenario that a patient does forget their passcode and opted out of biometric security, the problem they encountered would require them to reinstall the app, connect with their healthcare provider, and redownload their digital health records. This problem has a significant impact on anyone who happens to forget their passcode and offers them zero guidance on recovery.
For this project I have been design pairing with another designer. We facilitated a ideation workshop with the product owner and engineers, generated user flows, wireframes, prototypes, high fidelity deliverables, and behavioral specification documentation.
Ideation workshop, user flows, wireframes, prototypes, high fidelity deliverables, behavioral specification documentation
We began an exploration exercise focused on approaches and opportunities to support the patient in need when recovering from a forgotten passcode. During this exploration we aimed to avoid requiring the patient to reinstall the app. Our restrictions in the exploration is that Lumedic does not want to (at the time) save users information on a server. An option we eliminated early was login credentials as an option.
During our workshop with the product owner, engineers, and technical product manager we provided a framework in Miro to explore ideas with pros/cons, dependencies/assumptions, and open questions. These are the areas we discussed:
After the discussion as a collective we decided to further explore the Security Questions approach because the users answers can be saved locally on the device and did not require any backend support.
To put the user in the best position in the scenario they are prone to forgetting their passcode, we wanted to prompt them with a security question setup early. The app has been used in pilot programs, which meant that we also had existing users to consider.
We identified 3 main design areas
Security questions cannot just be any question to ask. We needed to create a framework to reference when creating strong questions that give the user the most security. Security questions are not a new pattern and there are plenty of online resources that we pulled from to create our own framework.
Security question rules
We went with option #1 with the hypothesis that asking for a security and providing an answer within the same screen would allow the user to review previously selected questions and answers and remove the sense of transitioning between too many screens. This approach also aligned with common security question patterns.
Using Figma we demoed the current design iteration to the team to get some early feedback. This is what we’ve learned
Based on our feedback, we introduced an opt-in screen that explains the benefit of security questions and allows the user to opt out without diving deeper into the flow. The security question and answer experience was updated to have one question/answer per screen. This would require the user to encounter 4 collective screens in comparison to the original 1.
During the design process, we entertained the idea of security questions while also researching best practices and examples of security questions through a mobile experience. What learned is:
During another demo with the engineer and product owner we shared our learnings about the usage of security questions. The engineering team expressed concern with the dropdown being a custom component that would require additional time and support in the long term. When discussing the amount of work needed to implement this design, the question of how many of our users are encountering this particular problem has arisen. Unfortunately we didn’t have any data on our current users that encountered this problem, and if the amount of work matched the need.
During this discussion we came to the conclusion that the core problem is that the user needs guidance in the scenario that they’ve forgotten their passcode. Currently they are stranded with no course of action. We then scaled down our approach to provide the user a link to our FAQ with steps to recover. This simple approach allowed us to begin tracking users who navigated to the FAQ and that would give us more insight into how often users are encountering forgotten passcodes. During the information gathering, the team can review the onboarding experience as a whole, decide if the work needed for a security question is the right approach or pivot to two-factor authentication that is most common in a mobile experience.
At a glance, this project felt that it regressed to something overly simple and not fully supporting the user when they forget their passcode. The journey and exploration taught me a lot about how security questions are not as secure as you may expect due to how users treat and act on a security question flow. Which is why most products approach a two factor authentication. It allows the product to communicate with a user and allow them to recover quickly without the need to recall an answer to a security question saved in the past.
The value in this project was the successful pivot before the design made its way to the engineering team. It required a few conversations with the team to explain that the cons of security questions outweighed the value to the user in the long run.