The designer in OSS.

As an ongoing part of the Open Design project,  Ushahidi is conducting interviews with Open Design leaders in various industries all over the world. The aim is to learn from their experiences, including the barriers and challenges they faced and possible solutions, as well as what they think or have found that can make designers successfully contribute to the creation of Open Source Software. We also wanted to know about what they found to be easy and how they think those successes can be replicated. This article covers what we’ve found so far.

To contribute effectively to Open source software, designers must learn to work well with other people and be willing to invest their time into developing and improving the product. It’s a marathon, not a sprint. Collaboration can be hard in the design context, but to successfully contribute to OSS, designers must learn to embrace a collaborative mindset and let go of the competitive mindset of design contests.

It’s often difficult to give credit to every single person involved in the creation of OSS, for this reason, designers should be willing to not require credit if they want to contribute. A designer working in OSS should have the mentality that anyone can do whatever they want with the work that they produce. They have to be okay with the possibility of not seeing what other people do with it or how it evolves. With this comes a level of trust in the OSS project owners and future contributors to iterate in ways that are respectful, logical, and relevant to the OSS software. Other benefits they might get instead of direct credit include:

Internet culture grows, explores and expands on media and projects through ‘remixing’ and designers who want to participate in open design must embrace this mindset and be willing to let go of control of their work. For example when designing the Simple.org logo, about 50 designers initially contributed ideas and perspectives and then 2-3 designers refined it, after which the project owner finalised the design.

Likewise, OSS projects must begin to understand how to value design contributions for what they can offer a project.

Designers contributing to OSS also need to discard the idea that the design work is never really done. There is someone (usually the project owner) responsible for deciding that “okay this is done” and close the issue–whether it is designing the UI or creating a logo or brand assets. The Project Owner usually has a deep understanding of the OSS project and understands the value of design contributions. For example, an OSS project that makes an app for refugees seeking legal help would have a Project Owner who has real, tangible experience of the myriad of needs that a refugee has, as well as the aim of the OSS project (app design) and knowledge of legal subjects.

While most people think of interfaces and visual design first, there are so many more ways in which designers–and even people who don’t think of themselves as designers, including photographers, videographers, and motion designers–can contribute to the design of Open Source Software.

Designers can collaborate to create design systems, including copy and style guides as well as assets such as templates, illustrations, graphics, and photos. They can also contribute to branding the OSS, creating tone of voice and identity. They can conduct interface audits or usability tests to identify UI and UX issues and provide recommendations. Conducting user research to gather user requirements and problem statements and create scenarios, user stories, user flows and so on are other welcome contributions to OSS.

Besides explicit design tasks such as the ones listed above, contributions can come in the form of providing knowledge to the design process. Simple.org is currently taking this approach and gathering contributions from ‘Swiggy,’ a delivery tool in india to understand what great customer service management/delivery looks like.

Designers can come together at in person events such as design jams. These events should have a leader who has a deep understanding of the OSS to be worked on, and it must focus on tangible issues that need to be addressed in the software. Some ideas that can be explored include:

To be truly user centred and empathic, they should try as much as possible to have at least one person directly affected by the problem the OSS is trying to solve present at the event. An alternative is to create structures, initiative and confidence to undertake immediate user testing of the OSS design contribution with people from the user group. They should also try to involve at least one developer that is already working on or has worked on the OSS.

The outcomes of this event should then be collected and shared in a central repository accessible to other people involved in the creation of the open source software. This is essential because transparency of the design process, thinking and research, and the availability of all these in an Open Repository is not only ethical but also useful for remote collaboration and future design contributions.

To ensure that they can contribute successfully and effectively to OSS, designers need to embrace building on top of each other’s work and let go of the need to get credit for the design.