Idea 143 Seamless Login (#144)

This commit is contained in:
Chad Jackson 2018-04-09 10:24:29 +02:00 committed by GitHub
parent 5f434e5e06
commit 46aea998e0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 76 additions and 4 deletions

View File

@ -32,6 +32,7 @@ aborted.
## Draft :seedling: and limbo :question:
| Idea | State | Success metrics? | Exit criteria? | Clear roles? | Future iteration? |
|---------------------------------------------------------------------|---------------------------|------------------------|------------------------|------------------------|-----------------------------------|
| [134-seamless-login](ideas/134-seamless-login.md) | :seedling: Draft | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes |
| [117-message-ordering](ideas/117-message-ordering.md) | :seedling: Draft | :white_check_mark: Yes | :white_check_mark: Yes | :x: No | :x: No |
| [99-confidence](ideas/99-confidence.md) | :seedling: Draft | :x: no | :x: no | :x: no | :x: no |
| [95-les-service-model](ideas/095-les-service-model/) | :seedling: Draft | :x: no | :x: no | :x: no | :x: no |
@ -59,15 +60,16 @@ progress again. This ensures the registry is kept up to date.
|---------------|--------|
| @anna | 58, 80, 87 |
| @adriacidre | 63 |
| @andmironov | 68, 80 |
| @andmironov | 68, 80, 134 |
| @adambabik | 58, 63, 68, 92 |
| @asemiankevich | 87 |
| @alwx | 134 |
| @asemiankevich | 87, 134 |
| @cammellos | 87 |
| @chadyj | 68, 80, 87 |
| @chadyj | 68, 80, 87, 99, 134 |
| @dshulyak | 63, 92 |
| @feuGeneA | 83 |
| @flexsurfer | 34, 80 |
| @hester | 80 |
| @hester | 80, 134 |
| @janherich | 87 |
| @jeluard | 68 |
| @lukaszfryc | 68, 83 |

View File

@ -0,0 +1,70 @@
## Preamble
Idea: 132
Title: Seamless Login
Status: Draft
Created: 2018-05-04
## Summary
When a user opens Status or taps on a push notification they should be able to start using the app quickly without any interruptions, and also have control over authentication preferences.
## Swarm Participants
- Lead Contributor: @alwx
- Testing & Evaluation: @asemiankevich
- PM: @chadyj
- UX: @andmironov @jpbowen @hesterbruikman
## Product Overview
Status frequently logs out users when the app is in the background and forces users to log in again when opening the app. Being repeatedly and unexpectedly logged out has led to frustration and complaints (see Instabug and internal reports) which negatively impact the user experience and potentially contributes to churn. Also, users are encouraged to have complex passwords but this can be cumbersome to enter.
By reducing friction around the critical point of returning to the app users can spend more time in Status which will help DAU and retention (Q2 OKR).
This idea seeks to make logging in seamless through both technical and UX methods.
### Product Description
From a users perspective, the user will not repeatedly be logged out when using Status. This will be the default behavior. Since authentication preference is personal, there will be security/login settings so that a user can customize their desired level of control. For example, a user can specify never to be logged out, or choose to log in every time.
When we do ask users to login we want this to be as smooth as possible, and this can be achieved with the (optional) use of device security features such as Touch ID or a pin code. Instead of a password prompt, a user can simply use their fingerprint or look into the phone. This will be set up during onboarding and toggled in settings.
Note, that all transactions require authentication, so even if the phone was lost or stolen a third party couldnt transfer funds. This idea does not cover the transaction flow.
### Iteration 1
During onboarding give users the option to setup seamless authentication (if their device supports it) and use the device/OS conventions to enable, or skip. There will be a setting to manage this preference.
## Iteration 2
Goal Date:
Take seamless login further and fix the root cause of the log outs by restoring from crashes. See [#2869](https://github.com/status-im/status-react/issues/2869#issuecomment-376098196) for some preliminary exploration.
This iteration is completed when users dont have to type their password after a crash.
## Success Metrics
- A user does not need to login after several hours of intermittent use on Android and iOS, as well as logins persistent across upgrades (can it be automated in tests?)
- UXR validates workflow on real devices with real users
- 90% of surveyed users are satisfied with the frequency of login requests from Status app
- 0 password related issues in Instabug
## Exit criteria
When Iteration 1 and 2 are complete the success metrics should be evaluated. If the results are successful this swarm can be closed. If work is needed a third iteration can be done to address shortcomings.
## Supporting Role Communication
- Core
- Marketing
- Test team
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).