Updated daily spending case study for Lightning

[sbddesign]

I updated the Daily Spending case study for Lightning. Proposed fix for #615.

⚡️ Deploy Preview

[danielnordh]

Thanks for jumping on this @sbddesign.

Most of my feedback is on the new screens themselves, do you have a Figma that I could comment on directly?
I think that might be more efficient.

[sbddesign]

Most of my feedback is on the new screens themselves, do you have a Figma that I could comment on directly?

@danielnordh FIgma Link

[danielnordh]

OK, left some comments on the Figma.

To try and summarize:

• While the previous screenshots are 'only wireframes, they attempted to be very precise in the actual information they contained, how they fit together, and what flows started and ended where
• Even though these new screens are 'higher fidelity' visually, they feel less precise and informative in terms of information details and flows
• It is not obvious what the Lightning default of this version does or doesn't enable for the user and how it might differ from the previous case

[sbddesign]

Thanks for the feedback, @danielnordh. I did a good bit of work inside of the Figma document. Would you be able to look at that and let me know what you think of my updates before I put the new images into this PR? I added some commentary in their, as well.

It is not obvious what the Lightning default of this version does or doesn't enable for the user and how it might differ from the previous case

The Lightning default of this version enables the product to actually function as a daily spending wallet. The current case study outlines a scenario where an on-chain wallet is being used for daily spending. IMHO, that's not feasible due to the on-chain transaction confirmation time.

[danielnordh]

Thanks @sbddesign, I responded on some of the Figma comments.

I assume you had seen the previous Figma file and prototype, and I'm guessing some of my feedback comes down to not wanting to loose detail that we previously had. Perhaps you have gone through that screen by screen and updated, if so, apologies.

In my view it's not just a visual update of the case study page in the guide that we're doing. It's providing an as complete as possible resource (or benchmark) for a daily lightning wallet. I appreciate that is a big job, in essence we have to highlight all the design choices and tradeoffs one would have to make for this use case. This is where some of the advanced options come in, and explaining the things that need to be different in this Lightning version vs the previous one.

When I said:

It is not obvious what the Lightning default of this version does or doesn't enable for the user and how it might differ from the previous case

I meant that in the onboarding, or in the product, it is not clear to the user what they can do with bitcoin, and what this product cannot do. The fact that it is Lightning only is not explained. It would be valuable to think of how to communicate this in a case study, for others to follow. We could ignore this and sort of state that 'they don't need to know since all there activity will be on Lightning', but this seems less than ideal.

[sbddesign]

I have made several updates to this PR. It now includes a much more extensive prototype as well as some simplifications of the UX designs.

The fact that it is Lightning only is not explained.

@danielnordh I'm kind of operating here under our philosophy of wanting to abstract away the difference between Lightning and on-chain so the user doesn't have to worry about it.

This may seem odd, but I don't think it's unachievable (Muun has pioneered this and I'm sure many will follow). I added some notes in this case study to the design and technical considerations in an attempt to make this clearer to the reader. From the developer's perspective, a submarine swap provider could be integrated with the wallet so that the user can send to and receive from on-chain addresses using their Lightning wallet. From the user's perspective, it's easy enough to use that they don't need to worry about it. Some QR codes (Lightning) look different to them than other QR codes (on-chain), but they all seem to work with this simplified bitcoin wallet.

[danielnordh]

Thanks @sbddesign, this looks good to me.
Just added a minor comment in the prototype about a typo.

[danielnordh]

LGTM

[sbddesign]

Just added a minor comment in the prototype about a typo.

Fixed, thanks!

[GBKS]

Great update. Just had a minor nitpick about image sizes & width/height attributes.

There's a "Manual restore" flow in the prototype that is not in the page or in the rest of the guide. Something we can consider adding to the onboarding section.

[GBKS]

ACK.

[sbddesign]

There's a "Manual restore" flow in the prototype that is not in the page or in the rest of the guide. Something we can consider adding to the onboarding section.

@GBKS We actually don't even go into a lot of detail about the automatic flow, either. I opened #638 for us to flesh out the restoring a wallet page so we can update in a separate PR.