Onboarding open-source projects to Bitcoin Design Guide

[pavlenex]

We've discussed a few times that in order for the Design Guide to take shape, we really want people to use it. One idea was to choose a few open-source projects and collaborate with them. We as a community can help them improve the UX/UI of their software, where as the project can provide valuable feedback to us. By being focused on concrete projects, we can see our theoretical work in practice and shape our guide around concrete use-cases.

I'm opening this discussion so we can decide on the process and determine what we can give to the project and what we expect in return.

1. How do we choose which projects to help?
2. Is there a certain type of project we'd like to use the guide?
3. What we can offer to the project?
4. What do we expect from the project in return?
5. Do we want businesses/enterprises as well or FOSS for starters?
6. Do we want new or established projects (for established we can probably focus only on certain parts of the UI)
7. Do you guys have any projects you like that we can help?

I'm trying to get the discussion going that can help me figure out how I can help in connecting to these projects, because I'd really like to help with that part, mostly because of my FOSS background for the past 4 years.

[GBKS]

A great conversation to have. The first question "How do we choose..." is important because it raises the point whether we want such a thing as the community "officially" supporting a project, or whether it's up to individuals taking charge and using some of the resources the community provides (guide, calls, feedback, etc). My assumption is that it's up to individuals (solo or as voluntary groups) to kick these things off and keep them going, and not some top-down type of thing. The rest of my response is based on that.

1. How do we choose which projects to help?
Since we already have some product case studies in the guide (here and here), it would be cool if those would align with supported projects. Would go hand-in-hand.

2. Is there a certain type of project we'd like to use the guide?
I'd start with open-source, non-custodial wallets as that's what most of the guide is about right now and then over time move to more complex products (merchants, enterprise, etc). Building good products is hard, so I'd focus on "less, but better".

3. What we can offer to the project?
I organized some thoughts here.

4. What do we expect from the project in return?
Since everything is open-source, not sure what else we can expect. Most important is that there is interest in design and collaboration on both sides so it's not some type of imposition. Of course we want the learnings from project work to flow back into the guide and other resources.

5. Do we want businesses/enterprises as well or FOSS for starters?
I'd keep it simple to start with. But others may have different interests and everyone should receive the same support.

6. Do we want new or established projects (for established we can probably focus only on certain parts of the UI)
Don't think project age matters. More important seems to be whether there are shared values, interest to collaborate, good potential for design work, etc.

7. Do you guys have any projects you like that we can help?
I personally want to start working with a project focused on multisig. Maybe Specter since we already had that design review call with them? Tankred might also be open to keep developing his demo app for Photon, which could satisfy the low-amount mobile wallet use case. I think we should also support Bosch in his work on the Core GUI. Big picture, I think it would be good to support one project in each major category (mobile, desktop, merchant...) so we could end up with a really solid set of interoperable, consistent, well-designed software that covers all major use cases.

[ConorOkus]

Thanks for starting this conversation, some thoughts on some of the questions.

1. How do we choose which projects to help?
Perhaps with projects that have shown interest in design collaboration already. They have engaged with the community in some fashion through community calls and design reviews.

2. Is there a certain type of project we'd like to use the guide?
Open source, non-custodial and focused on beginners to start with. Moving to more complex applications as Christoph mentioned.

4. What do we expect from the project in return?
They are willing to share the collaboration process through documentation, presentations, videos etc

Pretty much agree with the rest of the above comments

[pavlenex]

Thanks for the replies guys. This will be quite helpful in me determining what specifically we want from the projects and what we can offer them.

For example:

1. We're offering a team of bunch of designers UX/UI experts to help you improve your project sounds great, but it's too broad.
2. We'd like to help you improve the initial wallet setup of your wallet and our community will organize 3 meetings and draft xyz. This is specific but doesn't tell them exactly what we need in return.
3. We'd like to help you improve the initial wallet setup...and we'll organize a presentation meeting so that we can better understand your project. After that, we'll have a design sprint and try to help you with that specific problem. Finally we'll put what we learned into our design guide... This is good but doesn't provide concrete connection of them using the guide

I'm now trying to come up with a workflow/approach:

1. Project presentation
2. Determining problems
3. Design sprint meeting
4. Documenting what we've learned in the design guide
5. Project uses the guide to learn how they can solve the problem and provide feedback

[pavlenex]

A summary of discussion brought up in call #56 (Community Call 9).

From what I remember we discussed 3 different types of projects we can onboard.

Established Project

An established project is a project well-known in the community with established user-base. These projects have their own processes and already know what are their UI pain-points. Established project is harder to get attention from, since their maintainers are already busy managing their community etc. An established project needs personalized support/help in order to get involved. They want specific problems to be solved.

• Organize a meeting where project is presented
• Organize a meeting where someone from the established projects outlines pain-points
• We focus on specific areas and try to present a personalized solution to problems
• We use the learnings from that and improve our gide

New Project

A new project is something that is harder to discover. Usually has only a handful of users, but we can discover them through an application process. This project is happy that they have attention and are more likely to implement bigger UI changes. They're looking for any help they can get.

• Organize a meeting (start a discussion) where project is presented
• Define pain-points and offer a solution by pointing them to the specific area of the guide that solve it
• Improve the guide based on feedback

Bitcoin Design Community Starts a project

In this scenario, Bitcoin Design community starts decides to create a brand new wallet. This gives us more creative freedom and concrete product to showcase (built by BItcoin Design Community), however it comes with quite a few disadvantages imo.

• Efforts would need to be redirected in wallet development rather than guide development
• It's uncertain people will use the wallet and we'll have to wait for community to form around it
• Providing user support once wallet launches requires a completely new community that can manage it

IMO A new wallet would give us ideal circumstances and we can build on it theoretically, but wouldn't get us on the streets, we'd be missing quite a lot on users feedback and actual usage and in a way we'd have to become an established project to start getting users feedback.

[pavlenex]

Personally, I'd prefer if we initially get connected with an established projects and wouldn't mind new projects if we decide to create the application application process. With established projects we get common UX problems served on a silver platter, we just need to find a way to solve them and then implement what we've learned into the guide.

For established projects, I've found two that we can kick things off with.

Specter Wallet

Specter has already been presented in one of the design review calls. There's also a video of that presentation. The lead maintainer Ben discussed things with community and core team and they're willing to connect with us. I've mentioned to Ben that they'd need to identify pain-points which we can then try to solve either by pointing them out to the guide itself or improve the guide based on our learning. At this moment, I'm waiting to hear back from Ben with a list so that we can set up another meeting where he can show us the UX/UI problems Specter has. Established projects already know their user pain-points as they're in constant communication with their user-base.

BTCPay Server Wallet

As a core contributor to BTCPay, I am a bit biassed when suggesting this, but BTCPay has an internal web-wallet which relies on a full node. It has plenty of options but it certainly needs a lots of UI improvements. If community decides that this is interesting problem to tackle, I'm happy to organize presentation of project in general and showcase the wallet specifically.

[ConorOkus]

Sounds good, design review could probably be a good place to tackle very specific pain points for these projects. Perhaps a few interested designers work closely with these teams but we make the meetings open so people can listen in or watch the playback and give their opinion.

[GBKS]

I'm curious if Photon is a good project to work with as a new mobile project. Would allow us to execute well on the cloud backup key management scheme. But it would require Photon to become a serious wallet project. My impression is that it's more of a showcase for the library at the moment.

[pavlenex]

I guess it can be a good starting point, depending on how much time @tanx is willing to contribute to the UI/UX and if it's actually made to be a showcase for the library as you mentioned.

[tanx]

I'm curious if Photon is a good project to work with as a new mobile project. Would allow us to execute well on the cloud backup key management scheme. But it would require Photon to become a serious wallet project. My impression is that it's more of a showcase for the library at the moment.

@GBKS yeh, it's mostly a demo right now. Since it builds on BlueWallet's multisig libraries the foundation is pretty solid though.

I guess it can be a good starting point, depending on how much time @tanx is willing to contribute to the UI/UX and if it's actually made to be a showcase for the library as you mentioned.

@pavlenex I would love it if the wallet got some love from the design community. I'm currently working on a multisig PoC that allows upgrading from a single sig seedless wallet to a cosigner in a 2-of-3 with CoboVault and ColdCard support (with cloud backup of the xpubs/paths/fingerprints). Ideally with some kind of step-by-step guide that helps the user avoid common security pitfalls raised by Ben here and here.

[GBKS]

An additional approach would be to try to improve specific areas across projects. Let's say Conor and Maggie got so into onboarding during their work that they want to make sure that all wallets have the best onboarding ever. They can then engage with various projects on that particular topic. This is especially important for topics like import/export and interoperability, but might also be something we can consider for streamlining language. This approach is based on having experts in specific areas vs. embedded designers that work long-term with projects. The initiative would have to come from those experts to reach out to projects.

[pavlenex]

I think that's approach is good. It would allow people focused on certain portions of the guide to skip from project to project and gain knowledge & experience, but at the same time it would require better coordination since switching designer teams between projects will require the project maintainers to explain some things over and over, (unless we can document that somehow, record calls, etc?).

Or perhaps a mix. A long-term designer to the project (if project has it) can be that point of contact for different teams that would bring in the expertise in tackling problems.

[GBKS]

I think we just have to be prepared for different scenarios based on current project needs, designer interests, etc. Some people like to dip in and out, others prefer long-term relationships. Some are generalists and others are focused on usability, branding, design systems or some specific topic. Just from experience with designers (and I'm sure the same is true with developers), some can't stand projects longer than 3-6 months but can do amazing work (usually visual & branding) in short periods of time, and other designers prefer long involvement and careful iteration (usually usability and design systems). We could lay out a few different playbooks accordingly.

[pavlenex]

Okay, just a bit of update on my end, as I've been talking to a few FOSS maintainers and community members. We still need to have a defined process or workflow, but that comes with practice, so it'll be a trial and error a few times before we can actually define them.

For now, these are the projects that agreed to collaborate and the progress.

• Specter Wallet - Shared very specific UX troubles they need help with. We need to figure out how to present these problems (Christoph, Conor and I discussed that recording video may be good) and set up a meeting where we discuss how to tackle them.
• Zeus Wallet - Evan will be presenting Zeus on a Design Review Call #8 Afterwards they'll share specific UX problems but they're not opposed to an entire UI re-work if needed.
• Wallet using Photon- Tanker shared his what he needs help with, and would be good if we could take some action on Photon Wallet.
• BTCPay Server - I'm happy to do a demo of BTCPay Server when there's an empty slot and focus on the internal wallet and even more specific coin selection in the internal web wallet.

Probably a good way to proceed is to first get introduced to the project, then see specific problems. After we define specific issues, we can see how that issue relates to our guide. And it's for example onboarding issue, perhaps Connor or Maggie can help, if it's payment issue maybe Johns can step in and try to help, but the calls should always be opened to everyone and maybe recorded. Once we solve the problem we can update what we learned in a guide. I think we're in a stage where 1:1 focused work is better, since we're still not at a stage where we can simply share a page of the guide and solve a problem.

Thoughts?

[ConorOkus]

This sounds really good. I like that there is a mixture of projects here. Desktop, mobile, multisig, payment processor etc. Good job helping to organise this @pavlenex.

I agree let's set up some open introductory calls and go from there!

[johnsBeharry]

Nice work brining structure to this @pavlenex! Looking forward to more OSS Relations.

[pavlenex]

Another update. On Design call #9 we had 3 OSS project presentations. Video preview is available here.

We now have 4 projects in total that shared with us the introductions and some shared specific problems that we can tackle. The biggest problem right now is that we have to figure out how we want this handled. Do we organize a design sprint, a meeting, how do we decide which areas to tackle and who in community will actively been involved with particular projects.

Overview of the progress

Specter wallet

1. Project Introduction
2. Document of the specific UX problem they're tackling
3. Video recording by @GBKS explaining above document visually

To-do

• Figure out how problem fits into our design guide (their issue is about hardware wallet integrations into a remote-node software).
• Determine how do we want to organize problem solving (design review call or dedicated design sprint, something else?

Hexa Wallet

1. Project Introduction video
2. Project slides

To-do

• Reach out to the project and see what areas they need help with or provide feedback based on showcase they did

Zeus

1. Project Introduction video

To-do

• Reach out to the project and see what areas they need help with or provide feedback based on showcase they did. It's notable that they're not opposed to UI, redesign, even okay with using a different component lib.

BTCPay Server

• Project video introduction

To-do

• Determine how do we want to organize problem solving (design review call or dedicated design sprint, something else? for Coin Selection issue in the internal wallet and wallet itself.

So we have 4 projects to choose from, now that we know what hey need help with, let's figure out how we can help and who's interested in particular areas.

[moneyball]

I think we develop and refine a variety of ways to help, and then we work with a given project to determine to choose what would be most helpful.

I do like the recently shared (on Slack) mechanism to provide critique:
https://www.useronboard.com/how-bitcoin-onboards-new-users/
https://builtformars.com/creating-an-account-with-signal/

Such analysis and feedback would likely be valuable by many projects. It can also be done without interaction with a project so no distractions (but of course would be most valuable if the project is engaged and welcomes the feedback).

The other ideas you list are good too including design sprints for specific problems a project is having.

I would also suggest any engagement we have with projects always attempts to utilize the design guide to help. If the design guide doesn't contain the necessary content to help (which is likely to be the case early on), then it is an indication where it can be improved, and at the very least an issue should be created to track where it can be improved, and ideally part of the engagement with a project tangibly improves the design guide.

[GBKS]

I've been working on a document to capture these ways to support projects. Still messy, feel free to add your thoughts. Here it is. Creating a "project brief" format seems like a logical thing to do. This could take the form of an issue in the "meta" repo with a summary of the problem, references, contacts, next steps, etc. This would allow us to have a single go-to point for these projects to organize, answer questions and track status. Eventually we might be able to turn those into case studies, or reference them in the guide. Simple projects may not need more organizational overhead on our side, and more complex projects may have their own structures we can work with.

Regarding analyzing other projects, I find it to be one of the most informative things to do as a designer. It's so helpful to try things out, take a lot of screenshots and spend a little time analyzing them. It's a lot more effort than a slideshow, but the tutorials by BTCSessions on YouTube (here's a multisig example) are great. Not only do they showcase the products for mostly realistic use cases, he also adds very helpful insight and commentary that point towards the strengths and weaknesses of the user experience. Plus, video is convenient (as a viewer, but much harder to create).

The four projects we have here require very different types of support (redesign, feature improvement, feedback), so I think they will help us figure out a lot of this process.

[moneyball]

Those videos are great but a very different experience in that they're 1 hour vs. the 1 minute I spent looking through the slideshow. I think there is room for both.

[ghost]

Principles In Practice

Thank you @pavlenex for encouraging this discussion and for helping bring together multiple projects with specific issues. It is a great way of involving the community and discovering ways to help. Thanks @moneyball for suggesting taking issues from product makers. Thank you everyone, always, for your time and thoughts, both here and on meetings. I agree that building on design reviews and working toward more concrete design solutions is a good step forward.

People learn about bitcoin in good part from their experience with a bitcoin wallet or product. This experience can guide them through a progressive journey toward self-sovereignty or it could make them want to turn away once they encounter questions or challenges. The Bitcoin Design Guide is offering best practices for the creation and improvement of bitcoin products, yet we have a gap to fill: practical design solutions that can be replicated and customized to create and improve bitcoin products.

Something to think about is that only looking at specific issues without some kind of framework or process could make it hard for other product makers to adapt design solutions to their needs. It could also be harder to organize design reviews in a way that makes it easier to look for specific solutions, if we do not go beyond grouping them within a Design Reviews section.

As I’ve been looking into putting together the Principles page, I think it could, instead of being a page on theory and best practices for product makers, become a dedicated section to practical solutions based on bitcoin principles. Principles In Practice

This could be an opportunity to not only look at given issues but to create a roadmap of UX design that tackles issues through the process and decision making of creating a bitcoin product from beginning to end. I apologize if when I mentioned the possibility of building a wallet, I wasn’t as clear as to the reasons behind my thinking. I am not coming from a place of creating a competing product, but thinking in terms of creating a design foundation that stems from direct practice and experience, focused on best practices and working toward self-sovereignty. I am thinking of the possibilities of trying different design methods and creating practical solutions that can be adapted to different issues product makers are facing. Each step built in the open so as to help the entire ecosystem.

Building bridges:

• Exploring important issues that go into building a product, especially in terms of bridging design and development. If we look at each step in the design process it will be easier to identify issues that designers may be unaware of when trying to suggest solutions. It could also help designers know what is possible and what needs to be considered from a development point of view. @johnsBeharry @pavlenex @tanx (NothingMuch, I don't know his GitHub handle)
• Having a set of practical examples could help build a case toward better design that could be brought up to product maker teams. Perhaps, for example @Bosch-0 could help encourage changes to Bitcoin Core if we can have documentation to back his work and to back what he is hoping to improve.

Supporting what makes products unique:

• Again I am not thinking of competition, but about the benefits of working together to discover issues and possible solutions that can be adapted to multiple scenarios.
• Exploring different approaches based on the types of products that could be built, perhaps starting with the specific projects that have already been brought into the community.
• Each product maker has a unique story and purpose. Each one has unique audiences and covers different bitcoin needs. We should help support these strengths, encouraging the development of their unique potential.

Expanding specific parts of the process:

• Design review issues could be more easily organized as practical examples, if we have a process approach where the issues can fit into specific parts of a bitcoin product’s creation roadmap. We should look at what these possible steps can be. @pavlenex could you help us know more about the process of creating a bitcoin product, the possible individual steps and possible related issues?
• We could also review and showcase examples we find of good UX and unique approaches to handling bitcoin education.
• Focusing on specific parts of the design process, could help group issues, generate related questions and possible practical solutions that we can address as a community.
• We can tie back to Bitcoin Design Guide

Looking at the bigger picture:

Building a support system that welcomes questions, issues and conversation that can affect the entire bitcoin product ecosystem, like privacy and interoperability. We could help make the community bonds stronger so these issues can be brought up and addressed not only by a single product maker but by multiple product makers, leading to possible solutions within the larger community.

Drive innovation and education:

Having a framework could speed future design processes. It could serve as a kind of incubator for new product makers, and possibly create a space for learning opportunities. @ConorOkus, what do you think are some of the possibilities? I know you have good ideas on this.

Open new doors to research:

Open the possibility of researching specific parts of the design process, perhaps even with prototypes that could be openly shared. @johnsBeharry (Forgive me, I don't yet know the handles of other researchers -- Jelena, Maggie, Patricia, Jamaal, Mick...)

Connect with users:

• Discovering and testing some of the issues that people go through in their personal bitcoin journeys
• Trying possible solutions for smoother experiences by working closely with product makers and paying close attention to feedback from users and/or creating research projects that connect product makers, designers, researchers and the community
• Creating ways of displaying information and giving education that makes bitcoin easier to understand
• Encouraging a positive bitcoin culture

Connect theory and practice:

Building the design guide and connecting it to practical examples can make it easier for product makers to implement best practices and discover solutions more efficiently.

As this design foundation continues to grow, we could help guide them to specific examples. This could help free future design resources by focusing efforts on more difficult issues that have not already been addressed.

Support System:

As a framework develops, we could have a way of lifting support tickets that make it easier for both product makers and for designers to join in the process. @GBKS I know you already have some thoughts on this.

Learning from one another:

• Learning about the stories and purpose of product makers
• Listening to their specific issues and their hopes for improvement
• Developing ways for designers to join in the process
• Helping design smoother user experiences
• Using a growing knowledge base on how to handle bitcoin specific issues like how to solve issues even when not knowing audience information because of a privacy based foundation
• Guiding to existing examples and creating practical solutions with specific deliverables based on needs and wants
• Support a feedback circle so as to offer design advice and receive feedback in ways to improve our methods

Guide future projects:

As parts of the process are addressed, it should make it easier for product makers to find examples of solutions, for designers to guide product makers to specific examples, for designers to find ways to contribute, and to build a culture of support for current and future issues not only on design but on principles.

Practical solutions

Types of resources that could be created and openly shared:

• Mock-ups
• Prototypes
• Design files
• Open source libraries
• Good UX examples
• Mistakes to avoid
• Branding recommendations and ways to customize products in order to infuse personality
• Ways product makers can discover and build on their purpose

Goals to encourage in product creation:

Any other goals or thoughts about this entire process? @danielnordh you've thought about some of these issues, could you help me with the same question you asked me, is there something missing?

Guiding users:

• Creating progressive journeys, both in terms of security and education
• Encouraging financial health and bitcoin education

Protecting:

• Shielding people from problems and mistakes like loss of funds
• Offering specific solutions to make some of the best practices a default standard. Understanding the responsibility in product making, choosing best practices instead of leaving choices to people who may not know what is best for their situation.
• Encouraging inclusion and accessibility
• Keeping in mind empathy, access and privacy

Enhance:

• Focus on simplicity and ease of issue
• Encourage friendlier products

Guiding Principles:

(From conversations with @GBKS @ConorOkus @danielnordh @johnsBeharry, and personal thoughts)

No loss of funds
Progressive security & education
Interoperability
Permissionless products (Access for all)
Empathy
Decentralization
Privacy
Financial Health & Literacy
Self-sovereignty
Autonomy

---

As designers, sometimes we are standing on the sidelines, trying to figure out how to help. We should proactively cross bridges to connect with product makers in order to build a framework that can serve as a support system to address issues directly and to help build practical solutions that can be replicated and customized. We can become a direct resource where ideas are sprung and reshaped in the open, helping improve the entire bitcoin ecosystem. We can help create a culture of cooperation and support that leads to constant bitcoin product improvements, and that opens channels of communication that can be especially beneficial when problems arise. The focus should not be in creating one product, but in creating a foundational design process for products to be built upon following best practices.

Buidl It Bitcoin Strong.

I have tagged a few people, but if you are coming across these words and do not find your name here, please know that your comments on improving the way we go forward is always welcome, and any contributions are always appreciated. Thank you.