The Process
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:
- Security Questions
- Pros: Preventative approach, not saving patients personal information, can be saved locally
- Cons: Additional steps during the onboarding process
- SMS
- Pros: No additional steps within the onboarding, easy and seamless experience
- Cons: In the case of nefarious actions, the user already has the device in hand
- Email to recover
- Pros: No additional steps within the onboarding, easy and seamless experience
- Cons: In the case of nefarious actions, the user already has the device in hand which may already have access to email
- Collect Email during onboarding to communicate with patient
- Pros: giving personal data is optional
- Cons: Requires participation for proper security, additional steps in onboarding
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.
Integrating Security Questions
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 setup during Onboarding
- Security Questions set up within Settings
- Passcode recovery
Security Question Guidelines
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
- Easy for an individual to answer confidently
- Not obvious enough for hackers to guess or research
- Not subjective, open to interpretation, or reliant on mood and feeling
- There can clearly be only one answer
- Memorable
- Simple and Definitive
Design Iteration
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.
Higher Fidelity
Using Figma we demoed the current design iteration to the team to get some early feedback. This is what we’ve learned
- During the onboarding process, as a user it could be difficult to understand the need of security questions
- The onboarding flow has a very horizontal flow and the new design introduced a vertical depth that felt disruptive and daunting.
Opt-in Iteration
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.
Continued Research
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:
- Security questions rely on the user to answer the questions truthfully and honestly for it to have a chance to work properly
- 65% of users are likely to forget their password. What we didn’t know is how well that data translated to passcodes
- Security questions as a pattern have largely been replaced with 2 factor authentication. Resulting in the inability to find security questions as a common and modern pattern
- Security Questions was largely used on websites, which allowed the user to read the questions in full. The mobile experience challenged our dropdown approach when we required the user to select a question from within a dropdown.
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.
Design Pivot
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.
Reflection
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.