Challenges designers face contributing to open source projects

[johnsBeharry]

bitcoin.design/project lists some stellar projects but I've realised its still quite difficult for designers to know how to contribute or what to contribute that would add value to the project.

#design-review calls that @ConorOkus hosts are a great avenue for designers to contribute their first impressions - but there could still be more designer engagement after the calls.

Usually projects would have a CONTRIBUTING.md for developers to help them understand the process of contributing.

I propose we create a template for CONTRIBUTING_DESIGN.md so the projects can help onboard designers.

Looking to hear experiences of regular contributors, anyone considering it, or have tried to contribute.

Should also note that @Bosch-0 has started a project which is addressing this very issue for @bitcoin-core which is fantastic -- how can we scale this up?

[GBKS]

I think there are a few different angles here:

1. New designers figuring out this bitcoin thing in general
2. Getting designers to be active in the bitcoin design community
3. Getting designers to be active in Bitcoin open-source projects

For 1, the Guide is great, and also having the Slack to ask questions and discuss.

For 2, we have the Slack, design review calls, newsletter, @pavlenex video playlist, the #introductions channel, etc. There's also the "Contribute" page and the proposed "Open design collaboration" page.

For 3, we have the "Projects" and "Open design" pages and there's a lot more we can do. We can outline good design workflows, from brainstorm sessions to design reviews and implementation best practices. We can also create more channels to connect designers with projects/teams. Some case studies (like what Bosch is doing) could help, too.

I'm sure I missed a few things, but I agree that thinking through this systematically and finding ways to experiment, improve and evolve what we do is the way to go.

One good way to go about this is to put yourself in beginner's mind (forget everything), pretend you just heard about the Bitcoin design community for the first time, go to the website and start reading and browsing and see what works and where the holes are. And we can also ask newcomers to see what their prior experience has been like.

[johnsBeharry]

The design community is a great entry point if we have these resources and I especially like the idea of case studies. This solves a problem of newcomers not knowing whats out there in the ecosystem.

There are also designers who come in from wanting to contribute to specific projects which they may already be users of - but they don't have the processes in place to support design contributors, which makes it feel intimidating (that feeling of "im doing it wrong").

[GBKS]

As you mention case studies, I think one good additional approach is if designers can keep a bit of a journal of their work. It lets others follow along (or look back) and get a real sense of what it's like to do this stuff.

[ConorOkus]

After half a dozen or so #design-review sessions would be good to get some formal feedback. General feedback has been very positive but I want to spend some time over the Xmas period thinking about how we can make it even better. Tempted to throw together a short Google forms survey and get some responses that way.

We should reach out to some of the projects we have recommended and ask them how they would like to integrate design contributions?

[GBKS]

I think that's a good idea (both the survey and direct conversation).

[pavlenex]

In my experience, it's best to have a person in FOSS who can have 1:1 discussions with designer and onboard them slowly. Often designer isn't aware of the underlying of certain decisions and may suggest changes that are too radical and aren't really a priority for the project. That often causes discomfort on development side and then the resistance to change/suggestions increases because certain design decisions can can cause entire code-base restructuring.

Best way imo to onboard a designer, is similar to any other FOSS Involvement, start slowly, ask, learn and listen. Get involved and ask questions so that you can understand the why before you suggest the how. Also it's crucial to understand the priorities of the project. Good documentation and videos can help, but it's always best to connect with someone from the project and ask to demo things visually while explaining the software.

I think @dstrukt posted really good overview few weeks back on Slack. I will screenshot so we don't lose this valuable feedback.