├── tenfour-master-xd-file.md ├── skills-list.md ├── Open-Design-and-design-tooling.md ├── codeofconduct-contributing.md ├── witness-brief.md ├── README.md ├── designer-contributions-to-OSS.md ├── The-designer-in-OSS-article.md ├── Bangalore-workshop.md ├── Open-Design-2020-Update.md ├── Taipei-workshop.md ├── codeofconduct-community.md ├── TenFour-ready-for-design-contributions.md ├── workshop-framework.md ├── Launch-article-June-2019.md ├── Methodology.md ├── license ├── translating-issues-to-design-challenges.md └── events.md /tenfour-master-xd-file.md: -------------------------------------------------------------------------------- 1 | # TenFour master XD design file version control 2 | 3 | Master XD folder located here: http://bit.ly/TenFour-master-XD-folder 4 | 5 | Master XD direct download file located here: http://bit.ly/tenfour-xd 6 | 7 | Master font files located here: http://bit.ly/tenfourfonts 8 | 9 | ## Version control 10 | 11 | * Master file linked/uploaded by [Eriol Fox](https://github.com/Erioldoesdesign) on 7th of December 2019 12 | 13 | * Master file linked/uploaded by *Type your GitHub username here and the date.* 14 | -------------------------------------------------------------------------------- /skills-list.md: -------------------------------------------------------------------------------- 1 | ## A list of Skills that people listed in the Open Design Workshops 2 | 3 | ### I can do 4 | 5 | * Politics 6 | * UX Design 7 | * Design 8 | * UI Design 9 | * Take photos 10 | * Web Design 11 | 12 | 13 | ### Want to learn 14 | 15 | * Iconography 16 | * Design 17 | * Data driven design 18 | * Product management 19 | * UX Design 20 | * Research 21 | * UX Design 22 | * Humanitarian work 23 | * Design 24 | * UX Design 25 | * Research 26 | * Design 27 | 28 | ### Want to share 29 | 30 | * Storytelling 31 | * Information Architechture 32 | * Agricultural issues 33 | * Graphic Design 34 | 35 | 36 | ## A list of new skills/insights that people learned 37 | 38 | * Co-working online in 3 days 39 | * How to use Adobe XD 40 | * Google doc teamwork 41 | * Job assignment - Plan, Design, Report 42 | * Learning about people's professions 43 | * Learned different people in different divisions makes work efficient 44 | 45 | 46 | -------------------------------------------------------------------------------- /Open-Design-and-design-tooling.md: -------------------------------------------------------------------------------- 1 | # Open Design on design tooling. 2 | 3 | Conversations around the tools we use will happen naturally within the design community. The Open Design team understand there is a plethora of tools in the design industry and individuals have either a preference or a necessity to use one or more for their own reasons. We don’t advocate for designers to stop using their tools, but to recognise that alignment on tooling is a key factor for an efficient and friction-free contribution to any project of focus. Hence the same is a key component on wider success for contribution of design in OSS. 4 | 5 | Open Design centres on TenFour as an OSS case study, and the team at Ushahidi working on TenFour uses Adobe XD. The XD team has shown proof of integrating and inter-operating with many co-existing and competing design tools on the market, to enable a friction-free design process with lowest possible constraints such as hardware requirements. XD is available for macOS and Windows, easy to use, doesn’t require a high-speed internet connection and works offline, provides an all-in-one featureset that covers the full scope of TenFour’s interaction models including voice interaction, imports Sketch- and other file formats, and is available for free. Using XD will be the best way for design contributions to be integrated into the internal design process at Ushahidi. 6 | 7 | The Open Design frameworks, principles and methods aim to be as tool agnostic as possible and prioritise the benefits to both the OSS project and the designers experience with contributing. 8 | -------------------------------------------------------------------------------- /codeofconduct-contributing.md: -------------------------------------------------------------------------------- 1 | # Open Design Contributor Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. 6 | 7 | ## Our Standards 8 | 9 | Examples of behavior that contributes to creating a positive environment include: 10 | 11 | * Using welcoming and inclusive language 12 | * Being respectful of differing viewpoints and experiences 13 | * Gracefully accepting constructive criticism 14 | * Focusing on what is best for the community 15 | * Showing empathy towards other community members 16 | 17 | ### Examples of unacceptable behavior by participants include: 18 | 19 | * The use of sexualized language or imagery and unwelcome sexual attention or advances 20 | * Trolling, insulting/derogatory comments, and personal or political attacks 21 | * Public or private harassment 22 | * Publishing others’ private information, such as a physical or electronic address, without explicit permission 23 | * Other conduct which could reasonably be considered inappropriate in a professional setting 24 | * Our Responsibilities 25 | * Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. 26 | * Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. 27 | 28 | ## Scope 29 | 30 | This Code of Conduct applies within all project spaces, and it also applies when an individual is representing the project or its community in public spaces. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. 31 | 32 | ## Enforcement 33 | Instances of abusive, harassing or otherwise unacceptable behavior may be reported by contacting the project team at coc@ushahidi.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. 34 | Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project’s leadership. 35 | 36 | ## Attribution 37 | This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html 38 | For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq 39 | 40 | -------------------------------------------------------------------------------- /witness-brief.md: -------------------------------------------------------------------------------- 1 | 2 | # Brief for witnesses. 3 | 4 | 5 | ### Open Design Contact Information. 6 | 7 | **Email:** opendesignis@gmail.com 8 | **Website:** opendesign.ushahidi.com 9 | Open Design [Facebook](https://www.facebook.com/OpenDesignIs/) 10 | **Open Design** [Twitter](https://twitter.com/opendesignis) 11 | 12 | 13 | ## Open Design witnesses. 14 | 15 | ### Why? 16 | When we challenge designers and technologists to look at how to improve a digital service or product for crisis scenarios, refugee rights, gender equality or sustainability, if we do not purposefully include the people that are affected by that or have experienced this before then we are less able to understand, empathize and design and build an accurate solution to that problem. 17 | We’re reaching out to you to speak at the event as we value your level of experience and expertise in the organization you work or volunteer with. We understand that you are either a survivor or have worked closely with survivors of a tragedy that has taken place and we want to include yours and others' voices in this challenge to solve problems associated with the tragedy. 18 | 19 | ### What? 20 | This is a project which aims to create accessible processes for designers to collaborate and contribute to open-source software that does good in the world. Open Design attempts, using Ushahidi’s Open Source crisis communication tool, TenFour as a case study, to achieve this on a global scale. 21 | 22 | ### Event. 23 | The event is designed so that designers can work collaboratively to contribute to the project in person. This will be done with a special focus on the view of the target subject matter need (e.g. flooding) and yourself as a witness will be able to offer key information and insight into your experience. 24 | We call these events ‘workshops’ ‘Hackathons’ or ‘design jams’. We’re calling these ‘workshops’ and is an event At these kinds of events, computer programmers/developers and others involved in software development, including graphic designers, interface designers, project managers, and others, often including domain experts, collaborate intensively on software projects. 25 | Those responsible for the Open Design delivery should look into organizing the presence of a psychologist/counselor on-site for the full day. If the event is being hosted by conference they will be approached to source and approve the presence of a psychologist and, if applicable access to a conference wellbeing team can be organized. 26 | 27 | ### Our ask of you. 28 | What we’d like from you is: 29 | A pre-brief video call or in-person meeting before the event. Approx 30-60 minutes. 30 | An approximately 30-minute talk or conversation at the start of the workshop (between 10 and 12 depending on the workshop start time) about what you experienced and what else you know about the tragedy or incident (Flooding). Going into as much detail as you are comfortable with. This will be delivered to the audience of attendees (primarily designers and technologists interested in the crisis and solutions building). 31 | To stay for the full-day workshop (approx 6 hours) to answer any questions the designers attempting to solve the problems for this tragedy or incident. 32 | 33 | If you’d like to be part of the on-going response of these designers and Open Design then we welcome your involvement and support. 34 | 35 | ### What we can offer. 36 | A donation to your organization or a small stipend towards you for your time. 37 | Your travel to and from the event. 38 | Coffee, tea, lunch, and snacks throughout the day. 39 | Access to a professional psychologist/counsellor for the day if needed. 40 | 41 | 42 | 43 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # About Open Design 2 | 3 | ## How to talk to us 4 | 5 | You can join the Open Design slack 6 | 7 | We moved to [Discord!](https://discord.gg/Ev38r2m2FU) 8 | 9 | You can talk to us on any of the Open Design issues via comments. 10 | 11 | You can contact us via [twitter @Opendesignis](https://twitter.com/opendesignis) and [facebook @opendesignis](https://www.facebook.com/OpenDesignIs/) 12 | 13 | ## Design should be open for all. 14 | A project to create accessible processes for designers to collaborate and contribute to humanitarian open source software. 15 | 16 | Designers want to tackle big societal problems and improve the human condition. We know this because we’ve seen it. Heard it. Discussed it and felt the need for Open Design across continents. 17 | 18 | But when it comes to open source software (OSS), Designers often don’t know what they can do to contribute and how to do it. 19 | 20 | Open Design wants to achieve this through co-creation, where the outcome is designed by the community in a collaborative, multidisciplinary way that engages designers from all over the world both online and at live hackathon type events. 21 | 22 | [Read our Open Design launch article here](https://opendesign.ushahidi.com/design-should-be-open-for-all/) 23 | 24 | 25 | # People wanting to take Open Design to their communities should be able to: 26 | 27 | **Engagement** 28 | * Foster design to OSS engagement. 29 | * Foster OSS to design engagement. 30 | * Foster the understanding of the role of each other. 31 | * Can use and adapt the Open Design code of conduct and policies. They must follow the CoC. 32 | * Embrace a variety of skills, knowledge, background, demographics, leadership and time commitment. 33 | * A dedicated lead from either the OSS project internally or an appointed contributor with appropriate knowledge base to make decisions on key issues and take learnings and feedback back to the OSS project. 34 | 35 | **Types of contributors** 36 | 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. 37 | 38 | 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. 39 | 40 | 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. 41 | 42 | 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._ 43 | 44 | 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. 45 | 46 | 47 | # Glossary of terms. 48 | 49 | **(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. 50 | 51 | **GitHub -** A company that provides hosting for software development version control using Git. 52 | 53 | **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. 54 | 55 | **Design -** The way a product or service is planned and executed. 56 | 57 | **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. 58 | 59 | **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. 60 | 61 | **Graphics -** Visual assets typically created by a graphic designer or designer. 62 | 63 | **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. 64 | 65 | -------------------------------------------------------------------------------- /designer-contributions-to-OSS.md: -------------------------------------------------------------------------------- 1 | # Encouraging designer contributions to OSS. 2 | 3 | How project owners and managers can encourage designer contributions to OSS 4 | 5 | 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. Here’s the results so far: 6 | 7 | Project Owners have an important role to play in Open Design/Open Source design as they are the two-way advocate for OSS to design and design to OSS. In addition, they are the recognised ‘experts’ in the OSS purpose. 8 | 9 | Open source software is not perceived as friendly for people who are not developers. To encourage contributions from other skill sets, OSS project owners could follow the example of projects such as [Drupal](https://www.drupal.org/), a popular open source software that saw gaps in their user experience, and realised they had to improve much like a commercial organisation would: by [opening up their discussions to ‘non-technical’ people.](https://www.drupal.org/community-initiatives/drupal-core/usability) 10 | 11 | Another challenge that designers who want to contribute to OSS face is finding a project that is ready for design contributions. The projects/products need to be able to describe the design issues they need resolved well enough that designers can easily contribute when they find it. This is why people and organisations who start open design projects have to provide documentation on how people can contribute to the project. For example, [Simple.org](http://simple.org/) publishes [issues](https://github.com/simpledotorg/simple.org/issues?q=is%3Aissue+is%3Aclosed) that are useful in helping designers identify how they can contribute. All user stories, research and so on is easily available for people to see/read with flow diagrams for products. The requests should be clear and time bound, and the additional work to create and maintain documentation has to be factored in. 12 | 13 | OSS project owners should consider the different types of people (including UX Researcher, UI Designer, Graphics Designer, Motion Designer, Service Designer, Interaction Designer, and Brand Designer) who might want to contribute to their project, as well as the different resources and amount of time they’re willing or able to give. Some might be willing to contribute only one skill, such as conducting UX audits, while others might be willing to contribute across multiple competencies. Some designers might want to work on short term issues with a fixed timeline (such as logo design), while others might be more interested in issues that require research and investigation and are not time bound. Investigative designers can raise previously unseen design challenges and possible solutions. 14 | 15 | OSS project owners need to understand that designers can view an OSS project from a new (design) perspective, and this usually comes from a place of respect and genuine care, subject matter expertise and the desire to improve an OSS project/product. This new perspective is not an exercise in Design ‘ego’, and can be valuable in providing the users of the Software with a better experience. 16 | 17 | The tools and software used in the creation of OSS often constrain design contributions. As such, project managers should be open to including easily accessible software in their toolbox. To reduce barriers such as cost and access, project owners should encourage the use of tools: 18 | 19 | * That are easily available. 20 | * That can be used across a variety of operating systems including mobile devices. 21 | * That do not require high-end hardware. 22 | * That do not rely on highest speed internet connections and operate offline. 23 | * That are free to use without limitations to collaborative features. 24 | 25 | Using tools like this will facilitate and encourage wider contributions, and from less privileged demographics such as people with low to no income, people in countries with low to no internet connectivity, refugees, people that do not own their own computers and might be sharing devices, as well as people with impairments, parents and caregivers. 26 | 27 | Examples of these tools are: [GIMP](https://www.gimp.org/), [Canva](http://canva.com/), [Inkscape](https://inkscape.org/), and [Adobe XD](https://www.adobe.com/products/xd.html) 28 | 29 | Project owners should consider a design ‘friendly’ engagement strategy. This includes creating an environment that emphasizes collaboration and encourages people to come together and share different ideas. It is also important to consider how to keep designers coming back. Sustained and dedicated engagement can be tough without offline communities to support and create social glue. Project owners can also create and encourage digital connections to keep contributors engaged. They can find support and partnerships with government agencies or the corporate social responsibility arms of corporations to get resources they need, especially if the organisation has a stake in the project. 30 | 31 | In addition, when it comes to the creation of open source software, everyone is simultaneously a teacher and a student in a certain aspect. The quality of the learning experience should be supported. 32 | 33 | Another way to keep designers and other contributors engaged is for OSS project owners or managers to work around the giving credit challenge by integrating mutual credit schemes in platforms like Dribbble, Github, and Behance, or using a method similar to Stackoverflow’s reputation badges. 34 | 35 | ## In summary 36 | 37 | There can be a lot of barriers to designer contributions to Open Source Software including a lack of awareness of how to do so, and lack of engagement. Project owners can encourage contributions by being clear about what kind of help they need from designers, adopting easily accessible and widely accepted tools, and communicating and facilitating how OSS creators value design effort. 38 | 39 | -------------------------------------------------------------------------------- /The-designer-in-OSS-article.md: -------------------------------------------------------------------------------- 1 | # The designer in OSS. 2 | 3 | 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. 4 | 5 | ## The designer’s mindset 6 | 7 | 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. 8 | 9 | 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: 10 | 11 | * Opportunities for professional mentorship & growth. 12 | * Potential access to new employment opportunities. 13 | * Opportunity to work in a team (for freelancers) or with a large team (for sole designers at small companies). 14 | * Potential to meet collaborators for future projects. 15 | 16 | [Internet culture grows, explores and expands on media and projects through ‘remixing’](https://www.userzoom.com/blog/11-tips-for-effectively-screening-test-participants/) 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. 17 | 18 | Likewise, OSS projects must begin to understand how to value design contributions for what they can offer a project. 19 | 20 | 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. 21 | 22 | ## Design contributions needed by open source software 23 | 24 | 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. 25 | 26 | 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. 27 | 28 | 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](http://simple.org/) is currently taking this approach and gathering contributions from [‘Swiggy,’](https://www.swiggy.com/) a delivery tool in india to understand what great customer service management/delivery looks like. 29 | 30 | ## How designers can contribute to Open Source Software by collaborating offline 31 | 32 | Designers can come together at in person events [such as design jams](https://www.ushahidi.com/blog/2019/02/19/ushahidi-hosts-tenfour-design-jam-with-designit-adobe-at-interaction-week-19). 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: 33 | 34 | * An extension of an existing feature. 35 | * A new feature that needs design thinking/exploration. 36 | * Improving or redesigning an existing feature. 37 | * Localising the software. 38 | 39 | 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. 40 | 41 | 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. 42 | 43 | ## In summary 44 | 45 | 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. 46 | -------------------------------------------------------------------------------- /Bangalore-workshop.md: -------------------------------------------------------------------------------- 1 | # Bangalore: Open Design Workshop/Masterclass 2 | 3 | This file is intended on being a reference for resources for the attendees of the Bangalore open Design workshop/masterclass at DesignUP! conference 2019 in Bangalore as well as a repository for learnings from the event for the wider Open Design methodology and project. 4 | 5 | ## Slides 6 | 7 | You can view the slides used at the Bangalore workshop/masterclass [here](https://drive.google.com/file/d/18zy6R7mkNuYdp_4wz0D5c9LsDfzt_plH/view?usp=sharing) 8 | 9 | The agenda [here](https://drive.google.com/file/d/1sq9978GCwWmrfubldmCXk0NnD3LSbuPH/view?usp=sharing) 10 | 11 | The challenges issued to the team [here](https://drive.google.com/drive/folders/1ECJiyK3sAJaq6unM1sCQelQKxdi1VHoR?usp=sharing) 12 | 13 | The printed resource templates [here](https://drive.google.com/drive/folders/1Dmyj1p57Lx9B6zdra4G3PUsqFMOqgNhh?usp=sharing) 14 | 15 | ## Workshop living document 16 | 17 | You can find the workshop planning document [here](https://docs.google.com/document/d/1j6Y1MRrmJomtTuhZlVrY9nQXbWQxdp3nk62OTivD05Q/edit?usp=sharing) 18 | 19 | ## Witness 20 | 21 | Our witness was Akhila, a researcher involved in researching the Kerala flooding of 2018 and 2019. Akhila works for [Centre for Migration and Inclusive Development](http://cmid.org.in/) you can find their report on the Kerala floodings in .PDF format via a google drive link [here](https://drive.google.com/file/d/1UxIHvOEyT_aXqbKeJX1ayRpBjwmQP4G5/view?fbclid=IwAR03289j1ehOmDnHjWm996xQtMIAy8grAAZU1Koa5KiO8zHltVQGLQrT0Xg) 22 | 23 | 24 | ## Workshop Observations 25 | 26 | * Full Workshop, around 40. 27 | * Participants from all over India. 28 | * Design savvy. 29 | * Split of interested in OSS and interested in Humanitarian. 30 | * Most agreed on Humanitarian principles for design led contributions. 31 | * Ran 1 hour over time. 32 | * Unclear start time. 33 | * The general adoption to Adobe XD as a tool to prototype was super fast. Not everyone had used before. 34 | * There was a lot of enthusiasm in the room and a lot of the participants wanted to know more about TenFour and Open Design. 35 | * Breaks need to be better considered. 36 | * If a workshop is to be part of a conference it's best to do that on a dedicated workshop day and not alongside speaker slots. 37 | 38 | 39 | 40 | ## Learnings 41 | 42 | Learnings on how to amend the methodology and/or the workshop framework. 43 | 44 | ### Methodology 45 | 1. Witness inspired a lot of persona-details. 46 | 2. Witness crucial during idea evaluation and final feedback on prototypes. 47 | 3. As the audience was more design savvy they felt clearly restricted by too narrow briefs, the more open ones worked better. 48 | 4. All groups had some digital results in the end. 49 | 5. Groups still struggled with GitHub 50 | 6. Some attendees asked about other open source projects to work on the design for. 51 | 7. The question about 'When is a design 'ready' for development' or 'finished' came up. This is the process that must be in place in the OSS technology that allows for some laddered process of deciding when a design contribution is done. Because by the nature of design it can be subjective to both the designer and the person/s approving the design. Attendees satisfied with this not being defined via teh open Design project but are aware of the problem and keen to see suggested solutions. Open Design should be prepared for debate and discourse regarding this topic. 52 | 8. However the offer to continue on the topic in remote sprints needs more moderation. It is not as self explanatory as we expected and it is hard to keep up motivation after the end of the workshop. 53 | 9. Adding the outputs in GitHub comments was questioned. Is this really the best way to contribute design? Again, a topic where the meeting of OSS/Mainter expectations and non-OSS designers clash. 54 | 10. Better guidance on what to document, how and when. E.g. Take a photo of this activity, now write your names and team now upload to github etc. 55 | 11. Some difference in workshop process and outcome sdepending on professional positioning. Student vs. professionals. Attendees supported each other with learning and activities. 56 | 12. One group had a coder/developer in their group and they were able to ask technical fesibility questions to this member that helped them ideate within technical constraints. 57 | 13. Specific focus on learning during the process needs to be developed. 58 | 14. Recommended and documented ways to 'pick apart' or better understand and construct OSS issues that designers want to contribute to could be beneficial for both the Open Design process and the OSS projects benefitting from Open Design. 59 | 15. Many designers are keen to see projects where the OSS is 'started' with design issues or in close alignment with code issues. Basically some projects that are right at the start of being built are what some designers want to be part of as well as established OSS projects. 60 | 61 | 62 | ### Workshop Framework 63 | 1. Sending out a workshop pre-email 1 day before the activity was not enough time for some to plan to download software on company restricted laptops. 64 | 2. SIgning up for all the attached resource and tool sites takes a while and you can't assume people will do it pre-workshop. 65 | 3. We ran 1 hour overtime so we either need to cut activities, lengthen the workshop or find a remote option. 66 | 4. Challenges we regarded as too short in description or there was a lot of clarifying questions to the workshop leads like 'What are the restrictions?' 'What is success for the iuser?' 'Who are we designing for?'. 67 | 5. Ideation phase took a little longer as the teams had a lot of input on: the scenario, the technology, the purpose. Narrowing down was hard and time consuming. 68 | 5. 1st GitHub upload needs to be part of the workshop processes and outline. It can't just be a demo. 69 | 6. Workshop is best delivered with two Open Design leaders and 1 assistent with a content and social focus. 70 | 7. Refining the role required in a group and what their function is/could be e.g. 1 UX designer, 1 Researcher, 1 Documenter. 71 | 8. Being able to have activities that can happen in tandem when prototyping starts is to be developed. 1-2 people typically operate the prototyping tool and other complete tasks like sketching, storyboards and documenting. But this way not everyone gets a chance to prototype in one workshop. 72 | 9. The exercises are part of de-constructing a typical OSS 'issue' and many of the attendees understood this afte rthe process was completed and this part explained. 73 | 10. Picking apart challenges/issues could be more explicit as part of the workshop and less implied. 74 | 11. 75 | -------------------------------------------------------------------------------- /Open-Design-2020-Update.md: -------------------------------------------------------------------------------- 1 | # Open Design 2020 Update! 2 | 3 | So a few things happened in 2020 after Open Design closed out its first phase 1 of the funded project, hosted by [Ushahidi](https://ushahidi.com/), funded by [Adobe fund for design](https://www.adobe.com/products/xd/adobe-fund.html) and supported by partner [Designit](https://www.designit.com/). 4 | 5 | Open Design’s repository remains part of Ushahidi’s collection of repositories and remains under open source creative commons license but has now been forked to a personal GitHub account held by [Eriol Fox](https://twitter.com/EriolDoesDesign) and a new Github account named ‘Opendesignis’ and owned/maintained by Eriol Fox. Eriol also created a parallel repository on GitLab in order to bring the project to those who do not use GitHub as their primary source for open source projects and community. 6 | 7 | Open Design ceased its funded work via Ushahidi in December 2019 and January 2020 and due to no further immediate funding, was maintained as a volunteer OSS project by Eriol Fox. Eriol had led the Open Design project and funded activities/deliverables within Ushahidi, supported by the collaborators of [Jay Meissner](https://twitter.com/klick_ass) (of Adobe XD) and [Thomas Kueber](https://twitter.com/mryash) (formerly of Designit). Eriol left Ushahidi in January 2020 and continues to work on open Design as a volunteer OSS project having forked the repository originally started by Ushahidi. All work done as of February 2020 by Eriol Fox will now be added to the version of [Open Design in Eriol Fox’s personal repository account](https://github.com/Erioldoesdesign/opendesign) and updated in the [opendesignis account](https://github.com/open-design-is) and [Eriol’s GitLab account](https://gitlab.com/Erioldoesdesign/opendesignis). 8 | 9 | As Ushahidi was the organisation that incubated this project and under Creative Commons license rules we’ll continue to thank and reference Ushahidi and the partners of Adobe and Designit whenever Open Design project work is progressed as a volunteer OSS endeavour. 10 | 11 | This may mean that the website http://opendesign.ushahidi.com/ may cease to be accessible at any given point in the future as this is owned and paid for by Ushahidi and is their choice to continue to maintain. I (as in Eriol Fox) no longer has access to to way in which to update that website so any updates will not be from Eriol. 12 | 13 | So, other than the forking of the repos and spreading out of where Open Design can be accessed what has the now volunteer Open Design team been up to? 14 | 15 | In early 2020 (pre-corona virus) the Open Design team was having conversations with two OSS projects that were interested in hosting Open Design workshops and working with the Open Design team to adapt and try the methodology with their OSS projects. One project was based in India and the other was based in the UK. Both OSS projects had global purpose. 16 | 17 | Due to corona virus our conversations about in-person workshops around Open Design have been put on hiatus until safety can be ensured for any workshop attendees, organisers and projects. 18 | 19 | The Open Design team have however, engaged with many different projects through open design contributions and collaborations including the fossresponders project and continued to work closely with the opensourcedesign.net and sustain OSS design & UX working group. 20 | 21 | ### We’ve given several talks about the process of Open Design in 2019 and our hopes for the future of Open Design at these conferences: 22 | - Open Data Institute’s Friday talks in London 23 | - Sustain OSS 2020 in Brussels 24 | - FOSSDEM 2020 in Brussels 25 | - Interaction 20 in Milan 26 | - OSCA Festival 20 in Lagos 27 | - CiviCamp 2020 in Birmingham UK 28 | - Open Source Community Ghana in Ghana (Online) 29 | - FOSSASIA 2020 in Singapore (Online) 30 | - Coscup 2020 in Taipei (Online) 31 | 32 | ### The talks we have pending for 2020 are: 33 | - GitLab Commit on the 26th of August 2020. 34 | - A panel discussion at openup.global summit on the 12th and 13th of September 2020. 35 | 36 | ### We’ve also trialled and tested 3 different workshops for the new virtual-led conference eco-system 37 | - A 2 hour open design workshop focussed on OSS maintainers, owners and OSS developer contributors at Open Source 101: at home 38 | - A 2 hour open design workshop focussed on UX designers that have never contributed to OSS before at UX Bristol online. 39 | - A 1 hour open design workshop focussed on human rights technologists and those working with OSS in the humanitarian sector at RightsCon 2020 online. 40 | 41 | We have another workshop pending at All Things Open online in October 2020 where Eriol Fox and [Abigail Makolo](https://abigailmakolo.com/) are working on developing a revised session for OSS maintainers, owners and contributors to relate to, and work better with designers across OSS. 42 | 43 | In partnership with opensourcedesign.net we also attended Foss Backstage in Berlin (pre-lockdown) to offer a ‘UX speed-dating’ style table where OSS maintainers and developers could approach UX and designers with their OSS+Design questions and get UX feedback on their OSS projects. 44 | 45 | So it’s already been a busy year for the Open Design volunteer team. Eriol is now on staff at a wonderful OSS project called Open Food Network and is starting a PhD in January 2021 looking at Designers involvement with humanitarian OSS. [Thomas Kueber](https://twitter.com/mryash) has founded a design studio with long-time collaborator [Andreas Wegner](https://twitter.com/jesusberlin) called [Futur2](http://www.futur2studio.com/) and continues to support Open Design around their client work and [Jay Meissner](https://twitter.com/klick_ass) has been busy looking at administrative details as well as looking into OSS projects for Open Design to collaborate with going forward. 46 | 47 | Open Design ‘Phase 2’ has already learned large amounts of new data and information regarding the relationship with open source software and designers/design as well as how the OSS projects, individuals and humanitarian organisations play into this relationship too so keep an eye out for a de-brief from our three workshops already done this year as well our plans moving into the latter half of 2020 and into 2021. 48 | 49 | Last but not least Open Design has been running for the last 6 months with no funding so purely as a volunteer effort. In order to deliver quality research, insight and eventually, in-person workshops and sessions with designers and open source software we need funding. To this end, we’ve had conversations with fiscal hosts for funds and also started to set up GitHub sponsors as well as other ways of funding our ongoing work. If you have any advice, insight or support to offer us, we’re very happy to receive it asa opendesignis@gmail.com 50 | 51 | 52 | Eriol Fox signing off for opening up design and open source x 53 | -------------------------------------------------------------------------------- /Taipei-workshop.md: -------------------------------------------------------------------------------- 1 | # Taipei: Open Design Workshop 2 | 3 | This file is intended on being a reference for resources for the attendees of the Taipei open Design workshop at Open UP global summit 2019 in Taipei as well as a repository for learnings from the event for the wider Open Design methodology and project. 4 | 5 | ## Slides 6 | 7 | You can view the slides used at the Taipei workshop [here](https://drive.google.com/open?id=14DxxAnAL7KHolcIcEiORpduNx84J1G4V) 8 | 9 | The agenda for day 1 [here](https://drive.google.com/open?id=1HxS0BbDkgfVOYR5o5ryH7WUhANQmIC8L) the remote week activities [here](https://drive.google.com/drive/folders/1uN-uXKebE0oVOr7tphGKYRcBFlObmqVN?usp=sharing) and day 2 [here](https://drive.google.com/open?id=1LzuUPAS5xvChtSazA3yCTtscK7owrM3Z) 10 | 11 | The challenges issued to the team [here](https://drive.google.com/drive/folders/1ECJiyK3sAJaq6unM1sCQelQKxdi1VHoR?usp=sharing) 12 | 13 | The printed resource templates [here](https://drive.google.com/drive/folders/1Dmyj1p57Lx9B6zdra4G3PUsqFMOqgNhh?usp=sharing) 14 | 15 | ## Workshop living document 16 | 17 | You can find the workshop planning document [here](https://docs.google.com/document/d/1_G29c0eXw2tESLIl0ClYk89LzmHzdWiX5adJLZweubE/edit?usp=sharing) 18 | 19 | ## Witness 20 | 21 | Our witness was Mei Mei Chen, a 'Office Lady' who became heavily involved with the respnse to Typhoons after 2015 and Hung Wen Lu a farmer that was affected by the Typhoons and speaks about his experiences. 22 | 23 | Mei Mei Chen's organisations [Go Farmer](bit.ly/go-farmer) and [Rong Naida](https://www.facebook.com/groups/197584700968133/) and [Good people club](https://www.facebook.com/%E5%A5%BD%E4%BA%BA%E6%9C%83%E9%A4%A8-321962754494111/) a [video about the Typhoons](https://t.co/LcahuFVOvA). 24 | 25 | ## Workshop Observations 26 | 27 | * 38 people down to around 32 after the first break. 28 | * Unclear some of the time commitments and splitting the two workshops in half. 29 | * Translaters for different language speakers important but lengthens the process. 30 | * Two witnesses brought a great dynamic to the room and they were well prepared. 31 | * The way groups voted was different, one group did a democractic voting system on the challenges and another deciding which was the most important for the farmers to solve and chose that one. 32 | * Very diverse skilll set in this conference/group but all with the singular factors of: Wanting to improve design contribution and Humanitarian focus. 33 | * The conference had planned workshops back to back and therefore we started 15 minute late due to needing to set up and ran 10 mins over when cleaning up afterwards for the next workshop. Send set-up and take-down times to organisers of conferences pre-event. 34 | * Different countries/cultures use different comms methods as primary comms channel. Slack was ok but folks in Taiwan created Line groups and added workshop facilitator. Pre-research needed into the groups most likely method of comms. Taiwan prefers Line, Facebook and Instagram. 35 | * Conference had a slack group as well as the Open Design slack group so we preferenced the conference slack group out of courtesy. Slack group won't be close soon and will continue for future conferences so no risk of losing contact with attendees. 36 | * Event was offered to non-conference attendees as organisers wanted to maximise attedance for the workshop. 37 | * Event was offered on the conference website but also created facebook events. 38 | * Talk was the day before the workshop which increased the interest in attending the workshop but then we also weren't sure how many people would be able to attend the 1st and 2nd workshop. 39 | * Some confusion when offering an online remote option for those that would find it difficult to travel into Taipei for the second workshop. 40 | * Started 30 minutes late due to the venue elevators being slow and finished 30 minutes late. 41 | * Doing international workshops where people's first/proficient languages aren't that of the project/workshop facilitator requires great translation efforts (which was provided by the conference for this event). 42 | * Translating takes time. Allow for double the amount of time to deliver content/information when translation is present. 43 | 44 | ## Learnings 45 | 46 | Learnings on how to amend the methodology and/or the workshop framework. 47 | 48 | ### Methodology 49 | 1. Similar questions about restriction vs. freedom to design came up from this group. This is a key component for wider involvements from designers in FOSS is the degree to which the FOSS can allow for and encourage design exploration as part of their contribution process. 50 | 2. Some attendees considered challenges from a 'scope' pov. What was acheivable in the set workshop time vs. that they wanted to spend more time on. Suggestion for design issues is an estimated amount of time to spend on an issue or at least an indication from the FOSS on how long they consider a design contribution time wise. 51 | 3. Comments from developers around when 'design' is complete and ready to be developed. 52 | 4. Mentoring and peer-to-peer support needs in-depth investiagtion as well as how the community is built. 53 | 5. Because there was a member of the social/content team present. 54 | 6. Benefits of having a developer of the OSS software present made clear by some more developer focussed attendees asking about the tech stack of the OSS and how to work with it. In this case Ionic & PWA's. 55 | 56 | 57 | ### Workshop Framework 58 | 1. Challenges are now too long. Answering the probing questions from the previous workshop and adding them here as pre-answers is not affective. 59 | 2. 5 challenges were too many to cover in the workshop time. 60 | 3. Workshop is best delivered with two Open Design leaders and 1 assistant with a content and social focus. 61 | 4. Remote activities using Mural and other online tools worked well. 62 | 5. Offering online videos and written tutorials on how to complete remote tasks well recieved. 63 | 6. There will always be a mismatch between group outputs. Some groups will produce more 'advanced' prototypes or be able to complete more/less work in the time given. The presentation section of the workshop could therefore be standardised so people aren't comparing work. 64 | 7. Including step by step upload in the workshop end is key otherwise teams don't upload or put it off. Commitment fear or finalisation fear. 65 | 8. Some teams interested in further structured remote sprints. 66 | 9. One team finish their prototypes remotely and were able to gain feedback from the workshop leader to iterate in that 2nd workshop session and then re-upload. 67 | 10. Short Adobe XD demo was useful for this group as a few had never worked with XD before. 68 | 11. Ideal workshop team suspected to be: 2 workshop facilitators/designers, 1 content & socials, 1 volunteer per team (can include 1 facilitators/designers), 1 developer of OSS, 1-2 Witnesses. 69 | -------------------------------------------------------------------------------- /codeofconduct-community.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | ## Open Design Community Code Of Conduct (for events) 4 | 5 | ### Our Goal 6 | 7 | The Open Design community is dedicated to providing a harassment-free experience for everyone. We do not tolerate harassment of participants in any form. 8 | 9 | 10 | ### Applicability and Scope 11 | 12 | This code of conduct applies to all of this community's spaces, including public channels, private channels and direct messages, both online and off. Anyone who violates this code of conduct may be sanctioned or expelled from these spaces at the discretion of the administrators. 13 | 14 | ### Toward a Welcoming and Safe Environment 15 | 16 | We hope to create an environment in which diverse individuals can collaborate and interact in a positive and affirming way. Examples of behavior that contributes to creating this sort of environment include: 17 | 18 | * Using welcoming and inclusive language. 19 | * Being respectful of differing viewpoints and experiences. 20 | * Gracefully accepting constructive criticism. 21 | * Focusing on what is best for the overall community. 22 | * Showing empathy towards other community members. 23 | 24 | ### Anti-Harassment Statement 25 | 26 | This community will not tolerate harassment of any kind. Examples of harassment include: 27 | 28 | * Offensive comments related to gender, gender identity and expression, sexual orientation, disability, mental illness, neuro(a)typicality, physical appearance, pregnancy status, veteran status, political affiliation, marital status, body size, age, race, national origin, ethnic origin, nationality, immigration status, language, religion or lack thereof, or other identity marker. This includes anti-Indigenous/Nativeness and anti-Blackness. 29 | 30 | * Unwelcome comments regarding a person's lifestyle choices and practices, including those related to food, health, parenting, relationships, drugs, and employment. 31 | 32 | * Deliberate misgendering, using inappropriate pronouns, or use of "dead" or rejected names. 33 | 34 | * Gratuitous or off-topic sexual images or behavior in spaces where they're not appropriate. 35 | 36 | * Physical contact and simulated physical contact (eg, textual descriptions like "hug" or "backrub") without consent or after a request to stop. 37 | 38 | * Threats of violence. 39 | 40 | * Incitement of violence towards any individual or group, including encouraging a person to commit suicide or to engage in self-harm. 41 | 42 | * Deliberate intimidation. 43 | 44 | * Stalking or following - online or in the physical world. 45 | 46 | * Harassing photography or recording, including logging online activity for harassment purposes. 47 | 48 | * Sustained disruption of discussion. 49 | 50 | * Unwelcome sexual attention. 51 | 52 | * Patterns of inappropriate social contact, such as requesting/assuming inappropriate levels of intimacy with others. 53 | 54 | * Continued one-on-one communication after requests to cease. 55 | 56 | * Deliberate "outing" of any aspect of a person's identity without their consent except as necessary to protect vulnerable people from intentional abuse. 57 | 58 | * Publication of non-harassing private communication. 59 | 60 | * Jokes that resemble the above, such as "hipster racism", still count as harassment even if meant satirically or ironically. 61 | 62 | If you have questions or concerns about these issues please feel free to message an admin or ask for an opportunity to explore the issue with a moderator and volunteers. 63 | Reporting 64 | 65 | If you are being harassed by a member of our community, notice that someone else is being harassed, or have any other concerns, please contact the administrators via coc@ushahidi.com If the person who is harassing you is on the admin team, they will not be involved in handling or resolving the incident. 66 | The admin team will respond to any complaint as promptly as possible we can. If you do not get a timely response (for example, if no admins are currently online) then please put your personal safety and well-being first, and consider logging out and/or contacting the admins by email at coc@ushahidi.com. 67 | This code of conduct applies to our community's spaces, but if you are being harassed by a member of our community outside our spaces, we still want to know about it. We will take all good-faith reports of harassment by our members, especially the administrators, seriously. This includes harassment outside our spaces and harassment that took place at any point in time. The abuse team reserves the right to exclude people from the community based on their past behavior, including behavior outside of our spaces and behavior towards people who are not in this community. 68 | In order to protect volunteers from abuse and burnout, we reserve the right to reject any report we believe to have been made in bad faith. Reports intended to silence legitimate criticism may be deleted without response. 69 | 70 | ### Enforcement Process 71 | 72 | Every code of conduct violation report will be treated with seriousness and care. If a member's immediate safety and security is threatened, an individual admin may take any action that they deem appropriate, up to and including temporarily banning the offender from the community. In less urgent situations, at least two admins will discuss the offense and mutually arrive at a suitable response, which will be shared with the offender privately. Whatever the resolution that they decide upon, the decision of the admins involved in a violation case will be considered final. 73 | We will respect confidentiality requests for the purpose of protecting victims of abuse. At our discretion, we may publicly name a person about whom we've received harassment complaints, or privately warn third parties about them, if we believe that doing so will increase the safety of our members or the general public. We will not name harassment victims without their affirmative consent. 74 | 75 | ### Consequences 76 | 77 | Participants asked to stop any harassing behavior are expected to comply immediately. If a participant engages in harassing behavior, the administrators may take any action they deem appropriate, up to and including expulsion from the community and identification of the participant as a harasser to other members. At the discretion of the admins, or by request, one or more of the parties involved may request to discuss the violation and how to avoid similar situations in the future. 78 | 79 | ### Acknowledgements 80 | 81 | This Code of Conduct is adapted from the Community Covenant (http://community-covenant.net), version 1.0, available at http://community-covenant.net/version/1/0/. The Community Covenant is an open source effort and is built on codes of conduct that came before it, including the Contributor Covenant and the LGBTQ in Tech community code of conduct. 82 | 83 | ### License 84 | 85 | Community Covenant by Coraline Ada Ehmke is licensed under a Creative Commons Attribution 4.0 International License. 86 | Based on a work at http://community-covenant.net/. 87 | 88 | -------------------------------------------------------------------------------- /TenFour-ready-for-design-contributions.md: -------------------------------------------------------------------------------- 1 | # TenFour the OSS crisis communication tool is ready for design contributions. 2 | 3 | When you’re any kind of designer coming into an existing project, the first thing you typically do is get familiar with the product, brand, and users of the product or service you’ll be designing for. 4 | 5 | Often this means reviewing a series of hefty documents provided by the company or client, sometimes with past iterations, rationale and if you’re in good company, some insight user journeys and testing to help you understand the goals of the people that are using the product or service. 6 | 7 | Rarely, though more regularly seen now, are well-documented, up-to-date design systems or customized frameworks. Either live coded in HTML/CSS or using a generative tool. But for many Open Source Software (OSS) products and tools, creating and maintaining a design system is time and labor-intensive not to mention design skill reliant and, often not carried out as we know the volume of designers contributing to OSS is still small in comparison to those that contribute code. 8 | 9 | As such, designers looking to contribute to OSS can find one of their many hurdles to be how they access the building blocks, the UI, graphics, and flows of a product in order to create or modify the design in response to a feature request or issue in the OSS repo. 10 | 11 | Without easy access to a test system, framework or design system, designers can only rely on simple wireframes or piecing together screenshots (if they have access to the product). They can also undertake the task of creating the product in design software. 12 | 13 | There are some designers proficient in front-end coding that can ‘design in code’. This offers these individuals easier access to the building blocks to contribute design, but it doesn’t work for the large population of designers who’s primary tools are design software. 14 | 15 | As part of the Open Design project goals, we’re focusing on one of [Ushahidi’s](https://www.ushahidi.com/) OSS tools, [TenFour](https://tenfour.org/) to see if a framework of support, documentation, collaboration and example files can increase design contributions to this OSS and more to come in the future. TenFour is a PWA app that uses [Ionic](https://ionicframework.com/) as a framework to build functionality and visuals. Ionic has a series of standard and customizable components that are now detailed and described in the TenFour design kit, which is available in XD. 16 | 17 | ## Our design kit for TenFour 18 | 19 | The TenFour design kit was created in our design software of choice, Adobe XD. The file includes global elements used across the TenFour product as well as sample screens of many of the core functions of TenFour. 20 | 21 | The global elements include those actively used in the product and also those that have previously been created and remain unused, but potentially useful assets for future features and layouts of the TenFour product. 22 | 23 | We opted to include not only global example elements but as comprehensive a sample of screens from the live application so that designers can, in one file, get a sense of how TenFour operates and functions as a tool for communication in crisis scenarios. 24 | 25 | This design kit can be iterated on, added to and improved in order to make design contributions to TenFour even easier in the future, just like the OSS tool it supports. 26 | 27 | ## How to find the TenFour design kit 28 | 29 | You can find the TenFour design kit file in the Open Design issue [here](https://github.com/ushahidi/opendesign/issues/135) and in the TenFour repository on Github [here](https://github.com/ushahidi/tenfour/blob/develop/design-contributions.md). 30 | 31 | [You can download the TenFour design kit here] (https://github.com/ushahidi/tenfour/blob/develop/design-contributions.md) 32 | 33 | Currently, you can download the XD file to use for working on TenFour design issues. There are also links to view the content of the XD file [here](https://xd.adobe.com/view/d6acbb4d-0dce-44da-7093-bac08af8152d-a09d/) and [here](https://xd.adobe.com/spec/4ab4337a-d4a2-4f40-4881-f2349b12d769-3c85/grid). 34 | 35 | This is the first version of the TenFour design kit for OSS contributions and versioning of the file will be kept track of in the [design contributions](https://github.com/ushahidi/tenfour/blob/develop/design-contributions.md) file in the TenFour repo. 36 | 37 | ## Using the TenFour design kit XD file 38 | 39 | When using the TenFour design kit we recommend that you pull the components and page layouts from the design kit and use them in a new file that has 40 | 41 | * The name of the TenFour issue. 42 | * The issue number. 43 | * Your GitHub username . 44 | 45 | in the XD file name in order to distinguish different files from contributors. 46 | 47 | We ask all potential future contributors to not erase previous components unless they have been deprecated in Ionic and that we keep meticulous records of the file versions. 48 | 49 | ## How to start contributing to TenFour 50 | 51 | First, take a look at the TenFour repo’s [Read me file](https://github.com/ushahidi/tenfour/blob/develop/README.md) in Github, this will give you some background information on TenFour’s purpose as a product. There’s also an informational [slide deck about TenFour](https://drive.google.com/file/d/1B80_hcdWD-7SQFdssUzzRegfChtbwjdH/view) that will give you some in-depth information about the problem space of communication in a crisis scenario that TenFour is aiming to help solve. 52 | 53 | Next, we recommend you [download the TenFour design kit](https://github.com/ushahidi/tenfour/blob/develop/design-contributions.md) and take a look at the product screen examples and the design system to work with. 54 | 55 | You’re now ready to take a look at the TenFour repo that ‘need design’. We’ve separated this by suggested design function, [UX](https://github.com/ushahidi/tenfour/labels/Design%3A%20UX), [UI](https://github.com/ushahidi/tenfour/labels/Design%3A%20UI), [Visual/Graphic](https://github.com/ushahidi/tenfour/labels/Design%3A%20Visual%2FGraphic), [Usability/Inclusive design](https://github.com/ushahidi/tenfour/labels/Design%3A%20Inclusion), [Interaction design](https://github.com/ushahidi/tenfour/labels/Design%3A%20Interaction), [User Research](https://github.com/ushahidi/tenfour/labels/Design%3A%20User%20Research). You can also suggest that we add new labels for design-related work not expressed in these labels. 56 | 57 | Ask questions in the comments section of any issue if you need further clarification on how to approach the issue. 58 | 59 | When you’ve completed your design response to an issue in the TenFour repo, we recommend adding your contributions via the comments section of the issue and be sure to add the XD design file you created from the TenFour design kit. Explain in as much detail how you responded to the needs of the issue, user case and any requirements detailed in the issue. 60 | 61 | Add a new issue to the [Open Design repo](https://github.com/ushahidi/opendesign/issues) with a link back to the issue in the TenFour/OSS repo. This will ensure that if you need support form the Open Design community, it can be discovered and responded to. 62 | 63 | We’ll be developing how we agree on design critique and feedback as an Open Design community going forward but we’ll be advocating for a supportive, collaborative environment that prioritizes users, design mentoring, skill development and inclusion first. 64 | 65 | [If you can attend an Open Design event or workshop](https://github.com/ushahidi/opendesign/blob/master/events.md) we highly encourage this. These events are where we’ll be testing our [workshop framework](https://github.com/ushahidi/opendesign/blob/master/workshop-framework.md) and seeing how the global design community works best collaboratively on OSS. 66 | 67 | If you can’t attend, we encourage you to use and remix the workshop framework and organize a local event yourself. 68 | 69 | ### Can I offer other design contributions like user testing or UX work? 70 | You can use [Ushahidi’s documentation guides](https://app.gitbook.com/@ushahidi/s/platform-developer-documentation/design/design-process) on how to contribute design work like user test scripts, UX studies and performing and analyzing user testing results. This work greatly informs the rest of the design work that the TenFour design kit will be used for so we encourage these contributions too. 71 | 72 | ### What next? 73 | If you can, join us at one of our live workshops where we’ll form teams to go in-depth on large features and issues for TenFour and explore the situations through empathy exercises and contextual inquiry and actively use the TenFour design kit as a team. 74 | 75 | 76 | -------------------------------------------------------------------------------- /workshop-framework.md: -------------------------------------------------------------------------------- 1 | # Open Design workshop framework. 2 | 3 | ## Teams. 4 | Teams of each 5-6 people. Max 60 attendees for 2 facilitators (30:1 ratio). If volunteers are available, 1 per team plus 3 for runner activities would be best. For a 60 person event, a maximum of 12 volunteers. A minimum of 3-6 volunteers would be sufficient. 5 | 6 | Teams ideally constitute of UX, researchers, visual designers, UI designers, graphics designers, Interaction designers & a product manager/coordinator. Teams could double up functions but be careful of workload. 7 | 8 | We have some target designers for Open Design [described on page 4 - 7](https://docs.google.com/presentation/d/10TY67_rHr2WaegGudJyyvQ5xGu1E-ilGFu22dZWdjZo/edit?usp=sharing)of our social media plan. 9 | 10 | 11 | 12 | ## Comms. 13 | Teams may organize their own comms channels but there should be a place where we invite attendees to talk if they want to. For conferences, you can use the conference slack and ask to have a channel created. For independent events, you can create and distribute your own. [Sli.do](https://www.sli.do/) might be a place to do so. 14 | 15 | Attendees should be kept updated via email that they provided to the conference and/or the event ticket link. 16 | 17 | Our Code of Conduct for [community](https://github.com/ushahidi/opendesign/blob/master/codeofconduct-community.md) and [contribution](https://github.com/ushahidi/opendesign/blob/master/codeofconduct-contributing.md) 18 | 19 | 20 | ## Witnesses. 21 | Witnesses are people that have direct experience of the humanitarian challenge that the OSS tool is aiming to solve. In the test case of TenFour, these are people that have witnessed and lived through a crisis like a terrorist attack, flood or a hurricane. These witnesses are invited to talk at the event for around 30 minutes and strongly encouraged to stay for the duration of the event to be accessible to the designers working on the challenges so they can better understand whether what they’re building meets the needs of real people in these scenarios. 22 | 23 | [Witness speaker brief document](https://docs.google.com/document/d/1CVkht7rt2_cOUrYfaY4c5ekjgyzwiHFdRRM6cJy-020/edit) 24 | 25 | 26 | ## Psychological support. 27 | Because of the nature of some humanitarian OSS projects, there may be a need for a person with skills in counseling/psychology to attend the event as a duty of care to the witnesses and the attendee designers participating in the event. We strongly advise that first hand and second-hand trauma is not undervalued as a potential. 28 | 29 | 30 | ## Breakdown of the day: 31 | 32 | ### Pre-event work: 33 | - Pre-email pack - provide links to the TenFour/OSS sticker sheet. 34 | - Pre-email pack - links to the activities like Empathy maps, storyboards, Inspiration boards, etc. 35 | - Pre-email pack running order of the day, logistics, venue, transport, etc. 36 | - Pre-briefing for participants with notification of the focus of the workshop in detail (do not assume everyone will read this) 37 | - A way for attendees to talk pre-event. Discord, Slack, Signal group, etc. 38 | - Suggest a tool like Mural to remote collaborate. 39 | - CoC for the event. 40 | - Team & volunteer briefing for roles and things to be aware of on the day. 41 | - Brief the counselor/psychologist. 42 | 43 | 44 | **Start between 9.00am & 10.00am** 45 | - Breakfast, coffee. 46 | - Icebreakers & team forming. 47 | - Activity: Use a post-it board or stickers on name labels to catalog the skills in the group. What skills people want to learn, help with etc. 48 | - Activity: Group forming boards people put names on the board. It doesn’t have to be set in stone at this point. 49 | - Activity: Icebreakers What do you know about X event? About X issue? What do you hope to gain from Open Design? 50 | 51 | 52 | **11.00am - Immersion** 53 | - OSS product intro & where it lives. 54 | - 30 mins witnesses speaking about the related incident/event. 55 | - 10 mins counselor/psychology background & reasons on why trauma is needed to be dealt with. 56 | - Final team forming. 57 | 58 | 59 | **12.00 pm** 60 | - Coffee break 61 | 62 | 63 | **12.30 pm - Journey & Definition (current TenFour App/OSS)** 64 | - Challenge definition. 65 | - File share, murals, google drive, slack, downloads, updates, etc. 66 | - Start work: Discovery & understanding exercises. 67 | 68 | 69 | **13.00 pm** 70 | - Lunch 71 | 72 | 73 | **14.00 pm - Ideate & Prototype** 74 | - Continue working. 75 | 76 | 77 | **15.00 pm** 78 | - Usertesting methods. 79 | 80 | 81 | **17.00 pm - Present** 82 | - Wrap up work 83 | - Presentations. 84 | 85 | 86 | **18.00 pm - Upload to OSS project space** 87 | - How to upload your work. 88 | - Upload design files, explain work, etc. 89 | - Evaluation forms. 90 | - Follow up Design sprint info. 91 | 92 | 93 | **19.00 pm** 94 | - Post briefing by the organizers: Short summaries of what worked well, what didn’t and what could change. A Space to evaluate individually and then share back to the organization team. 95 | 96 | 97 | ### Things to be aware of when doing these kinds of events: 98 | 99 | - People that don’t have relevant skills will show up. Eg. Developers 100 | - People will overestimate their skill level with a given tool Eg. Think they are experts when they are ‘intermediate’ 101 | - Some people may struggle to form a group or become part of a group. Organizers may be required to ‘place’ people into groups and do this part for people. 102 | - Some people may drop out after break/lunch/an hour etc. Don’t take it personally but also help a group to recover from the loss of a member. 103 | - Some people might not speak English as a 1st language or may be more comfortable with a different language. 104 | - People might swap groups. 105 | - People might have disagreements and part of your role as an organizer/facilitator is to manage these disputes. 106 | 107 | 108 | ### Post-event: 109 | - Post briefing for participants. 110 | - Post-event online meet up to follow up on ideas raised at the event. 111 | - Remind attendees of online space to discuss ideas. 112 | - Follow-up guides on how to continue contributing. 113 | 114 | 115 | 116 | ## Template for further workshops 117 | 118 | **City name:** Disaster/Relevant scenario type + TenFour/OSS: 119 | **News story:** [Link goes here] 120 | 121 | *Example: 122 | **City name:** Bangalore: Kerala flood rescue + TenFour: 123 | **News story:** [gulfnews kerala story](https://gulfnews.com/world/asia/india/for-second-year-in-a-row-kerala-floods-wreak-deadly-havoc-1.1565616937234) 124 | 125 | **Witnesses to reach out to:** 126 | Look for meetup groups, community groups, conference contacts and anyone with experience of the crisis/OSS product focus. 127 | People to invite: Invite attendees to the workshop. Can be via a/the conference or connected communities in the locality. 128 | 129 | 130 | **People to invite:** 131 | If there are specific people/groups you want to be invovled in the workshop. 132 | 133 | *Example: One of the issues that we will focus on in the workshop has chatbot functionality therefore we want to ask people with some chatbot experience to attend. 134 | 135 | TenFour/OSS Issue to focus on: 136 | 137 | | Title of issue| Description of issue| Issue link | Action needed | 138 | | ------------- | ----------------- | ---------- | -------------------------------- | 139 | | Issue title | Issue Description | [Link/s] | Any actions on the issue needed? | 140 | | Issue title | Issue Description | [Link/s] | Any actions on the issue needed? | 141 | | Issue title | Issue Description | [Link/s] | Any actions on the issue needed? | 142 | 143 | *Example:* 144 | 145 | | Title of issue| Description of issue| Issue link | Action needed | 146 | | ------------- |------------- | ---------- | --------------------------------| 147 | | **SOS button & Status updates** | In certain situations, my request may be extremely urgent and I may be in immediate danger. In these cases I need ways of communicating information to my org that maintains my safety and communicates the severity of the problem. | [Issue 106](https://github.com/ushahidi/tenfour/issues/106) [Issue 66](https://github.com/ushahidi/tenfour/issues/66) | Merging of the two issues and clearly defining the needs of the feature. | 148 | 149 | 150 | **Other issues that might be connected & important are:** 151 | - Title + description of issue - [issue link] 152 | - Title + description of issue - [Epic issue link] 153 | - Title + description of sub-issue [link] 154 | - Title + description of sub-issue [link] 155 | - Title + description of sub-issue [link] 156 | 157 | 158 | ### Scenarios to look at: 159 | Name of the type of user and their primary concern/objective - Short paragraph on there scenario and set of concerns. What they might be thinking, feeling, doing etc. in the given scenario of TenFour/OSS. 160 | 161 | *Example:* 162 | Kerala ex-resident - remote volunteer - Concerns are how to help family & friends from a safe location. Decisions on whether to return to assist and who/what orgs to access to do that safely. Or support remotely. Often spend a lot of time trying to contact family & friends in the area and sometimes coordinating their rescue via official or non-official means. 163 | 164 | 165 | ## Slide deck. 166 | [Located here TBC](https://drive.google.com/drive/folders/1U0DfmGRaXAwqXR-S-BxCHPmyd_sYOYGz?usp=sharing) 167 | 168 | 169 | ## Resource files. 170 | [Located here TBC](https://drive.google.com/open?id=10HkPK6viEAXvXYcuuQEZPJrKKC9G6fDH) 171 | 172 | 173 | ## Sticker sheet files. 174 | [Located here](https://github.com/ushahidi/tenfour/blob/develop/design-contributions.md) 175 | 176 | 177 | -------------------------------------------------------------------------------- /Launch-article-June-2019.md: -------------------------------------------------------------------------------- 1 | # Design should be open for all. 2 | 3 | Designers want to tackle big societal problems and contribute to Open Source Software (OSS), but the current developer centred framework for creating OSS makes this appear unattainable. As a result, Open Design (OD) attempts, using [Ushahidi’s](https://www.ushahidi.com/) Open Source crisis communication tool, [TenFour](https://www.tenfour.org/) as a case study, to create and deliver accessible processes to enable designers to collaborate and contribute to OSS on a global scale. 4 | 5 | ## What is Open Design? 6 | 7 | Open Source tools whose core purpose is to make the world a better place are mostly built with little or no contribution from professional designers, leading to poor User Experience, unappealing interfaces, and little or no thoughts towards ethical design concerns. When we think “Open Source”, we immediately think “developers”. We don’t necessarily consider other people, such as designers, who are contributing to creating useful and usable software. 8 | 9 | Designers want to tackle big societal problems and improve the human condition. Designers want to contribute to OSS but don’t know what they can do to contribute and how to do it. Designers are starting to pay more attention to design ethics and designing for social good. To reframe the conversation to include design ethics, usability, and aesthetics of OSS and to address these issues, Open Source Design (OSD) is emerging as an area of discussion. OSD involves co-creation, in which the outcome is designed by the community, rather than one entity, such as a private company. OSD, which is based on publicly shared design information and thinking, can result in a framework for developing projects that might be beyond the resource of any single company or country, leading to better products and services. 10 | 11 | The aim of Open Design is to contribute to and create useful, easy to use, ethical products that have a social impact by using a collaborative multidisciplinary approach that engages designers from all over the world. 12 | 13 | 14 | ## What do we need to enable OSD? 15 | 16 | So far, organisations that exemplify open source design including Mozilla, Simple.org, and openIDEO.com have successfully implemented workflows that suited a single project that may or may not have been an explicitly ‘for good’ project. Other organizations or individuals might have wanted to implement something similar, but lacked proper documentation or applicability to modern design tooling. Open Design sets out to enable OSD at scale, for everyone, and what we believe is required for success is: 17 | 18 | * A defined process that enables designers to participate in the product design process from definition to implementation. 19 | * A means of distilling design research to make it available and usable for others. 20 | * Properly defined methods of managing design artefacts. 21 | * A collaborative process for defining outcomes, including proper reuse of parts of said outcome in other projects as well as for reviews and approvals. 22 | * A reliable technical infrastructure that allows all of the above happen globally. 23 | 24 | Added, inclusion and involvement in the process of developing Open Source Software are among the toughest challenges of the design profession, especially for designers interested in ethical design. There seem to be considerable roadblocks between core developer teams in OSS and designers, thus making the process of designer contributing appear unattainable. Some of these barriers include difficult taxonomy and complex developer-focused software. 25 | 26 | By creating intentional systems such as our inclusive and open methodology and focus on OSS projects that do good in the world, wherein designers can contribute to the development of OSS, Open Design also ensures that we’re not building products for ourselves, instead, we’re building for “users”. Open Design allows participants who are motivated to help solve problems while developing their own skills, expertise and knowledge by gaining new experiences. 27 | 28 | ## Principles for Open Design 29 | 30 | * Open Design (OD) embraces human-centred design and a multidisciplinary framework. 31 | * OD amplifies attitudes, methods, tools that are geared towards collaboration instead of competition, as well as a learning-based approach. 32 | * OD 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. 33 | * OD espouses transparency, accountability, and flexibility. 34 | 35 | 36 | ## Open Design‘s aims 37 | 38 | In order to address the issues and barriers to designer contributions in OSS, we are enabling Open Design. 39 | 40 | The goal of this project is to create and deliver accessible processes and systems to organise distributed remote, collaborative design at a global scale, thereby enabling design contributions to OSS. This includes an optimized replicable workflow that can be supplemented through light-weight integrations with software tools when necessary. In view of the goals of ethical design and designing for social good, the framework is especially aimed at contributing to social enterprises and humanitarian organisations. 41 | 42 | The framework will focus on a mix of sharing how the product is designed (designing in the open) and creating resources such as icon sets, themes, design systems, illustrations, and toolkits (as in the work of [undraw.co](https://undraw.co/)) that other people can use, but will lean more on a collaborative, multidisciplinary, open approach, using collective co-design to [tackle wicked problems](https://theblog.adobe.com/why-i-dont-believe-in-empathic-design-don-norman/), such as crisis communication, that are hard to generally empathise with. The output of this project will go beyond UI deliverables to include other aspects of Design such as UX research, product insights, accessibility and usability. 43 | 44 | ## Next Steps 45 | 46 | Using Ushahidi’s OSS tool, [TenFour](https://www.tenfour.org/), as a case study, over a 12 month period, we will attempt to create this framework to help designers contribute to Open Source Software. The project will start by using [Adobe XD](https://www.adobe.com/uk/products/xd.html) build-out and publish an open design system with all of the design artefacts, guidelines, and documentation necessary to contribute to TenFour as an open-source designer. There will also be [workshops and Design Jams at conferences](https://medium.com/tenfour/ushahidi-hosts-tenfour-design-jam-with-designit-adobe-at-interaction-week-19-967a9a0cce97) in order to introduce [Open Design methodology](https://github.com/ushahidi/opendesign/blob/master/Methodology.md) to global design leaders in various countries and generate thought leadership content on how the tools and methods of open-source design might address today’s most pressing problems. The learnings from the workshops will be used to iterate and improve on the Open Design method. 47 | 48 | The expected outcomes of the project are categorized into Product and Knowledge Sharing. On the Product end, there will be active contributions to TenFour where designers can become familiar with contributing to an OSS tech for good project. In addition, there will be an opportunity to suggest a framework for how designers can contribute to OSS based on the TenFour approach using Adobe XD. 49 | 50 | On the Knowledge Sharing hand, the research and development process, including learnings and insights from the process will be carefully documented and shared in various accessible formats including reports, a website, and design conferences around the world. We will be sharing thought leadership pieces, best practices for designing in the open, and the challenges faced by both the core team and other community members. We hope to further conversations on building tools that integrate Adobe XD further into the ecosystem of tools for OSS and the tech for good community. 51 | 52 | – The Open Design Team 53 | 54 | 55 | ### Project Partners 56 | 57 | The project is the result of a collaboration among [Adobe](https://theblog.adobe.com/ushahidi-works-with-designit-and-adobe-to-give-people-a-voice/), [Designit](https://medium.designit.com/designing-for-emergencies-be899148e806) (a Wipro company), and [Ushahidi](https://medium.com/tenfour/ushahidi-hosts-tenfour-design-jam-with-designit-adobe-at-interaction-week-19-967a9a0cce97). Read about the previous two Design Jam’s that inspired this project here on [Adobe’s blog](https://theblog.adobe.com/ushahidi-works-with-designit-and-adobe-to-give-people-a-voice/), here on [Designit’s blog](https://medium.designit.com/designing-for-emergencies-be899148e806) and [here on Ushahidi’s blog](https://medium.com/tenfour/ushahidi-hosts-tenfour-design-jam-with-designit-adobe-at-interaction-week-19-967a9a0cce97). 58 | 59 | [Adobe](https://www.adobe.com/) is a multinational computer software company focused on the creation of multimedia and creativity software products, as well as digital marketing software. The Open Design Project has been supported by the [Adobe fund for design](https://www.adobe.com/products/xd/adobe-fund.html). 60 | 61 | [Designit](http://www.designit.com/) is an international strategic design firm working with ambitious brands to create high-impact products, services, systems and spaces that people love. 62 | 63 | [Ushahidi](http://www.ushahidi.com/) is a non-profit tech organisation aimed at helping marginalized people raise their voice and get the support they need. Ushahidi builds technology to solve global humanitarian and international development problems, and increase the speed and effectiveness of emergency response. 64 | 65 | ### Notable Open Source Design projects 66 | 67 | [Simple](https://medium.com/@dburka/open-source-identity-design-for-simple-4025c6d48acc), a health tracking and reporting app for healthcare workers and patients. 68 | 69 | [Openideo.com](https://www.openideo.com/), Through OpenIDEO, people worldwide come together to build on each other’s skills and ideas for good. 70 | 71 | [Redhat](https://www.redhat.com/en/blog/designing-better-user-experience-open-source-software?source=bloglisting&f%5B0%5D=post_tags%3AProduct+design), ChRIS project, enabling doctors to make use of leading-edge, yet frustratingly esoteric, software to improve patient care is an example of the larger challenge of UX in open source. 72 | 73 | [Mozilla](https://blog.mozilla.org/opendesign/), An Open Design process that builds from our open source beliefs. A guided and gated design process in four phases: Ideation, Concepting, Refinement and Guidance. 74 | -------------------------------------------------------------------------------- /Methodology.md: -------------------------------------------------------------------------------- 1 | # Methodology: How Open Design will work. 2 | 3 | ## Principles for OSD. 4 | 5 | * 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.). 6 | 7 | * Open Design amplifies attitudes, methods, tools that are geared towards collaboration instead of competition, as well as a learning-based, mentoring approach. 8 | 9 | * 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. 10 | 11 | * Open Design is a multidisciplinary, intersectional and inclusive space. 12 | 13 | * Open Design advocates for transparency, accountability, and flexibility. 14 | 15 | 16 | ## Open Design as events. 17 | 18 | Conduct a series of events (and propose a replicable structure to the events for the community to take forward) that uses with [TenFour](https://www.tenfour.org/), [Ushahidi’s](https://ushahidi.com/) 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. 19 | 20 | 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. 21 | 22 | ## To test we intend: 23 | 24 | 1. To build a community around a real life humanitarian OSS project (in case of the Open Design project this is Ushahidi's [TenFour](https://www.tenfour.org/)) 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. 25 | 26 | 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._ 27 | 28 | 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. 29 | 30 | 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. 31 | 32 | 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. 33 | 34 | 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. 35 | 36 | 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. 37 | 38 | 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. 39 | 40 | 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. 41 | 42 | 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. 43 | 44 | 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. 45 | 46 | ## Testable Criteria. 47 | **Open Design events must include:** 48 | 49 | 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). 50 | 51 | 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. 52 | 53 | 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. 54 | 55 | 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. 56 | 57 | 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. 58 | 59 | 6. A leader/facilitator in the organising group must be established through consensus. 60 | 61 | 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. 62 | 63 | 8. The event focus must be on well-defined, tangible issues that need addressing in the OSS. 64 | 65 | 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. 66 | 67 | 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._ 68 | 69 | 11. An intro to the OSS must be done at the beginning of the event. [Example slide deck](https://drive.google.com/file/d/1B80_hcdWD-7SQFdssUzzRegfChtbwjdH/view) 70 | 71 | 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.”_ 72 | 73 | 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. 74 | 75 | 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._ 76 | 77 | 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._ 78 | 79 | 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. 80 | 81 | 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. 82 | 83 | 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. 84 | 85 | 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._ 86 | 87 | 20. Mitigate the use of design jargon and allow for specific, relevant insight into the feasibility of a design ‘solution’. 88 | 89 | 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. 90 | 91 | 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. 92 | 93 | 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._ 94 | 95 | 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. 96 | 97 | 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. 98 | 99 | 26. The CoC or right to record has been breached should be followed for each event 100 | 101 | 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. 102 | 103 | 28. The event should be documented and the process and outcomes should be made publicly available on the property of the OSS. 104 | 105 | 29. Where appropriate, research/results, documentation and recording must be made publicly available on the Open Design property. GDPR compliance is essential. 106 | 107 | 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. 108 | 109 | 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. 110 | 111 | 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. 112 | 113 | 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. 114 | -------------------------------------------------------------------------------- /license: -------------------------------------------------------------------------------- 1 | License 2 | 3 | CC BY-SA 4.0 4 | https://creativecommons.org/licenses/by-sa/4.0/ 5 | 6 | Creative Commons Attribution-ShareAlike 4.0 International Public License 7 | By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions. 8 | 9 | Section 1 – Definitions. 10 | 11 | Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image. 12 | Adapter's License means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License. 13 | BY-SA Compatible License means a license listed at creativecommons.org/compatiblelicenses, approved by Creative Commons as essentially the equivalent of this Public License. 14 | Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. 15 | Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements. 16 | Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material. 17 | License Elements means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike. 18 | Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License. 19 | Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license. 20 | Licensor means the individual(s) or entity(ies) granting rights under this Public License. 21 | Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them. 22 | Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world. 23 | You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning. 24 | Section 2 – Scope. 25 | 26 | License grant. 27 | Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to: 28 | reproduce and Share the Licensed Material, in whole or in part; and 29 | produce, reproduce, and Share Adapted Material. 30 | Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions. 31 | Term. The term of this Public License is specified in Section 6(a). 32 | Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material. 33 | Downstream recipients. 34 | Offer from the Licensor – Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License. 35 | Additional offer from the Licensor – Adapted Material. Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter’s License You apply. 36 | No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material. 37 | No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i). 38 | Other rights. 39 | 40 | Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise. 41 | Patent and trademark rights are not licensed under this Public License. 42 | To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties. 43 | Section 3 – License Conditions. 44 | 45 | Your exercise of the Licensed Rights is expressly made subject to the following conditions. 46 | 47 | Attribution. 48 | 49 | If You Share the Licensed Material (including in modified form), You must: 50 | 51 | retain the following if it is supplied by the Licensor with the Licensed Material: 52 | identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated); 53 | a copyright notice; 54 | a notice that refers to this Public License; 55 | a notice that refers to the disclaimer of warranties; 56 | a URI or hyperlink to the Licensed Material to the extent reasonably practicable; 57 | indicate if You modified the Licensed Material and retain an indication of any previous modifications; and 58 | indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License. 59 | You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information. 60 | If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable. 61 | ShareAlike. 62 | In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply. 63 | 64 | The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License. 65 | You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material. 66 | You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply. 67 | Section 4 – Sui Generis Database Rights. 68 | 69 | Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material: 70 | 71 | for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database; 72 | if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and 73 | You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database. 74 | For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights. 75 | Section 5 – Disclaimer of Warranties and Limitation of Liability. 76 | 77 | Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You. 78 | To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You. 79 | The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability. 80 | Section 6 – Term and Termination. 81 | 82 | This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically. 83 | Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates: 84 | 85 | automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or 86 | upon express reinstatement by the Licensor. 87 | For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License. 88 | For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License. 89 | Sections 1, 5, 6, 7, and 8 survive termination of this Public License. 90 | Section 7 – Other Terms and Conditions. 91 | 92 | The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed. 93 | Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License. 94 | Section 8 – Interpretation. 95 | 96 | For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License. 97 | To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions. 98 | No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor. 99 | Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority. 100 | -------------------------------------------------------------------------------- /translating-issues-to-design-challenges.md: -------------------------------------------------------------------------------- 1 | # Translating (developer) Issues to (design) Challenges 2 | 3 | This is an activity that the Open Design team have been trialling during 2020 workshops across the different stakeholder groups of: Designers (all definitions and abilities), OSS maintainers/Owners, Humanitarian projects/organisations with an OSS. 4 | 5 | You can find links to the working whiteboard that we used a tool Miro for below: 6 | 7 | 8 | [Miro Workboard for Open Source 101:at home 2020](https://miro.com/app/board/o9J_luu3JGw=/?share_link_id=617301176692) 9 | 10 | [Miro Workboard for UX Bristol 2020](https://miro.com/app/board/o9J_lq02e_8=/?share_link_id=695937082946) 11 | 12 | [Miro Workboard for RighstCon 2020](https://miro.com/app/board/uXjVKM74nGY=/?share_link_id=247058537995) 13 | 14 | 15 | ----- 16 | ## How to change an issue into a design challenge 17 | 18 | One key aspect of encouraging design participation in the humanitarian, human rights and open source space is being able to take an issue that is written 'for developers or techies' and finding a pathway for design to hold space in that place. This can take the form of 'translating' a developer focussed and written issue into a 'design brief of challenge' The tricky part, it still needs to make sense to and be clear for developers and not 'just the ones you can have a face to face chat with, but developers globally (yup OSS being global and open!) 19 | 20 | 21 | **You can use the examples below if you prefer but we encourage you to use your real life projects.** 22 | 23 | *Here you'll find some examples of Humanitarian OSS projects/issues. If you have your own project (whether it's online or not, please use that instead! a working example is always better!) 24 | The easy/hard level has been assessed by Eriol Fox and may or may not reflect your individual comfort levels. We have tried to pick and give examples that are accessible for varying levels of experience and understanding.* 25 | 26 | | Easy-ish | | Hard-ish | 27 | |---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| 28 | | TenFour | | Hikaya | 29 | | https://github.com/ushahidi/tenfour | | https://github.com/hikaya-io/activity | 30 | | TenFour is an emergency check-in application for teams that unites multiple communication channels: SMS, email, desktop, mobile and chat. It's a team check-in system that gets answers when you need them most. | | A modern way for nonprofits to manage project activities and indicator results. Try out Activity using our hosted version at hikaya.io . | 31 | | TenFour: Fire Marshall: user training and teaching | | Hikaya: i18n: How to determine the language to display Activity in? | 32 | | https://github.com/ushahidi/tenfour/issues/203 | | https://github.com/hikaya-io/activity/issues/484 | 33 | | | | | 34 | | Pa11y | | Chayn - Little Window | 35 | | https://github.com/pa11y/pa11y-dashboard | | https://github.com/chaynHQ/little-window | 36 | | Pa11y Dashboard is a web interface to the Pa11y accessibility reporter. Pa11y is your automated accessibility testing pal. It runs accessibility tests on your pages via the command line or Node.js, so you can automate your testing process. | | Little window is a clever little cat chatbot that directs women to the information they are looking for as quickly as possible. Feminist tech project helping survivors of abuse get the information & support they need. Open-source. Volunteer-run. 'Design with, not for'. | 37 | | Pa11y: Add Groupings to pages | | Chayn: no guiding issue :( create one! | 38 | | https://github.com/pa11y/pa11y-dashboard/issues/254 | | https://github.com/chaynHQ/little-window | 39 | | | | | 40 | | CHAOSS | | The New Sanctuary Coalition | 41 | | https://github.com/chaoss | | https://github.com/CZagrobelny/new_sanctuary_asylum | 42 | | This repository is part of the CHAOSS Community, a Linux Foundation project focused on creating analytics and metrics to help define community health. | | The New Sanctuary Coalition is a network of congregations, organizations, and individuals standing publicly in solidarity with families and communities resisting detention and deportation. This internal database software facilitates NSC's core programs and allows them to operate at increasing scale. | 43 | | Interview campaign with underrepresented groups in Open Source | | Admins can bulk invite users | 44 | | https://github.com/chaoss/wg-diversity-inclusion/issues/294 | | https://github.com/CZagrobelny/new_sanctuary_asylum/issues/247 | 45 | 46 | 47 | 48 | It's best to form groups for this challenge, around 4 -5 people involved in product creation, but be cautious of 'developers' being the dominant voice in this activity or prioritising 'technology' and 'code' over the problem definition. 49 | 50 | Here's an example of what I would call a 'translated design challenge' 51 | 52 | From this [original issue](https://github.com/ushahidi/tenfour/issues/119) 53 | 54 | ### Push alert after a configurable time that someone has not responded to a check-in 55 | 56 | Is your feature request related to a problem? Please describe. 57 | I'm frustrated when I have to check for myself whether someone has responded to a check-in on TenFour. 58 | 59 | **Describe the solution you'd like** 60 | As a user that has constructed a check-in and send it to my team I want to receive an in-app push alert after a configurable time that someone has not responded to a check-in. This should also display in a ‘history’ or notifications section. 61 | 62 | To this design challenge: 63 | 64 | ### Push alert after a configurable time that someone has not responded to a check-in 65 | 66 | **Please describe the problem from at least one ‘users’ point of view:** 67 | 68 | As a person responsible for other people in TenFour it worries me when I don’t get a quick answer back from a team member about whether they are ok or not. When there is a crisis, knowing how much time has gone by without a response is important and knowing who hasn’t replied yet helps me to set up fall-back plans for a worst case scenario. But crisis is complicated and I might have other things that I need to concentrate on. That’s why I’d like some way of TenFour telling me when someone hasn’t replied in a certain time. 69 | 70 | One way we thought of doing this is through configurable, push alerts on a persons device. 71 | 72 | 73 | The event that triggered this issue was a recent terrorist attack in Nairobi: https://www.bbc.co.uk/news/world-africa-46880375 74 | 75 | We are designing for at least two user groups primarily after a disaster, but they may be many more users. 76 | 77 | **User 1 -** NGO Leads or people managing a TenFour domain. Typically have the role types of Owner and Admin in TenFour. 78 | 79 | The owner of the TenFour organization could be the teacher of a class looking after students in a crisis. These users often pre-create groups in TenFour based off certain criteria but also want groups to be flexible. 80 | 81 | **User 2 -** The people in the TenFour domain that receive a TenFour check-in and have been asked to reply. They may be moving from location to location in order to be safe. They may not have their phone immediately to hand. 82 | 83 | 84 | **What is success for our user/s?** 85 | Admin is notified who has not responded in a time frame that works for them 86 | TenFour users are able to respond when/if they can. Seeing alerts may not be useful for these users. 87 | 88 | 89 | **What are our design constraints?** 90 | 91 | Requires: 92 | Mobile telecom connection or internet connection.
Users are on the TenFour system as a ‘person’. 93 | Must be developable within existing tech stack functionality 94 | Will be completed by OSS developers 95 | 96 | 97 | ### Remember, writing this isn't just for your own benefit it's for all people who will see and learn from it's benefit. 98 | 99 | That's developers, other designers, users, researcher and the OSS community can look to examples like this for good practice. Set a good example :) 100 | 101 | 102 | -------------------------------------------------------------------------------- /events.md: -------------------------------------------------------------------------------- 1 | Events and conference appearances will be in chronicalogical order with most recent at the top of each list. 2 | 3 | # Workshops 4 | 5 | 6 | ### Taipei 2019 7 | 8 | The Open Design team has been accepted and invited to the excellent [Open UP Global Summit in Taipei](https://www.openup.global/), Taiwan November 30th to December 01st 2019 to deliver a workshop. 9 | 10 | Open UP summit is the first interdisciplinary conference focused on open source projects and products in Asia-Pacific, aiming to provide you a unique conference experience by integrating global resources and developing open source products with a guided and enjoyable process. 11 | 12 | Open Design Team will be running a talk and demo of Open Design and then running a split workshop across two days on ‘Open Design Workshop for Humanitarian Challenge’ where attendees will get started with contributing design to OSS with TenFour, the crisis communication tool from Ushahidi. 13 | 14 | Open Design is a project-based approach to including Design in the creation of Open Source Software that makes a meaningful impact in the world. It is led by led by Ushahidi, in partnership with Designit and Adobe. 15 | 16 | The workshop will be focused on TenFour issues relating to Cyclone & Typhoon preparation and response. 17 | 18 | [Issue 225](https://github.com/ushahidi/tenfour/issues/225): Chained Check-ins as task lists for volunteers helping post-disaster. 19 | [Issue 215](https://github.com/ushahidi/tenfour/issues/215): Create a location-based group when someone add a location on their profile. 20 | [Issue 130](https://github.com/ushahidi/tenfour/issues/130): Create and manage sub-groups within TenFour. 21 | [Issue 224](https://github.com/ushahidi/tenfour/issues/224): Understand and see what skills volunteers in a specific TenFour organisation have in a crisis scenario. 22 | [Issue 112](https://github.com/ushahidi/tenfour/issues/112): Check-ins and messages should have “severity” levels. 23 | In keeping to the Open Design methodology, the workshop will also include witnesses: people that have direct experience of the humanitarian challenge (in this case the Typhoons, Cyclones and the resulting effect on the people and country). Before the event, participants will receive a packet providing links to the TenFour/OSS sticker sheet, activities like Empathy maps, storyboards, Inspiration boards, and other relevant information. 24 | 25 | 26 | ### Bangalore 2019 27 | 28 | The Open Design team has been accepted and invited to the excellent [DesignUP! conference in Bangalore 2019](https://designup.io/blr2019/) to deliver a masterclass workshop on the 14th of November. 29 | 30 | DesignUp is an annual design conference focused on design in, and for, tech. The aim is to encourage conversations and work that make Tech and Businesses more human and humane as well as more impactful to people and the ecosystem in general. 31 | 32 | Open Design Team will be hosting a full-day masterclass workshop on Creating impact with open source and humanitarian tech at DesignUp. 33 | 34 | Open Design is a project-based approach to including Design in the creation of Open Source Software that makes a meaningful impact in the world. It is led by led by Ushahidi, in partnership with Designit and Adobe 35 | 36 | The workshop will be focused on TenFour issues relating to the [Kerala floods](https://gulfnews.com/world/asia/india/for-second-year-in-a-row-kerala-floods-wreak-deadly-havoc-1.1565616937234): 37 | 38 | [Issue 106](https://github.com/ushahidi/tenfour/issues/106) and [Issue 66](https://github.com/ushahidi/tenfour/issues/66): SOS button & Status updates 39 | [Issue 215](https://github.com/ushahidi/tenfour/issues/215): Create a location-based group when someone adds a location on their profile 40 | [Issue 131](https://github.com/ushahidi/tenfour/issues/131): Check-in urgency – When replying to a check-in 41 | [Issue 57](https://github.com/ushahidi/tenfour/issues/57): Messaging between TenFour and Users 42 | 43 | 44 | ### Seattle 2019 45 | 46 | In February 2019, the Open Design team ran a second Design Jam as part of [IxDA’s Interaction Week in Seattle](https://interaction19.ixda.org/), USA. At this event we tackled issues around the impacts of intense rain and flooding in Seattle, a school trip gone wrong, and the flooding of a nearby wastewater treatment plant. 47 | 48 | An article about the [results of the event was posted to the Ushahidi blog](https://www.ushahidi.com/blog/2019/02/19/ushahidi-hosts-tenfour-design-jam-with-designit-adobe-at-interaction-week-19) and the call for entries and [goals for the event](https://interaction19.ixda.org/program/workshop-tenfour/) is available online. 49 | 50 | The Design workshop structure 51 | The Jam day started out with building teams, defining the OSS tool ‘TenFour’, it’s history, what it does and how to access resources and who to ask questions about the process of building prototypes and designs for the tool. 52 | 53 | Nathanial Manning was present to give the background history on TenFour and the current product build focus and product planning. 54 | 55 | The workshop took place while an unusual snowstorm shut down airports, public transit and individual traffic in the Seattle area. While the coincidence didn’t help conference attendees in getting from A to B that very day, and had quite some impact on Interaction Week as such, some locals and local media described the weather scenario as an actual crisis. 56 | 57 | The attendees then went through several discovery exercises including Empathy Mapping, Defining the problems, Ideation, Story-boarding and then Prototyping and then presenting the results back to the attendees. 58 | 59 | Briefs & Scenarios 60 | Water Treatment Plant in Shilsholebay 61 | West point is a Seattle based waste water treatment plant with over 121 employees that work across the various functions in the plant. 62 | 63 | Since the 2017 early hours flooding, the management team has increased effort on communication when heavy rains are near. 64 | 65 | TenFour is a pre-installed app on the company phones. Employees use their own phones, but all employees know about and were trained on the app and luckily it was not needed in 2017. 66 | 67 | Who’s taking part: 68 | 69 | Maria, a 32 year old performance manager who has worked there for 4 years. She is the good soul of the team. 70 | 71 | Stuart, a 25 year-old technician intern who just recently joined the plant. Stuart is rather shy and introverted. 72 | 73 | Jeff, a 34-year old sampling technician, who is the company’s expert for water quality. 74 | 75 | Eireni, a 36-year-old technical engineer who’s been at the plant for over 10 years. She knows the layout of the plant very well. 76 | 77 | Ali, a 46-year old General Operative and pump engineer. Ali is HIV positive and has a weakened immune system. 78 | 79 | Kurtis is a 65 year old security guard that finishes their 8 hour shift at 13.30. 80 | 81 | What is happening: 82 | 83 | A typical day at the plant has started early. The plant is staffed 24 hours a day for security reasons. 84 | 85 | Moderate rain was forecasted for today and the plant was prepared for it. Around 8am the rain began to fall heavier than forecasted and expected. The rain continues to fall increasingly heavier… 86 | 87 | It’s early in the afternoon already. With increasing nervousness, the engineers/technicians go about their checking of machinery in pairs. Ali, who is monitoring from a central computer gets up as he sees water drops coming from the ceiling and is alarmed when he starts observing dangerous water levels in the treatment tanks. The whole team decides to check with the other colleagues in the building and to leave to arrive home safely. 88 | 89 | But when they open up the door to the hallway, they can see that there is already water running down the stairs and some of the lights have come down with water running over them. They can already smell electrical faults and the light start flickering. Will it be safe to step into the water with all these cables hanging down? 90 | 91 | Maria worries about her colleague Kurtis who was doing a final patrol before finishing his shift and handing over to another staff member Pete. Is he safe? She decides to try to locate Kurtis. 92 | 93 | Stuart and Jeff are preoccupied with containment protocols and reporting to be aware of their immediate surroundings. 94 | 95 | They really need to get out of here, no matter what…But how can they make sure that everybody gets out safely and on time? 96 | 97 | University of Washington: Student trip to Oso 98 | The Geography department of UWS has taken 35 1st year university students and 4 faculty members out to the area of Oso to investigate the environment for an assignment. There is a staff member based in the central University campus as a HQ contact. 99 | 100 | Since the mudslides of 2014 the faculty members are careful to avoid previous areas of high-danger and there route has been planned. 101 | 102 | TenFour is installed app on the faculty’s phones but maybe not all the students. All faculty know and were trained on the app and safety protocol. 103 | 104 | Students are less aware…as are their families back home… 105 | 106 | Who’s taking part: 107 | 108 | 4 faculty members including: 109 | 110 | Ajara, who’s had family emergency texts throughout the day and is distracted. 111 | 112 | Freya, Who lost distant relative in the 2014 Oso mudslides. 113 | 114 | 35 students including: 115 | 116 | Ishra, who doesn’t feel comfortable to walk long distances, but is too shy to tell anyone. 117 | 118 | Tom, who’s long-term boyfriend is currently on a one week business-trip in Rome. 119 | 120 | Cleo, who is trained in first aid and emergency response who does regular recreational climbing. 121 | 122 | Jason, who is bold and a little fool hardy. Wants to explore the area more than is safe. 123 | 124 | What is happening: 125 | 126 | The faculty and students are together in a safe but remote location in Oso on the edge of the warning zone from 2014. They are preparing for a day of collecting samples and recoding data and have heavy backpacks, waterproofs and boots on. 127 | 128 | Around 09.30 Ajara receives the first middle severe weather alert by text, where the region would only mildly get influenced by the outer skirts of a thunderstorm hitting the region during late afternoon. They’re prepared with water proofed equipment and have a pre-approved route. But two hours later it a cloudburst arrives and Ajara receives another alert stating that the severity of the heavy rainfall unexpectedly changed so they might end up closer to the center of the event than expected. 129 | 130 | They’re preparing to find a way to end their study trip, while it starts raining more and more severely. The water starts collecting rapidly in basins. Half an hour and suddenly Cleo states that they are losing visibility in the storm downpour and suggests signalling for help. 131 | 132 | One can sense the tension in the group, although everybody tries to remain calm. But suddenly Tom notices that Jason, along with 3 of their fellow students are not in the larger group. They start calling out and panicking trying to use their devices but the signal has become patchy in the location. 133 | 134 | What are the key challenges and questions they’re facing? In addition the team in the main campus in central Seattle want to know if the field trip is safe. 135 | They all have their smartphones with them and the TenFour-App installed. What would you do and how could the app help in order to get out out of that situation and make sure everyone gets back to safety? 136 | 137 | Seattle Software AG: Roads of Seattle 138 | Seattle Software AG is a Seattle based software company with 400 employees that develops IT solutions for a mobile and interconnected world. As communication is crucial for their business, all employees receive a smart phone when entering the company. 139 | 140 | Some of the staff members live outside of central Seattle in the areas of Duvall, Snoqualmie and nearby areas. The company is not sure how many are in those areas and staff regularly visit clients outside central Seattle. 141 | 142 | TenFour is a pre-installed app on the company phones but not on their personal phones. The reception has been mixed to use the app… 143 | 144 | Who’s taking part: 145 | 146 | Hector, a 36-year-old designer who used to work as a voluntary firefighter in his twenties. 147 | 148 | Ben, a 24-year-old trainee who has just started at the company. Ben is rather shy and introvert. 149 | 150 | Eden, a 40-year old project manager, who likes to always have an overview about things going on. 151 | 152 | Max, a 16-year-old, who is just visiting Seattle Software AG as High school intern. He has no company phone. Travelling with Eden. 153 | 154 | Jean is a 78 year old woman who lives in a retirement home in Duvall and just finished an interview with Hector, Eden and Max. 155 | 156 | Clint is the office manager and arrived in the main central office before 6am. An early bird. 157 | 158 | What is happening: 159 | 160 | Hector, Eden and Max are on their way back from a user interview with a community in Duvall looking at improving government services with the Elderly and have just started driving back to the central office. 161 | 162 | It has been raining quite heavily, so they’re trying to get back as fast as possible. After 10 mins of driving in low visibility they start driving through larger pools of water. 163 | 164 | But travel time should be a 1/2 hour only, anyway – so they keep going with their review about the specific client situation when they suddenly notice that there are cars stopped by the side of the roads. There’s no information available, so they just carry on driving for a bit. 165 | 166 | 167 | Max is using his phone in the backseat and nobody checked whether he has a seatbelt on. 168 | 169 | Eden and Hector are starting to worry about the retirement home and also whether they will get back home let alone the central office! Who is going to notify Max’s parents? 170 | 171 | Eden tries to check the situation, but they can’t find any advice online. 172 | 173 | Clint is noticing that the team are close to arriving but haven’t heard from them since this morning and is worried about the weather. 174 | 175 | What are the key challenges and questions they’re facing? 176 | 177 | All of the team members have the App Tenfour installed, but barely use it. 178 | 179 | How could the App help them get out of the situation safely? 180 | 181 | What about the retirement home? 182 | 183 | Disclaimer 184 | All the information and scenarios included in these slides have been complied and inspired from research and resources online. 185 | 186 | We can not vouch for the accuracy and factual information of the sources. They offer us, as non-native Seattle folk, a guide of how the infrastructure of Seattle operates in heavy rain, storm and mudslide events. 187 | 188 | We ask that the attendees offer up additional information and facts around these scenarios to inform their work. 189 | 190 | 191 | ### Berlin 2018 192 | 193 | One of the fundamental building blocks to the Open Design project happened in form of a workshop on July 21st, 2018, in Berlin, Germany. We’ve been tackling issues faced around Berlin flood risk areas including the subway, rural rivers and office blocks. 194 | 195 | There are two full write ups of this event including a video: 196 | 197 | [“Designing for emergencies”](https://medium.designit.com/designing-for-emergencies-be899148e806) by Thomas Kueber 198 | [“Ushahidi Works with Designit and Adobe to Give People a Voice”](https://theblog.adobe.com/ushahidi-works-with-designit-and-adobe-to-give-people-a-voice/) by Andre Jay Meissner 199 | 200 | *The Design Jam structure* 201 | The Jam day started out with building teams, defining the OSS tool ‘TenFour’, it’s history, what it does and how to access resources and who to ask questions about the process of building prototypes and designs for the tool. 202 | 203 | Erik Hershman and Eriol Fox of Ushahidi, the organization that built TenFour presented the background history and the current tools build focus and product planning. 204 | 205 | The attendees then went through several discovery exercises including Empathy Mapping, Defining the problems, Ideation, Story-boarding and then Prototyping and then presenting the results back to the attendees. 206 | 207 | Briefs & Scenarios 208 | The focus, fictional company ‘AG Software’ based in Mitte Berlin. 209 | Background: “Berlin Software AG is a Berlin-based software company with 400 employees that develops IT solutions for a mobile and interconnected world. As communication is crucial for their business, all employees receive a smartphone when entering the company. 210 | 211 | TenFour is a pre-installed app on the company phones. All employees know what the app is good for, but luckily it was never needed to use it. 212 | 213 | But this will change by today…” 214 | 215 | The attendees received 3 briefs to choose to prototype for.: 216 | 217 | Brief 1 218 | Office in Mitte 219 | Our users: 220 | 221 | Maria, a 32 year old developer who works for Berlin Software AG since 4 years. She is the good soul of the team. 222 | 223 | Tom, a 25 year-old-intern who just recently joined the company. Tom is rather shy and introverted. 224 | 225 | Sarah, a 34-year old UX designer, who is the company’s expert for conducting user tests in their usability lab. 226 | 227 | Ben, a 36-year-old technical engineer who’s regularly climbing since 4 years. 228 | 229 | Hans, a 46-year old developer. Hans is overweight and has asthma. 230 | 231 | What is happening: 232 | 233 | It’s one of these day’s where the office in the 5th floor. Most of the colleagues on that floor are at client meetings or at a team building event in the Spreewald. Also the other floors are quite empty today 234 | 235 | It’s middle in the afternoon in the afternoon already. As the developers have a close deadline to fulfil, most of them have been working concentratedly with their headphones on the ears. But then Tom gets up as it he sees water drops coming from the ceiling and screams out when he looks out of the window and sees the flooded street in front of the building. The whole team decides to check with the other colleagues in the building and to leave to arrive home safely. 236 | 237 | But when they open up the door to the hallway, they can see that there is already water running down the stairs and some of the lights have come down with water running over them. They can already smell the electricity and the light start flickering. Will it be safe to step into the water with all these cables hanging down? 238 | 239 | Maria worries about her colleague Sarah who wanted to conduct a usability test down in the basement. Is she safe? She decides to reach out to her and runs down the slippery stairs despite the hanging lamps. 240 | 241 | Then the rest of the group hears a strange noise and sees how the printing machine catches fire due to a short circuit. They really need to get out of here, no matter what…But how can they make sure that everybody gets out safely and on time? 242 | 243 | [You can view the first prototype here](https://xd.adobe.com/view/b491ba90-3c0c-4da3-68ce-20a79409a933-c2a0/) 244 | 245 | Brief 2 246 | Subway in Mitte 247 | Our users: 248 | 249 | Who’s taking part: 250 | 251 | Leonie, who doesn’t feel comfortable to swim long distances, but is too shy to tell anyone. 252 | 253 | Ryan, who’s 2 year old daughter is at the full-day kindergarten 254 | 255 | Max, who’s long-term boyfriend is currently on a one week business-trip in Rome. 256 | 257 | Sara, who’s a technical engineer who’s regularly climbing since 4 years, currently working in the office. 258 | 259 | What is happening: 260 | 261 | Leonie and Ryan are on their way back from a business lunch and are awaiting the next subway to head back to the office. It has been raining quite heavily, so they’re trying to get home as fast as possible. After entering the U7, they’re not able to take some seats as there are plenty of people on their way during this time. But travel time should be a 1/2 hour only, anyway – so they keep going with their review about the specific client situation when they suddenly notice that the subway just stopped in the middle of the tunnel. There’s no information available, so they just wait for a bit. 262 | After 10 Minutes standing, a guy in the front notices that there seems to be water on the railway, slowly rising. 263 | 264 | Some neighbours get hectic, everybody tries to check the situation, but they only observe it rising. After 1/2 hour in the tunnel, a small child starts crying and the first passenger passes out due to panic and panic breaks out! Somebody asks for water and for a professional, but nobody seems to be available. Most people are trying to check-in with their friends and family, but due to connection issues, it’s hard to keep in contact properly. 265 | 266 | What are the key challenges and questions they’re facing? 267 | 268 | All of the team members have the App Ten-four installed but barely use it. How could the App help Leonie and Ryan get out of the situation safely? Where are the others? 269 | 270 | [You can view the first prototype here](https://xd.adobe.com/view/b3423307-643c-4997-7401-fa3318dd817c-c573/) 271 | 272 | [You can view the second prototype here](https://xd.adobe.com/view/34cb0318-614d-4db5-412a-f5561262c8dd-42fa/) 273 | 274 | [You can view the third prototype here](https://xd.adobe.com/view/c92fa610-0633-4b91-4fe8-66dd2b81e68d-bf1e/) 275 | 276 | Disclaimer 277 | All the information and scenarios included in these slides have been complied and inspired from research and resources online. 278 | 279 | We can not vouch for the accuracy and factual information of the sources. They offer us, as non-native Seattle folk, a guide of how the infrastructure of Seattle operates in heavy rain, storm and mudslide events. 280 | 281 | We ask that the attendees offer up additional information and facts around these scenarios to inform their work. 282 | 283 | 284 | # Conference talks 285 | 286 | ### Interaction 2020 287 | 288 | The Open Design team has been invited to [Interaction 20 in Milan](https://interaction20.ixda.org/) February 2020 to speak about the Open Design project and the learnings from our first phase from 2018 to 2019. 289 | 290 | On Wednesday the 5th of February 2020 the team will take to the stage to take the audience through that journey by presenting you the results of the first year into the Open Design project, and to invite you to join our mission to unlock Open Source Design for all of us – to add true scale to advancing the human condition. 291 | 292 | You can find tickets to the conference on the [Interaction 20 website](https://interaction20.ixda.org/tickets). 293 | 294 | 295 | ### Open Up Global Summit 2019 296 | 297 | On the first day of Open Up global summit Eriol Fox of Ushahidi delivered a talk ['Open Source Design with OSS Humanitarian Tech Tools'](https://www.youtube.com/watch?v=4-jzxd9CjYQ&list=PLwz4EueITgvmJzrNWbGkAMeDVLlOWQuch&index=11&t=248s) to bring to the OSS and open audience in Taipei the importance of understanding the challenges embedding designers and design in OSS projects. This was done by highlighting the work done on Open Design to that point. 298 | 299 | 300 | ### All things Open 2019 301 | 302 | The Open Design team is attending [All Things Open 2019](https://allthingsopen.org/) in Raleigh, NC on October 13-15, 2019 to speak on several humanitarian and open source software topics. 303 | 304 | All Things Open is a polyglot technology conference focusing on the tools, processes and people making open source possible. Target audience includes designers, developers, decision makers, entrepreneurs and technologists of all types and skill levels. Stay current by signing up below. 305 | 306 | You can find more indepth information about All Things Open on their [event summary document](https://allthingsopen.org/wp-content/uploads/2019/01/ATO2019eventsummary.pdf). 307 | 308 | We’ll be speaking about [designing for crisis](https://allthingsopen.org/talk/designing-for-crisis/), a panel discussion on [diversity best practice](https://allthingsopen.org/talk/diversity-and-inclusion-best-practices-a-panel-discussion/) and of course, a short talk about [Open Design](https://allthingsopen.org/talk/opensource-com-lightning-talks/). 309 | 310 | Attending and speaking at events like All Things Open are unique chances where all functions that make the technology industry work come together not just in a commercial sense but in advocacy of Open Source Software. 311 | 312 | Through our current research, we know that helping designers, corporates and for-profit companies that hire designers on staff understand what the role of OSS and humanitarian tech is, but helping those that build and maintain OSS understand the role and value of design is key to a collaborative, inclusive future for design and open source. 313 | 314 | Please come back after the event for a summary of what was discussed and discovered at All Things Open 2019 regarding Open Design! 315 | 316 | ### FOSS4G 2019 317 | 318 | The Open Design team attended [FOSS4G](https://2019.foss4g.org/) held in Bucharest, Romania in August of 2019. FOSS4G stands for Free and Open Source Software for Geospatial. It is the flagship event of OSGeo. 319 | 320 | FOSS4G 2019 was dedicated to enable an asymptotic connection between software and data. Open Design offered a talk that focused on how the attending individuals working at OSS organisations could begin to enable contributions from designers. 321 | 322 | We delivered a talk titled ‘Open Source Design with Humanitarian tools’ on Friday the 31st August at 3:00 pm. 323 | 324 | Drawing on our interviews and research over the last 3 months we offered insights into the problem space where designers are having difficulty engaging with OSS, reiterated the reasons why and where design can add value to OSS and offered practical tips on getting started with structuring an OSS repo fro design contributions outside of the Open Design event framework. 325 | 326 | You can find the [presentation slides from the talk here](https://github.com/ushahidi/opendesign/issues/115) on our open source repo and the [audio recording of the talk (in English) here](https://player.fm/series/chaos-computer-club-recent-events-feed/open-source-design-with-humanitarian-tools-foss4g2019). 327 | 328 | Some of the key idea raised from the audience was around the need for spaces and tracks for designers within FOSS/OSS conferences. Explicitly making is known that designers are needed and valued within the OSS space is key to the wider acceptance of OSS both ways between Designers and Developers/OSS manitainers. 329 | 330 | More issues raised are around good first issues for designers on OSS repos and asking for specific design needs and how to define those. More info about these [can be found in the slides](https://github.com/ushahidi/opendesign/issues/115). 331 | 332 | --------------------------------------------------------------------------------