UX Improvement: Send flow

[swedishfrenchpress]

Issue Type

• [x] UX Improvement
• [x] UI Enhancement
• [ ] Accessibility Issue
• [ ] Usability Concern

User Story/Background

As a user, when I press the "Send" button, I am presented with two options: ecash or Lightning. I choose one, expecting a straightforward process. However, upon selection, the interface becomes unclear. For example, when I want to pay an invoice, the option misleadingly says "create an invoice" which seems like a typo, as it's actually the third button. This confusion disrupts my workflow, and I believe it does for others as well. From discussions and personal experience, it seems most users (95%) prefer to scan an invoice directly, 4% paste an invoice, and a minority (1%) might do something else. This feedback suggests a need for more intuitive and accurately labeled options to streamline the payment process.

Current Behavior vs. Expected Behavior

Current Behavior: After pressing the "Send" button, users are presented with two options: ecash or Lightning. Selecting either option leads to a confusing interface.

• Ecash: User is required to first select a mint, then a payment option (nostr or copy & quick share) before they can enter the amount they want to send and generate the invoice.
• Lightning: User must first select mint and then select one of 5 options to complete a lightning transaction. Text suggest user must create an invoice when the user has an intention is to pay an invoice, causing confusion and a disruption in the process.

Expected Behavior: After pressing "Send" the user should be able to more easily send ecash or pay send bitcoin via lightning.

Proposed Solution

UX:

Send ecash

1. Press "Send"
2. Press "Ecash"
3. User has default mint -> the first mint added should always be the auto-default mint
4. Select amount (Mint can be changed in this screen)
5. Payment overview (advanced options, amount and mint can be changed here)
6. Final Ecash QR screen with following options:
7. Copy token
8. Share8.Send via Nostr

Send Lightning

1. Press "Send"
2. Press "Lightning"
3. User has default mint -> the first mint added should always be the auto-default mint
4. User sees 4 options a.) Paste invoice: Copies invoice from clipboard b.) Scan QR: show scan QR screen c.) Enter Manually: User enters a lighting invoice or address d.) Contact: Send to any nostr contact with an LNURL in their profile.
5. Payment overview (advanced options can be changed here)

UI: Quite a few large UI changes. Please see mockup below.

Mockups/Prototypes:

Send ecash

• Figma:https://www.figma.com/file/GWk1KbXXSUvd7sEHlFKBvD/eNuts?type=design&node-id=1308-17432&mode=dev
• Video: https://github.com/cashubtc/eNuts/assets/78821053/8983c6e1-8b16-48d1-8807-58e3fa6bcf5e

Send Lightning Coming soon.

Rationale

• Benefit to Users: One of the golden rules of UX is "Don't make me think." In design, our goal should be to minimize the user's cognitive effort to achieve their objective. By eliminating the two screens that necessitate the user making two choices (mint selection and send method) before reaching the point where they enter the desired amount to send, we reduce mental load and streamline the user experience.

Alternatives Considered

There are a few alternatives designs I explored initially but I feel that this version is the best. Happy to make any modifcations or explore any new concepts.

Additional Context

This was one of the first pieces of feedback we received back in September #189. I also recognized it when I first downloaded and used the application. We also got some feedback from @callebtc regarding this. I've also shared this design within the Cashu discord and Bitcoin Design Community. We've received limited but positive feedback.

I recognize that allowing the user to change mints after they've already generated the ecash adds extra complexity. The backend would need to perform a mint swap. However, I think it's valuable to have.

[KKA11010]

Excellent summary with a comprehensive description!

I agree on the sub-optimal send-flow, and I will implement your design proposals to enhance the UX. This will be a huge improvement! However, there are different possibilities to achieve the same goal in eNuts:

Send Ecash flow

Proposal send Ecash flow from dashboard (4-6 steps):

1. Press "Send"
2. Press "Send Ecash" a.) User has default mint -> auto select it b.) User has no default mint -> auto select mint with highest balance? show mint selection screen?
3. Select amount (Mint can be changed in this screen)
4. Payment overview (advanced options, amount and mint can be changed here)
5. Final Ecash QR screen with following options:
   • Copy token
   • Share
   • Send via Nostr (6.) In case of sending via Nostr, contacts will be shown -> Select target from contact list and publish DM event

Proposal send Ecash flow via Nostr contact list (4 steps):

1. Press "Contacts"
2. Select contact (or press QR icon to scan npub/nprofile QR) and press "Send Ecash" a.) User has default mint -> auto select it b.) User has no default mint -> auto select mint with highest balance? show mint selection screen?
3. Select amount (Mint can be changed in this screen)
4. Payment overview (advanced options, amount, target-contact and mint can be changed here)

Proposal send Ecash flow from QR scan screen (3 steps):

1. Press "Scan"
2. Scan npub or nprofile QR a.) User has default mint -> auto select it b.) User has no default mint -> auto select mint with highest balance? show mint selection screen?
3. Payment overview (advanced options, amount, target-contact and mint can be changed here)

Send Lightning flow

Proposal send Lightning flow from dashboard (4-5 steps):

1. Press "Send"
2. Press "Lightning" a.) User has default mint -> auto select it b.) User has no default mint -> auto select mint with highest balance? show mint selection screen?
3. Paste invoice/lnurl or scan invoice/lnurl a.) Pasted invoice: shows invoice overview b.) Pressed "scan": show scan QR screen and redirects to invoice overview
4. Payment overview (advanced options can be changed here)

Proposal send Lightning flow via Nostr contact (4 steps):

1. Press "Contacts"
2. Select contact from list and press "Zap" ??? a.) User has default mint -> auto select it b.) User has no default mint -> auto select mint with highest balance? show mint selection screen?
3. Select amount (Mint can be changed in this screen)
4. Payment overview (advanced options, amount, target-contact and mint can be changed here)

Proposal send Lightning flow via QR scan screen (3 steps):

1. Press "Scan"
2. Scan invoice/lnurl a.) User has default mint -> auto select it b.) User has no default mint -> auto select mint with highest balance? show mint selection screen?
3. Payment overview (advanced options can be changed here)

🤠

[swedishfrenchpress]

Thanks for the summary, @KKA11010 .

One thing that came to my mind when looking at your flows is how we can abstract away the default mint issues. Could we automatically assign the first mint the user adds? They would always have the option to change the default mint in the settings. This would eliminate the need to have a mint selection step during the send process.

I think we're in alignment with the Send Ecash flow from the dashboard. I have some small tweaks to the copy that I think will help. How about we keep the two options as simple as possible:

Agreed on the send Ecash flow via Nostr. The only thing that comes to mind is whether we should combine the ability to send Ecash and Lightning in the same contact flow. And I see that you touched on this in the send Lightning flow via Nostr step. I'll work on a UI that combines sending both Ecash and Lightning via the contacts option.

In the meantime, I posted a quick survey on Twitter asking users what they typically do after choosing to send a Lightning payment: https://x.com/uxerik_/status/1761405968632471645?s=20. I want to use this insight to influence the options we display after the user chooses the send Lightning option.

[KKA11010]

Someone sent me this on Nostr. Could this be a good screen when some presses "send lightning"?

[swedishfrenchpress]

I've been reflecting on how to enhance our send flow, drawing from the feedback we received. I've been brainstorming on a design that unifies the lightning and Ecash flows into a single one aiming to minimize cognitive load for the user.

Send Lightning:

1. Clicks "send".
2. By default, users are directed to a "Send Lightning" flow. Given that the majority of our users likely want to send lightning payments, this approach seems logical. However, users can easily switch to Ecash using the toggle switch at the top of the screen at any point.
3. In the Lightning mode, the camera activates automatically.
4. Users have the option to either scan a LN QR code or input an LN invoice. (Concern is UI clutter with camera and manual entry features, especially on small screens.)
5. At any stage during the Lightning sending process, users can select the mint icon to access a menu for mint selection, allowing them to change the mint used for payment.

Regarding step 3: This decision was influenced by a survey asking users, "After opting to send a Lightning payment, what is your next step?" (https://x.com/uxerik_/status/1761405968632471645?s=20). With 180 responses, the results were evenly split between pasting an invoice/entering an LN address and scanning a QR code. So having both options on the same screen seems like the most practical. It also takes into consideration our feedback @KKA11010. I think there might be some potential concerns about small screen compatibility, but I'm optimistic about devising suitable designs for smaller displays.

Scan LN invoice QR https://github.com/cashubtc/eNuts/assets/78821053/00df2592-fa21-48d4-8df6-9153be303a59

Paste LN address / invoice https://github.com/cashubtc/eNuts/assets/78821053/e58946ef-053c-4c5e-8c1c-f74f859da943

Send Ecash:

1. Clicks "send".
2. Select the "Ecash" option via the toggle switch.
3. This action opens the "Send Ecash" menu, where, unlike in the Lightning mode, the camera is not displayed.
4. The user specifies the amount of sats for token generation.
5. Upon generating the token, if users decide to switch mints, they can simply click on the mint name, select an alternative mint, and a new token will be generated accordingly.
6. This streamlined approach aims to simplify the user experience while accommodating diverse user preferences and behaviors.

https://github.com/cashubtc/eNuts/assets/78821053/6ba4e5e5-7fa5-4010-bbb1-7422a7f41514

[KKA11010]

I've been reflecting on how to enhance our send flow, drawing from the feedback we received. I've been brainstorming on a design that unifies the lightning and Ecash flows into a single one aiming to minimize cognitive load for the user.

Send Lightning:

1. Clicks "send".
2. By default, users are directed to a "Send Lightning" flow. Given that the majority of our users likely want to send lightning payments, this approach seems logical. However, users can easily switch to Ecash using the toggle switch at the top of the screen at any point.
3. In the Lightning mode, the camera activates automatically.
4. Users have the option to either scan a LN QR code or input an LN invoice. (Concern is UI clutter with camera and manual entry features, especially on small screens.)
5. At any stage during the Lightning sending process, users can select the mint icon to access a menu for mint selection, allowing them to change the mint used for payment.

Regarding step 3: This decision was influenced by a survey asking users, "After opting to send a Lightning payment, what is your next step?" (https://x.com/uxerik_/status/1761405968632471645?s=20). With 180 responses, the results were evenly split between pasting an invoice/entering an LN address and scanning a QR code. So having both options on the same screen seems like the most practical. It also takes into consideration our feedback @KKA11010. I think there might be some potential concerns about small screen compatibility, but I'm optimistic about devising suitable designs for smaller displays.

Scan LN invoice QR https://github.com/cashubtc/eNuts/assets/78821053/00df2592-fa21-48d4-8df6-9153be303a59

Paste LN address / invoice https://github.com/cashubtc/eNuts/assets/78821053/e58946ef-053c-4c5e-8c1c-f74f859da943

Send Ecash:

1. Clicks "send".
2. Select the "Ecash" option via the toggle switch.
3. This action opens the "Send Ecash" menu, where, unlike in the Lightning mode, the camera is not displayed.
4. The user specifies the amount of sats for token generation.
5. Upon generating the token, if users decide to switch mints, they can simply click on the mint name, select an alternative mint, and a new token will be generated accordingly.
6. This streamlined approach aims to simplify the user experience while accommodating diverse user preferences and behaviors.

https://github.com/cashubtc/eNuts/assets/78821053/6ba4e5e5-7fa5-4010-bbb1-7422a7f41514

Thank you for the design proposal @swedishfrenchpress

I personally don't like the combining of Ecash and Lightning in 1 single screen.

It does not minimize the cognitive load imo but presents the user with a lot of possibilities.

I prefer the current way to choose between ecash and lightning in the very first step. It is much more intuitive.

Lets focus on the lightning send-flow:

• After pressing 'send' > 'lightning'

I propose to open the QR scanner with a button to paste an invoice and a button to navigate and pay to a lnurl address.

[swedishfrenchpress]

Thanks for the feed back @KKA11010! I've been working on a version that keeps the existing flow: Send -> Lightning / Ecash -> UI. I've been a bit busy with some work related stuff and haven't had a chance to finalize it. Hopefully will have something to share next week.

[swedishfrenchpress]

Hey @KKA11010, I've been exploring some ideas and would love to hear your thoughts.

https://github.com/cashubtc/eNuts/assets/78821053/5c27c815-7f63-49f9-a3cf-eab790027be3

In the video, I run a few different workflows:

• Pasting an invoice
• Scanning a QR code
• Sending to an LN (Lightning Network) address

Here are some of the notable changes:

1. Introduced a "Contracts" and "Scan QR" button above the manual entry field.
2. Eliminated the descriptive text under Ecash and Lightning options.
3. The summary field is now streamlined to display only the essentials: amount, estimated fees, and total. After reviewing other Lightning wallets like Phoenix and Wallet of Satoshi, which tend to limit the displayed information, I believe this approach reduces cognitive load. Previously, the display included payment type, mint, receipt, amount, estimated fees, and balance after the transaction, which was quite comprehensive but might be overwhelming.
4. This design also depends on the ability to dynamically calculate fees, that is, in real-time as the user inputs an amount. Currently, the app requires users to press a "calculate fee" button before proceeding to the payment confirmation screen. This design aims to eliminate an extra step by integrating fee calculation directly into the final send screen.
5. One element that's missing in this design is coin selection, which I couldn't fit. It could potentially be included if we reintroduce the calculate fee screen followed by another payment confirmation screen, but as mentioned, I'm keen on reducing the need for extra steps.

I'm open to any feedback you might have!

[swedishfrenchpress]

Hey @KKA11010, I've been exploring some ideas and would love to hear your thoughts.

https://github.com/cashubtc/eNuts/assets/78821053/5c27c815-7f63-49f9-a3cf-eab790027be3

In the video, I run a few different workflows:

• Pasting an invoice
• Scanning a QR code
• Sending to an LN (Lightning Network) address

Here are some of the notable changes:

1. Introduced a "Contracts" and "Scan QR" button above the manual entry field.
2. Eliminated the descriptive text under Ecash and Lightning options.
3. The summary field is now streamlined to display only the essentials: amount, estimated fees, and total. After reviewing other Lightning wallets like Phoenix and Wallet of Satoshi, which tend to limit the displayed information, I believe this approach reduces cognitive load. Previously, the display included payment type, mint, receipt, amount, estimated fees, and balance after the transaction, which was quite comprehensive but might be overwhelming.
4. This design also depends on the ability to dynamically calculate fees, that is, in real-time as the user inputs an amount. Currently, the app requires users to press a "calculate fee" button before proceeding to the payment confirmation screen. This design aims to eliminate an extra step by integrating fee calculation directly into the final send screen.
5. One element that's missing in this design is coin selection, which I couldn't fit. It could potentially be included if we reintroduce the calculate fee screen followed by another payment confirmation screen, but as mentioned, I'm keen on reducing the need for extra steps.

I'm open to any feedback you might have!