Define the primary product scope of the guide

[Bosch-0]

This discussion relates to the wider LN content discussion however think deserve its own thread as it effects all areas of the guide not just LN related content.

Something I think would be invaluable for the guide is to clearly define the primary product scope the guide is aiming to help build. Defining this helps in various ways:

• Helps us decide what content SHOULD be included in the guide.
• Helps us decide what content SHOULD NOT be included in the guide.
• Makes it easier to onboard new contributors to the project as it is clear the type of content we are creating.

The scope IMO we should be focusing on is: Mobile first, non-custodial, Bitcoin Lightning products.

Anything that falls outside of this scope can be added in separate sections of the guide though this should not be a priority.

Why? See mine and Steve's comment on making the focus of the guide being for 99.9% of future users of which the above defined scope covers for reasons outlined in those comments.

This scope (or any scope we decide on) should be detailed in the introduction page and an explanation given as to why this is our scope. For example, if using the above scope we should elaborate as to how this product scope is how 99.9% of users will be on boarded into Bitcoin through over the next decade.

We should also clarify that the guide, at times, may make assumptions about where Bitcoin UX is heading and that it's content should be used as recommendations NOT as gospel.

We should also be crafting content that is future-proof and not just copy / pasting what is currently (most likely transitory) best practices - though this probably warrants a separate discussion.

[GBKS]

I think we have roughly three buckets in the guide:

1. General information (getting started, designing bitcoin products, private key management, glossary), which provides a foundation that can be applied to all kinds of products and design processes
2. Sections using specific product categories/types/specs to lay out user experience considerations, best practices, etc (onboarding & payments)
3. The case studies section, which is more open-ended and can cover diverse product types

Those buckets still work, IMHO, and it's bucket 2 that we are discussing here (and a little bit bucket 3). So far we've prioritized the "automatic cloud backup mobile app" because that is pretty much as consumer-payments-friendly as you can get with an on-chain focus. Now that we consider Lightning, and we want to keep our mainstream focus, it's logical to update the areas built around specific products (bucket 2) accordingly. Making that logic clear would be helpful, as you suggest.

Big picture, the Personal finance page can probably help prioritize our product focus, as it lays out personal finance need from the most frequent, low-value at the top and the opposite at the bottom.

I wouldn't be so strict around excluding specific types of content. If it's good content that helps a sub-set of designers and adheres to our principles, then we should see if we can find place for it. It doesn't have to be in those pages that focus on consumer products, but maybe it fits elsewhere.

[sbddesign]

I wouldn't be so strict around excluding specific types of content. If it's good content that helps a sub-set of designers and adheres to our principles, then we should see if we can find place for it. It doesn't have to be in those pages that focus on consumer products, but maybe it fits elsewhere.

I agree that we shouldn't be too strict around excluding specific types of content. It's probably easier to simply establish a roadmap of "current priorities". I think most contributors will want to work on the current priorities. However, that doesn't stop someone from creating content that falls outside those priorities if they want to do that.

Example: if the community roadmap is focused on creating content for mobile-first, non-custodial, Bitcoin Lightning products, then most people will likely work on that content; but, an individual is still free to create content around a desktop lightning node if they want to and submit a PR for the community to review.

[moneyball]

At a really high level, I think the guide's scope should be to aid product builders creating an application to non-custodially receive, store, and send bitcoin, at scale. (this isn't inconsistent with what has already been written, but it is a concise way to describe it)

Mobile-first, non-custodial, LN all derive from that.

[Bosch-0]

I wouldn't be so strict around excluding specific types of content.

Yeah definitely! Not a good approach to be too strict but having some focus, especially whilst we get LN integrated, I think will be a much easier approach than being too broad. We can broaden things as the guide becomes more developed - maybe that can be a V3 goal?

On your point around buckets in the guide this is something I have been giving a bit of thought to that relates to this discussion and the LN one. Making it clear what content type each section (bucket) of the guide is also something that will have the same benefits as defining a scope would have mentioned in the OP. Below is some rough sections I've defined and what type of content each should cover:

Introduction

• Explains what the guide is, what it's scope is (focused for now, wider as we expand into other products types), what it's limitations are. Should be able to do this in 2-3 paragraphs.
• Lays out the sections (see below) with brief paragraph on each.

Section 1

• Covers general Bitcoin design content.
• This would be the 'Getting started' and 'Designing Bitcoin products' chapters.

Section 2

• This section would lay out design 'pieces' explaining what they are and their their design trade-offs.
• The private key management page is an example of a chapter what would be in this section (I would rename this to private key schemes).
• Other chapters in this section could include:
  • Backup schemes - an example of a backup scheme "piece" would be detailing emergency kits used in Muun.
  • Networking schemes? (break this chapter into Bitcoin and Lightning sections.)
• We can include pieces that may still be experimental in design (things like keysends for LN wallets) that can be easily removed if the practice becomes obsolete. It should be noted that the pieces content should not be intertwined too much so we can easily add / remove pieces as we need.

Section 3

• This would be the meat and potatoes of the design guide and design a mobile-first, non-custodial, Bitcoin Lightning wallet from start to finish. Like a puzzle, we would combine the most UX friendly 'pieces' from section 2 to build a product.
• Chapters would be onboarding, payments (primarily LN focused). I would probably structure this section quite different tbh and break up onboarding / payments - will explore this further soon / after some discussion around this structure.
• We should stick with using the wallet UI kit for all design mockups in this section to keep things looking consistent.
• Something fun we could do is give this product some unique branding and have it presented as its own product that people could refer to. We could have this section called "Building the 'insert brand name here' wallet" and then detail it from start to finish inside.

Section 4

• This section would design more novel products from start to finish using the most UX friendly 'pieces' from section 2. in the same manner as section 3.
• This would include things like a multisig vault, node or Lightning node manager products.
• I think for V2 of the guide we should focus on getting all the other sections done well and focus on this for a V3 of the guide, thoughts?

Section 5

• This section would have a range of case studies for various use cases for wallets.
• This would build on section 3 (and later section 4) designs to show the various use cases that the product we built in section 3 could be used for.

Section 6

• This section would be the final section and have all the secondary type content like 'Contribute to the guide' and 'Glossary' chapter.

Currently we have a setup where section 1 and 2 and kind of jelled together and it can get a little confusing to reach and this will become more so as we add more content.