Conduct a series of events (and propose a replicable structure to the events for the community to take forward) that uses TenFour, Ushahidi’s Open Source Software (OSS) crisis communication tool as the experiment example, that when an OSS tool has a humanitarian purpose, designers are more likely to engage with the OSS product.

As well as the OSS having a clear and relevant humanitarian need, if a community is briefed, engaged, aligned and in possession of the right collaborative tools, designers can gracefully contribute, evaluate and lead remotely in OSS projects to the same extent as they would in proprietary software projects.

1. To build a community around a real-life humanitarian OSS project (in case of Open Design this is Ushahidi’s TenFour) with designers interested and willing to contribute and give feedback on the tools and processes through their involvement. To build up a critical mass of participants for the above we conduct two in-person workshops where we engage and enable interested designers by a mixed set of methods.

2. Immersion through storytelling: We build empathy with users of TenFour by developing a visually enhanced story around a realistic disaster scenario. This is supported by people who have experienced the OSS’s primary humanitarian purpose that we call ‘Witnesses’. Example: A Witness for TenFour can be someone who was in a city at the time a hurricane hit.

3. Well defined challenges: Using existing issues, features or epics in an OSS repository, we work with our ‘Witnesses’ and the owner of the OSS to choose something which is beneficial for the humanitarian need and that has sufficient design scope to involve multiple groups.

4. Guided ideation: We help to build teams and guide them through a structured ideation process to ensure we use design as a system challenger.

5. Tooling: we provide online-based tools (a design system and support with tooling) to manifest ideas and learn how to contribute remotely and distributed as well after the events.

6. Post-event: We build a post-event design-sprint based system to foster engagement and provide a communication channel and contribution platform to further contribute after the event.

7. We provide a structured evaluation method and tool for attendees to give feedback on the process after the event and during the contribution phase.

After the initial build-up of the community through the three events, we closely monitor the feedback and foster growth of the community through the use of digital channels, online communities, and engagement in the relevant discussion. 

In the last phase, after a first idea of the success/problems with our methods and tools become evident we engage with more non-profit organizations (or other entities) that run/own OSS to roll out similar problems and gather data and add to our findings in a different context.

Design contribution isn’t purely about scaling an OSS product capacity. Needs related to scaling will need wider engagement across skill sets such as product management and business development which are on the edges of what Open Design can offer OSS.

1. An in-person event in a local area is useful but not essential. The in-person event must be in an accessible venue (for people with impairments).

2. If hosted by an organization, the organization must have read the Open Design code of conduct and agree to uphold the principles of Open Design while engaged with the project and process.

3. If an in-person event is not possible, there must be an accessible, virtual event where teams can meet and collaborate together. This must use a virtual method that is accessible.

4. An in-person group must have a code of conduct and an agreement to collaborate together. Both should be available to view online and in-person. This must include the project’s commitment to Personal Identifying Information (PII) and how PII is handled and stored.

5. An in-person event must include a right to record/document signed by all participants. If people have reservations about pictures/videos being taken from them they should make it explicitly clear to organizers. All participants reserve the right to not be recorded. The reason we do this is e.g. we do an event around LGBTQ+ OSS in a country or with a participant whose country of origin is criminalized. By releasing video/photo of this they are put in danger. 

6. A leader/facilitator in the organizing group must be established through consensus.

7. The leader must also have an understanding of the specific OSS to be worked on. This person must be able to accurately and adequately explain the purpose of the OSS, user base, needs, and priorities.

8. The event focus must be on well-defined, tangible issues that need addressing in the OSS.

9. Events are best for issues that explore an extension of an existing feature in a new way, a new feature that needs design thinking/exploration, and/or a feature that requires physical understanding of the feature used to be effectively designed.

10. An introduction to where the OSS project is hosted (Example: GitHub, Gitlab, Forum, Website, etc.) must be released pre-event and covered at the beginning of the event.

11. An intro to the OSS must be done at the beginning of the event. Example slide deck

12. The ‘features’, ‘issues’ or ‘epics’ needing focus must be ‘challenge’ based. Example:  “TenFour is a crisis communication tool for teams to get in touch with each other remotely using messages called ‘check-ins’. There is currently no way for people using TenFour to broadcast a ‘status’ to the wider team independently of a ‘check-in’. We’d like to investigate the ways in which this can be implemented as inclusively as possible and as well defined as possible. This could include multiple issues describing what needs doing e.g. research, cataloging design, UX, UI, graphics, user-testing, etc. as well as the limitations that the designers are operating within constraints such as  there is no ability to A/B test.”

13. For virtual events or such that offer remote or asynchronous participation, there must also be ‘solo’ issues available within the chosen ‘feature/epic/issue’ in order to enable contribution from across time zones and work availability. 

14. It is encouraged to invite already existing ‘teams’. Example: The team at ‘Corporation X’ has an on-staff researcher, UX designer, graphic designer, and product manager, and they join the event as a team.

15. Existing teams at companies/organizations can attend the events and work together but it is encouraged that they attempt to fill a skill/function gap. Example: The team at ‘Corporation X’ has an on-staff researcher, UX designer, graphic designer, and product manager. But does not have a prototyper on staff. Therefore, they must look to other attendees at the event to fill this gap.

16. The groups at an in-person event should be able to collaborate effectively together and feel as though they are contributing effectively. We acknowledge that everyone has a ‘design’ opinion and that the focus of the project must be ‘X’ centered design.

17. Team structures must be collectively decided and agreed upon within the team. If facilitation is needed, the team organizing the event should facilitate or help organize facilitation.

18. Where volunteered, participants can establish a ‘mentoring’ process where someone with experience and/or proficiency in a given area can support someone who has signaled the need for development in this area.

19. Where available a group or individual who has been affected by the problem the OSS is trying to solve should be present at an event. Open Design calls these folks ‘Witnesses’ Example:  If the OSS attempts to solve an issue around earthquakes, a person who has experienced an earthquake should be present to add insight and context.

20. Mitigate the use of design jargon and allow for specific, relevant insight into the feasibility of a design ‘solution’.

21. Assume that everyone has an unfamiliarity with a certain tool and/or process. Provide sample contribution management to participants through a combination of recommended tools and processes. 

22. An ideal research+design+dev workflow defined by the OSS project must be available. It is suggested but not mandatory to follow. However, your design contributions must be contributed in a way that the OSS project can use it.

23. Where available, a person who has worked on or involved in the development and coding aspect of the OSS should be present to discuss the feasibility of implementation. Example:   Developer, OSS owner, product manager.

24. An in-person event strongly suggests the teams agree on a method of online/virtual communication that is secure and end-to-end encrypted (Telegram, Signal, Email, Whatsapp) for groups and attendees to communicate pre-event, during and post-event. This communication method must be safe and not criminalized in the country that the event occurs.

25. Adobe XD is Ushahidi’s design and prototype tool of choice. TenFour is designed using XD and TenFour’s design system is made available in XD format. XD is available for multiple common operating systems, is optimized for performance/does not require powerful/expensive hardware, works in both offline and online environments and is graceful in flaky internet uplinks/limited bandwidth, enables prototyping for voice-only- and multi-modal interfaces without requiring any upfront knowledge, and is available as  a free to use design, prototyping, sharing and communication tool. The free version of XD does not introduce any constraints that would block any of the intended outcomes, suggested practices or team sizes. 

26. The CoC or right to record has been breached should be followed for each event

27. To enable the participation of remote participants the event should be webcast and recorded where available and appropriate. In this case, individuals’ rights to be protected must be respected and all recordings must be stored in a secure place. GDPR compliance must be observed.

28. The event should be documented and the process and outcomes should be made publicly available on the property of the OSS.

29. Where appropriate, research/results, documentation, and recording must be made publicly available on the Open Design property. GDPR compliance is essential.

30. Time should be given for participants to collate, collect and translate their process and outputs into a digital format. This documentation should become part and are publicly available under the above terms.

31. There must be a way for the OSS project to contact participants to be able to clarify any design details within a reasonable time frame.

32. After the event, there will be a ‘design sprint’ where participants to an event can continue to work for an advised 2 hours per day for 7 days. 

33. After the events, teams can continue to communicate on further design sprints to make any extended progress on their feature/issue/epic but this is outside the scope of the Open Design team’s support and the relationship then exists between the OSS and the designers.

1. Foster design to OSS engagement.

2. Foster OSS to design engagement.

3. Foster the understanding of the role of each other.

4. Can use and adapt the Open Design code of conduct and policies. They must follow the CoC for the community and the CoC for contribution.

5. Embrace a variety of skills, knowledge, background, demographics, leadership and time commitment.

6. A dedicated lead from either the OSS project internally or an appointed contributor with an appropriate knowledge base to make decisions on key issues and take learnings and feedback back to the OSS project.

1. There will be people that have an in-depth understanding of a type of user, geographical area or industry, that will be able to contribute deeper insight than those not knowledgeable on this subject. These people will typically tackle an issue that has not time-bound frame and requires research and investigation to discover a design solution.

2. There will be people that can offer insight but not time. Therefore, there should be a way in which these people can offer insight that is smaller time-bound.

3. There will be people that can only offer small amounts of time to help and there should be issues able to be completed in under 2 hours.

4. There will be people that have certain skill competency (self-described) and will only want to assist in that skill competency. There are also people that work across competencies Example: A design able to contribute both UX skills and UI skills.

5. There will be people that are not competent in a skill, but want to help on an issue that they can gain mentoring and support from a competent skilled professional.

Want to contribute to the Open Design methodology? View the issue on Github and offer suggestions in comments or make a pull request to make changes directly.

(Free) Open Source Software (OSS, FOSS) – Software that is typically available to many for free or very low cost depending on what the software entails. Open by default in that there should be no or little information that is not accessible by anyone.

GitHub – A company that provides hosting for software development version control using Git.

Git – Git is a distributed version control system for tracking changes in source code during software development. It is designed for coordinating work among programmers, but it can be used to track changes in any set of files.

Design – The way a product or service is planned and executed.

UX – User experience. The part of a product that focuses on what the experience is. Typically a blend of research, insight and building a ‘journey’ or ‘process’ a user takes through a product or service.

UI – User interface. The part of a digital product that a user interacts with. Typically comprising of buttons, text, forms, menus and now voice, touch, VR & AR.

Graphics – Visual assets typically created by a graphic designer or designer.

Issue – A feature of the product/technology, piece of work or ‘issue’ described typically within an open-source GitHub repository where work on a product/technology exists.