Superbloom

Being a designer in Open Source (OS) isn’t always easy or straightforward, neither is it the same for all designers. Different open source projects are set up differently, hence demand different outputs and engagements from designers. In this blog, we list the six main tenets for a successful design contribution to OS projects.

Designers in Open Source may have their own reasons to be a part of OS, but if you’re new or still figuring out why you want to be in OS and how to make your way in, there are many helpful resources such as:

  • This blog post written by DesignerUP which introduces the reader to Open Source, areas of contribution for designers in Open Source, how to find a project, mistakes to avoid and lots more.
  • This guide which details the context required to contribute, and walks you through how to contribute to Open Source.
  • This article, which lists a number of Open Source projects, each with a brief description, and goes on to talk about why you should contribute to Open Source.
  • This article written by Victory Brown details some of the cultural and community aspects of joining an Open Source project for the first time as a designer.
  • And this talk by Abigail Makolo speaks about her experiences of contributing to Open Source as a designer and the “hacks” she learned.

There’s a reason why we’re still talking about why and how to contribute to Open Source which is about a lot more than becoming a better contributor or designer within the Open Source ecosystem. This is because the Open Source design community isn’t at a scale that can sustainably respond to Open Source design needs. There are still very few designers who have reached a stage where they feel comfortable cold-approaching an Open Source project to offer their contribution. These designers continue to self-learn and borrow design practices from the for-profit world and adapt it for Open Source and human rights centered design. Design in Open Source and Human Rights is an evolving practice that is slowed by the limited resources offered.

Though this is a difficult space in which to practice design, we have compiled six tenets for designers to keep in mind when contributing to or working in Open Source. Although these can benefit any designer, they have been structured and written from an Open Source design perspective:

1. Center the users in your thinking

Users are the reason we produce design. Everything we produce is centered around solving the user’s problems. There may be users we don’t have an opportunity to interact with, especially for those of us who aren’t full-time designers on an Open Source project. To overcome this, we can try to learn user perspectives from “support issues”, user forums, project communication channels, such as Slack, Discord, Discourse etc, and even from developers and other team members who may previously have interacted with the users. Learning about users means making design decisions about our Open Source Software that makes sense to the users. The continued return on design effort investment is expressed in the form of features and commands being more regularly used and contributed to. The more detail we have about our users, the better decisions we can make about our designs. User needs aren’t only about designing a working solution within the technical or usability bounds of the software but also about considering their security, privacy, inclusion, accessibility, and diversity needs. Those users who belong to the edge cases (or stress cases) for a product, or even those not to design it for. The only way for a designer to make these considerations a regular part of their work is to learn and practice them continuously. When we don’t, it is not easy to make it a part of the design process as it’s not included in our project planning, estimates or conversations with stakeholders. Ergo, it will be difficult to uphold why these considerations need attention and how they support product/business goals. All users are important users of Open Source Software, whether it is the people that use the tools, coders, designers or contributors, therefore we must keep in mind everyone that is affected by our work.

Example:

A GitHub issue for an Open Source project did not list any details or provide clarity about user behavior required for the design. As designers, we elaborated on the issue and added more context by bringing in users’ points of view via user stories and their journey using the product. Detailing a GitHub issue in such a manner is a valid contribution to the project and it shows that we’re thinking about the users. In another case, we ran a user journey mapping exercise to discover specific pain points and moments when the product could intervene in a users’ life to solve their problem. Designing around such moments is a great way to make our design contributions to Open Source Software user centric. 

In another example, here’s a talk by Abhishek Sharma about working with users while designing an Open Source product.

2. Learn the ways of a developer

Wait, why are developers in second position? The collaboration and respect between designers and developers is critical to building widely useful Open Source Software. Developers perform an essential role because they implement design solutions, add technical constraints or opportunities and bring design concepts to life for the users. Learning about how they work and what is important to them makes us better design contributors, and we can learn a lot from them, especially if they’ve worked with other designers.

There are some things we can only learn by working with developers, such as understanding the feasibility of our designs with the tech stack the product is built on. There’s little point getting into a debate or argument with a developer about why our ideas are the best solution for the users when the complexity and effort needed to build within the current tech stack hasn’t been considered. Developers will always have multiple priorities, therefore we must create design alternatives that work well for users and that are feasible to develop. We need perseverance for some ideas more than others to help the developers understand and agree to build them. And sometimes we have to totally revise an idea. All of this is a part of product development (regardless of whether it is Open Source!). The best solution always wins and it’s not about us versus the developer.

In our product experience we try to keep a healthy mix of finding alternatives and pressing for an idea. Shipping a feature or solution is the most essential part of the job so that the product is useful. We frequently need to work with developers to iterate on an idea — this means that the most usable or ideal version of an idea won’t be shipped in one go; rather it is shipped in multiple release cycles. It’s normal to wait up to two years for a feature to go live in Open Source Software! 

Working with developers isn’t just about handing off our designs, it’s about building a partnership with them. In many cases we may not be able to interact directly with developers, and we need to make sure our ideas are explained clearly in writing (or via a recorded video of our screen while explaining the design) to facilitate hand-off of our designs. This should include a detailed description of the solution with comments, annotations and prototype, along with our assumptions and user considerations. This should be done in such a way that developers can understand the journey we’ve taken to arrive at a solution, and shouldn’t require a live presentation of our work. Developers who have worked with other designers are able to understand where we’re coming from even before we have explained ourselves. They will appreciate our work, be able to provide constructive criticism and understand our point of view. If they haven’t worked a lot with other designers, they may only be able to share their own perspectives which can still be useful if we learn or ask questions about why a design feature is not possible. Most of the time we will find a solution that the developer and we are both happy with. At the same time, it is sometimes frustrating when we’re unable to implement ideas in the way we want. In these moments work collaboratively to find a solution both parties agree with.

Examples of Superbloom’s work with developers in previous projects: 

  • Using the “Five Whys” method, we used this Superbloom resource “Synthesis for Open-Source” to help developers undertake various user centric tasks such as user testing, recruiting users, planning, and operations, to synthesize findings from users. This resource is not about getting developers to do design work, rather, it’s part of a collaborative effort to sensitize each to one another’s processes. 
  • During the research phase of our USER project, we discovered various points of view and patterns around how scientific Open Source projects and the developers working on them view usability and design. The project investigates the conditions that enable scientific open source teams to prioritize and focus successfully on usability.

3. Think about assets and design documentation

This is how we can get our ideas and solutions across to developers, users, product managers or any other stakeholders we’re working with. It includes our:

  • Penpot or Figma file
  • Documentation of user stories
  • Communicating on GitHub or other channels
  • Measurement metrics
  • Assumptions and considerations
  • Documentation for another designer to collaborate

All of these help to explain our design specifications, why the design works and how someone can contribute. Assets also include our design systems, grids, components, and everything else we create for a handoff to developers or other designers. In our experience it has been a valuable investment to set up component libraries and design systems at the start of a project even if it’s just one component. It doesn’t have to be a complete, extensive, all encompassing design system at the outset. It’s about laying down the foundation with our atoms and molecules (Brad Frost’s atomic design) in place. We can always go back and edit as and when the designs change, however, it is useful to set them in place so that we don’t have to spend a lot of time managing changes across our design file even for minor changes. If we aren’t building a custom design system for a project, we can also benefit from Open Source design systems such as Material UI Design or paid libraries. Today, really advanced tools such as Penpot (an Open Source prototyping tool we can use in a browser), or Figma, enable this type of work and these tools are always being improved. Therefore, make all design assets easy to read, understand and access by anyone — there’s usability to our assets too! We may even user test it if we’re really driven to produce high quality work.

Here’s an example of documentation that enables designers and other stakeholders to navigate and use a design file. This documents the team structure, areas for contribution, and even some instructions for collaborating in Figma!

In another instance, we helped discover insights about the requirements from a user perspective by talking to users and updating GitHub issues. This asset helped everyone involved in the project to make the right product decisions.

4. Think about other designers

Early in my career, I designed with the sole intention of communicating an idea to a team and developers by putting together screen grabs and annotations, or only designing a part of the screen, as if there was no need for the UI once it was built and added to the product. I soon realized this was a very short-sighted view of my design contributions. This method made it hard for other designers to use my designs, and made it challenging to reuse them or build on top of them. I took this approach because:

  • I didn’t have the required time or budget to do the design properly
  • I wanted to optimize the design process and work for myself
  • I didn’t know the bigger picture of the product and the extent of contributions required from me
  • I didn’t have opportunities to collaborate with other designers

It’s good to design on the basis that we may not contribute to a project forever and therefore set up the designs in a way that we can easily pass the baton onto other designers. This connects to the previous point about how we set up our assets and documents. When we step outside the established “norm” of designers being solo creative geniuses, and look at a bigger, collaborative, co-designed picture, our actions and approach towards the project changes. We start paying more attention to documentation, asset creation and keeping our work clean and proper at all times. Thinking about our designer community also makes the project more sustainable from a design perspective. This means that we may have to size up the project and estimate the number of tasks, and how long they will take. With a little practice, this becomes second nature.

Thinking about other designers enables us to be welcoming to them and may also help onboard and mentor them or learn from them ourselves.

Example: Here’s a talk by Eriol Fox about how they enabled onboarding of designers into OSS.

5. Think about the product, business and domain

In a Superbloom research project, we found that one of the foremost roadblocks or challenges to valuable design contributions is a lack of understanding of the domain, business and users. For example, a designer contributing to a scientific research OSS in biochemistry must also understand a few things about biochemistry and how its users, the scientists, work. Each domain has its nuances and may require different design principles and approaches. It’s not something that can’t be learnt but it can be demanding. A designer’s work is not just about the screens and User Interface, we help people achieve their goals. Therefore, from a goals perspective, it’s crucial that OSS designers understand what is feasible to build and how to build it. It may not be easy to find designers who are familiar with the subject matter and so it becomes a product team’s responsibility to nurture a designer in their domain. A designer must also decide which domain, product or business they wish to contribute to. It’s worth considering which domain we want to work in long term, for example, messaging, productivity, social tech, healthcare, scientific research etc… so that we remain interested even when we change projects. But for those getting started, start anywhere! There are many opportunities and we can always change our trajectory later!

6. Think about the community

A community approach and building together is at the heart of Open Source Software (not just for coders!). This may seem like an extension of thinking about the users or other designers, but there’s more to it. It manifests by creating resources for the community, sometimes beyond our OSS design team and domain. We can create learning materials, design systems, a components library, illustrations etc. For designers who may be starting out — it’s never too early to think about the extended Open Source community. To those more focused on their career and growth, — it’s never too late! 

There are many other ways to contribute to the community e.g. participating in community events, networking with others, sharing job/work opportunities, adopting, translating and localizing resources for your region, exchanging ideas and learning with community members.

Example: 

Both Open Source Design and Superbloom have channels where many folks from the Open Source community hang out, interact and participate, and the Sustain Open Source Design podcast is a space to talk about OSS experiences.

***

To sum up, it may not always be possible to balance these six tenets at all times during our work, but to make our contributions long lasting and sustainable, we have to keep trying!

Credits: Abhishek Sharma, Eriol Fox