Skip to content

Signing on mobile v1: design decisions

Jump to bottom
Sasha Postnikova edited this page Oct 13, 2020 · 14 revisions

Links
Signing on mobile v1 #348 🐱
Kickoff meeting 📆
Hypothetical press release 📆
Specs doc 📆
Gnosis Safe - 5 Inconvenient multisig signature collection on-the-go 📆
Miro Dima, Dirk, Mouaz Signing on mobile 📌
iOS Invision 💖
Android Invision 💖

User tests
#27 Signing on mobile test script 📋
#27 Prototype A 💖
#27 Prototype B 💖
Dovetail project 💡

Past ideas
Authorize mobile device for Safe #310 🐱
Dapp interaction via WalletConnect #294 🐱
Safe Multisig mobile post phase 1 📆
Authorized device & initiate tx via WalletConnect 📆
Miro Tobi’s wireframes WalletConnect 📌

Platform: iOS, Android

App version: tbd

Which problem do we solve?
Inconvenient multisig signature collection on-the-go (see Gnosis Safe - 5 Inconvenient multisig signature collection on-the-go 📆 and Signing on mobile v1 #348 🐱).

What are the metrics and KPIs we will be measuring for this feature?
Funnel: how many users achieve successful owner import (owner_enter_seed -> owner_select_account -> success).

Is there user research or quantitative data informing decisions made here?
Data from discovery interviews Q1 2020 💡
Insights from discovery interviews Q1 2020 💡
Insights from #18 Safe Keys mobile prototype 💡
Insights from #19 Android Basics mobile prototype 💡
Roadmap Q3/Q4 2020 📆
Insights from #23 Read-Only mobile prototype 💡
Insights from #27 Signing on mobile iOS 💡

User flows

  1. Import owner key
  2. Sign transaction
  3. Remove owner
  4. Import owner when no Safe is loaded

1. Import owner key

2. Sign transaction

3. Remove owner

4. Import owner when no Safe is loaded

Main design decisions

1. Do we allow transaction confirmation only or confirmation & execution? Rejections?

Leave out transaction execution and rejections in the first version for simplicity. Execution should happen in the web interface. There are no proper rejections on mobile yet. We’ll introduce execution and rejections on mobile later.

2. One app-specific owner key vs multiple keys

Start with one app-specific owner key for simplicity.

  • We don’t have data about how users want to use their owner keys on mobile.

  • 90% of Safe owners have access to 1 Safe only (source). Which means that 90% of the Safes don't share owner keys with other Safes.

  • Multiple owner accounts for the same Safe on one phone could result in loss of funds if someone takes hold of the phone.

  • Counter-argument – reusing the same account for multiple Safes is bad for privacy.

3. Add owner via the app settings vs Safe settings

We agreed not to add owner from Safe settings. The same key is used for all loaded Safes.

  • It is simpler for the first version, no premature optimisation
  • This is close to how web interface with external wallet behaves
  • It’s too early to assume most users have multiple Safes that have different signer keys each
  • We are flexible to optimise it later

4. Do we need password/PIN protection?

In the first version – no, because phone is already locked. Go with “Are you sure?” dialog to prevent accidental signing, add biometry/password in later iterations.

5. Wallet vs key vs account

Let’s call it 'owner key' instead of 'account', 'owner account' or 'wallet'. It’s not very consistent in the web interface either, a question to consider later.

  • Difference between address, account and wallet
  • You’re not really importing a ‘wallet’
  • In the web interface we call it ‘owner’, ‘wallet’, ‘owner wallet’, ‘connected wallet’.
  • In the future we might rename it ‘signer’, ‘key’ or ‘signing key’ everywhere.
  • During user tests there was no strong preference among the users. So far in the tests they have followed the language used by the interface.

6. Entry point

The decision was to import owner key from app settings. The alternatives were:

  • ‘App settings’ and ‘bottom sheet’ were selected for ‘Prototype A’ and ‘Prototype B’ respectively.
  • ‘App settings’ is simpler to implement but has low discoverability.
  • ‘Bottom sheet’ is more prominent but the relation between Safes and keys might be less clear.
  • User test insights: both options were discoverable, although most users looked in the settings first.

7. To improve discoverability or not

There were some ideas on improving discoverability of this feature:

  • Suggest to import wallet right after the user loaded the first Safe
  • In case there are Safes show a banner on Balances screen

  • Decision: not in v1.

8. Loading state – full screen loader vs just the timeline

After the confirmation has been submitted we show full screen loader. Reasoning:

  • There are multiple requests.
  • To avoid multiple loaders.

9. Success screen vs snackbar

Show snackbar after the owner key has been imported. Reasoning:

  • You can’t go back from success screen, the key is already imported.
  • ‘Finish’ button does nothing.

10. Remove button vs swipe to remove

Remove text button 'Remove owner' below the list item, replace Etherscan link with Delete icon. No swipe to remove. Reasoning:

  • It’s a list item.
  • Users will hit ‘Remove’ button accidentally.
  • Swipe would be an option if all list items were the same and without chevrons.

User tests – insights, changes after user tests Changes:

Changes after release, metrics tbd

Wiki home

Wiki home

Clone this wiki locally