Methodology.md

Methodology: How Open Design will work.

Principles for OSD.

• Open Design embraces X centred design (X = the most critical factor of the project. This could be ‘Human-centred design’, ‘Environment centred design’ or ‘Democracy centred design’ etc. the X is replaceable with the descriptor. An example would be climate change projects. Where the ultimate beneficiary is environmental sustainability and not necessarily humans.).

• Open Design amplifies attitudes, methods, tools that are geared towards collaboration instead of competition, as well as a learning-based, mentoring approach.

• Open Design encourages inclusion, low participation thresholds, and peer governance (free and communal validation of quality) thereby avoiding contributor burnout and design by committee (such as groupthink and hive mind) which are risks commonly associated with open source creation.

• Open Design is a multidisciplinary, intersectional and inclusive space.

• Open Design advocates for transparency, accountability, and flexibility.

Open Design as events.

Conduct a series of events (and propose a replicable structure to the events for the community to take forward) that uses with TenFour, Ushahidi’s 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.

To test we intend:

1. To build a community around a real life humanitarian OSS project (in case of the Open Design project 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 Ten Four 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. Inviting ‘Witnesses’ to be part of the process: Witnesses are people that have direct experience of the crisis scenario we are trying to solve in the Open Design workshops. They are there to build deeper understanding of real life experiences of a humanitarian need.

4. 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.

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

6. 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.

7. 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.

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

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

10. 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 organisations (or other entities) that run/own OSS to roll out similar problems and gather data and add to our findings in different context.

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

Testable Criteria.

Open Design events must include:

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 organisation, the organisation 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 projects 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/video being taken from them they should make it explicitly clear to organisers .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 organising 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, usertesting 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/organisations 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’ centred design.

17. Team structures must be collectively decided and agreed upon within the team. If facilitation is needed, the team organising the event should facilitate or help organise 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 signalled 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 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 criminalised 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 made 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 teams support and the relationship then exists between the OSS and the designers.