The goal of this document is to define common types of collaborations, to serve as starting points for new inquiries. Collaborations should be tracked as issues with the "collabration" label, see the current ones here.
This is not meant to be a strict rule set. Every project is unique, and healthy collaboration requires everyone involved to be sensitive to the projects needs and goals. Our own goal is to support projects and contributors to improve their products and design practices (and not impose our ideas).
Here are six types of design needs a project may have.
An existing project is looking for resources and expertise to improve their product's user experience (and potentially design process).
Ways the project can choose to interact with the community:
- Review the guide to find a direction or solution
- Engage in Slack conversations to share ideas and get feedback
- Participate in a design review session
Our role in this scenario is to be a helpful partner in providing resources and feedback.
An existing project has identified a problem they would like support with and is looking to the community for help resolving it.
For example:
- Perform user research to inform their future plans
- Analyse the current user experience and propose improvements
- Solve a particularly complex UX issue
- Establish a design system for an application
- Improve the onboarding user flow
- Design a website
- Revise logo and brand
In addition to the options in #1, the team can also create a project brief to start a deeper collaboration. The brief should include the following:
- Introduce the team, project, its goals, constraints and design process
- Explain the issue to work on
- Outline ideas for collaboration
- Identify next steps with members of the community
We can share the brief with the community to find contributors.
Solving single problems usually means to work within the current project framework. Bigger discussions around design processes and other improvements can be had, but the scope of work would be to resolve the specific problem that was brought up by the project team.
An existing project is maturing and wants to improve the overall design, which may also means finding a designer and adopting design processes.
The term redesign is often used too quickly. Many times, it is better to systematically improve the existing design than start from scratch. This should be carefully considered.
Steps we can take:
- Identify goals and vision
- Examine the current state of the project
- Compare vision to current state
- Break down work-to-be-done into manageable parts
- Example:
- Refine brand
- User Interface audit
- Create a UI style guide
- Implement UI style guide (without touching interaction design)
- Revise individual application screens and user flows one-by-one
- Example:
- Prioritize
- Consider whether to start with the application or the website
- Consider level of effort for each change
- Consider availability of contributors
- Consider time to adopt new workflows
- Plan collaboration
- Good idea to start with a design review to present the project and create initial interest
Designers who want to tackle redesigns should ensure they have the availability to regularly contribute for longer periods of time. How much time is required depends on the scope. In addition to designers, having a dedicated project manager available to help with planning and communication is also helpful.
This is an opportunity to adopt a good design process from the start, beginning with researching product concepts, target audience research, etc. New projects likely also have other foundations to lay, so designers need to be flexible.
Similar to redesigns, a team of designers (and a project manager) is ideal to tackle new projects. Once the design foundation has been created, that need will shrink.
Some projects want to expand their team by bringing in dedicated designers. As designers are often individual contributors with a unique set of interests, experience and availability, this can often be a longer, more gradual process.
Simplified designer life cycle in a project:
- Observer
- Sees if there are opportunities to contribute
- Decides whether contributing is “worth it”
- Ideal if there’s an identifiable go-to person to help get started
- New contributor
- Has identified an area of improvement
- Needs guidance on how to contribute (tools, processes...)
- Should feel welcome and get satisfaction from contributing
- Occasional contributor
- Helps when issues arise
- Dedicated contributor
- Initiates design improvements
- Core contributor
- Helps shape overall design and design process in a project
Our goal is clarify what type of design support the project needs, create visibility for the "opening", and help onboard designers.
As projects grow and their processes evolve, they may come to a point where they want to improve how they practice design and attract designer contributors. A designer may already be part of the project, but design contributions have been irregular and unstructured (which is fine for smaller projects).
Steps we can take:
- Understand current status and design needs (possibly via a design review session)
- Understand project workflows by discussing with the team
- Recreate application in a design tool as a baseline. This can be done partially, focusing on the areas that are being worked on
- Start exploring new changes/features in design first and use those on Github, etc to discuss and make decisions
- Build and evolve design system over time
What makes for a good design process:
- Using design to preview and discuss before implementation
- Having well-organized design files
- Everybody in the project having access to design files
- Clear understanding how design moves to implementation
- Close collaboration between designers and developers during implementation
- Developers and designers regularly communicating and being comfortable with each others way of working
- Designs and developers involved (to different degrees at different times) from start to finish
- Open forum for design conversation
- Regular user feedback (forums, issues, user testing, analytics, etc)
- Design decisions based on rationale, not “feelings”
- Priorities are based on user needs
- Focus on specific user groups, and a deep understanding of their specific user needs
- Having a clear problem statement
Project design process life cycle:
- No design process
- Design is typically the outcome of development-driven activity
- Loose design contributions
- Design suggestions happen but without much structure
- Designs done by anyone (good and bad)
- Patchy design implementation
- Structured design contributions
- Design system is getting built
- Dedicated communication channels for design
- Regular design calls/meetings/discussions
- Mature design process
- Design system implemented
- Clear process the team is comfortable with
- Consistent iteration
- Conversations within our network
- Prompts on the Projects and Contribute pages
- Proactively looking for design needs (Twitter, scanning project issues...) and reaching out to projects
- We improve real-world Bitcoin user experiences
- It allows us to validate our ideas by putting them to the test with real needs
- We will identify new problems to solve
- We can help designers get more experience and find projects they are passionate about
- We allow projects to build better products
- Learnings can flow back into the Bitcoin Design Guide
This is ultimately up to the individuals who are volunteering their time to decide, so the following are simply recommendations:
- FOSS over OSS over closed source
- Non-profit over commercial
- Self-custodial over custodial