Improve Confirmation Screens

[bdresser]

Metrics have told us that the bulk of ALL user actions (anywhere from 70-90%) are on/around the Confirm screen. Almost half of all confirm screens are "contract interactions," which are perhaps our least well-designed confirm screens.

@omnat 's user research with dapp developers has also highlighted a lot of pain points with these screens, some of which are documented on this Figma

We should spend some time exploring ways to improve the design & experience of Confirm screens of various types. First step design brief @omnat & @bdresser

Other resources:

• See extension epic: Improve Transaction Legibility metamask-extension#5803
• Label of assorted issues: https://github.com/MetaMask/metamask-extension/issues?q=is%3Aopen+is%3Aissue+label%3AT18-ConfirmableAction

[bdresser]

also should consider

• a format for approving Meta Tx
• a confirmation screen for "change networks" API

[bdresser]

chatting with @danfinlay - may make lots of sense to separate the screen for switching a network (MetaMask/metamask-extension#5101) from the rest of the work on confirmation screens, since that might be a much larger project. thoughts @omnat @cjeria ?

[omnat]

to me its another permission request for the user so falls under user permissions. the scope here is

'dAppX detects user is on a wrong network, and suggests them to change it requests them permission to change it'

if it should be a bigger project with larger scope, what is that scope?

[bdresser]

sorry yeah my comment was not descriptive 😄

I think our work to design the confirmation screens that deal with signing transactions is going to be much more complicated than the screens that deal with nav or account management.

We should def keep talking about these together to start, but when it comes time to start thinking about prioritizing the design work, we should break this up so it doesn't become a massively complex task. Divisions might fall along the lines in the Figma

(1) nav & account confirmation screens (switch networks, connect/sign)
(2) transaction confirmations (the meat! sending ETH & tokens, contract interactions)
(3) signing data confirmations

good call on the wording, updated the other issue @omnat

[omnat]

The divisions for UI design work you mentioned here make sense to me, yes!

And agree, all 3 divisions share some conceptual & technical commonalities. And the experience design of overall permissions design (one-off / dynamic) is a more early stage design work and can be talked about together at this stage.

[omnat]

Technical questions, use-cases, and next steps here:
https://docs.google.com/document/d/1-yrO6lRmtL3hnDRS1hbTAuTB3jGgyxPmaGzYzAdfIiQ/edit