Add guidelines for LN sent payment confirmation UX

[moneyball]

Describe your content request

We should provide guidelines for what to show for various situations when sending LN payments.

Link to the page

https://bitcoin.design/guide/payments/send/

Why would you like to change the content?

We don't address LN yet.

Suggestions

Here is a draft proposal.

When a user attempts to send a payment it may or may not be completed "instantly." For example, if the payment recipient is using a non-custodial mobile wallet it could take them hours to open the wallet app to complete the payment. Therefore, it is important to provide a design guideline of how long a user should wait within the app (synchronously, with a modal screen, perhaps showing something like a spinner). Let's define a timeout, T. What should T be? Perhaps 10 seconds?

There are then 3 possible outcomes of interest:

1. Payment completes within timeout period T
2. Payment has yet to complete within timeout period T
3. Payment fails within timeout period T

For 1, it should then be as simple as showing "payment completed."

For 2, the guideline could be to show "payment sent" then allow the user to access any of the wallet's functionality again. Within the wallet's payment history view, the payment can be shown as pending.

For 3, show "payment failed" along with information about the error and suggest the the user might try to do.

In the case of 2, the payment completion now becomes an asynchronous activity which may or may not succeed. A design decision that needs to be made is whether to create an environment in which users assume (asynchronous) payments will complete and design the copy and notifications to support that. This is likely preferable as long as data supports that most asynchronous payments do successfully complete (what should "most" be here...80%? 95%?). If this is the case, then upon successful completion of the asynchronous payment there would be not notification to the user. Only if the payment is not completed (eg the HTLC times out after 24 hours) would a push notification be provided to the user letting them know the payment failed so they can take appropriate action (eg informing the recipient they attempted to pay them but it didn't work).

If, however, the design guideline is to not assume an asynchronous payment will succeed, then perhaps the "payment sent" screen should also indicated "pending." A push notification would also be sent upon a successful completion of the payment to let the user know. Another argument in favor of this design approach is that even if the user assumes it will succeed, they might like to be informed when the recipient has received it.

[pavlenex]

Thanks for proposing this @moneyball. Just for clarification, the reason why this page doesn't address LN yet is because previous milestones were addressing sections before it.

We do plan to address LN in the payments section with a few upcoming milestones, starting with milestone 11.

[GBKS]

Regarding timeouts, here are two relevant ancient articles from the Nielsen Norman group:

• Response Times: The 3 Important Limits
• Powers of 10: Time Scales in User Experience

The Bitcoin UI Kit has some screens for errors that could serve as a starting point for this, see them here. Although I would first put together a flow diagram to capture the logic before going into screen design.

I am curious if an app could make intelligent guesses whether a payment is likely to succeed. Could it probe the network and come up with a likelihood of success? If there's a 95+% chance of success, it could assume it will work? I am also curious if this is a moving target that changes as the tech matures, wallets become better connected, and the network grows.

Another option is to not face the user with a spinner, but let them do something useful during that time. Maybe they could label the transaction, add some tags, or save the contact while the transaction is pending.

[moneyball]

Yes it would be possible to develop a likelihood of success. LDK doesn't currently support this but could if there is demand from wallets/design community.

[GBKS]

This will be addressed in #589 (that PR is not 100% there yet, but will be).