 Okay, so, thanks for coming to this talk about design contributions to open-source software. The learnings from the open design project, which is a project that I did during my time at Ushahidi. I won't be going into any depth about what Ushahidi does, just essentially it's an open-source, non-profit humanitarian tech company that I was the lead designer of for two years. So, a little bit about me before we launch into some of the project background. My name is Errol. My pronouns are they them. If you're going to do any photos or refer to me, please use my pronouns. I'm a humanitarian designer. I've been in the design and user experience space for about 10 years, previously in corporate and commercial spaces. I have been though in the community development and humanitarian space for around about seven years in a voluntary capacity and two years in the open-source space. So, that's kind of my background going into this project. So, as a person that was fairly new to open-source, really, I came in as a designer with a set of preconceptions about how to approach the subject of design within any tool. Open-source to me was another way of creating a software tool. And one of the things that became really quickly apparent to me as a designer in this space within open-source after I did some of the very quick learning about what open-source is, how the community is built and how it operates in a very different way to potentially the corporate world or the commercial world, is I was asking myself this question when I was going through our repos, looking for contributions or looking at contributions from coders. I was thinking, why aren't there many design-related contributions to our open-source specifically, but then the wider question came up was, I wonder if equally in other open-source projects are there design contributions there. So, I started to have conversations with, at the time we had two designers on staff at Yshihidi, we were having lots of conversations about how this could be possible and what are the barriers for designers to contribute to open-source software. We were designers employed working on open-source software, but we still had this desire and this want to include the design community in somewhat the similar way that the development community is, but perhaps in a way that works best for designers. So, we engaged with an agency, an agency came to us actually at Yshihidi as a humanitarian open-source project and wanted to do some work with us. They were really keen to explore what humanitarian open-source tech was. And with them, we started talking about this problem space of designers in open-source and they were really interested. It kind of sounded to them like sometimes the things that they organised around like called design jams or kind of designer hackathons in a lot of ways. So, they were like, well how about we take some of the time that we were going to support you with and create some events and do a design hackathon around your open-source. And we thought great, let's see what happens, let's see what works. So, we did two different events with this organisation and it's how we met Adobe through these different events. We did one in Berlin and we did one in Seattle. And these are the basis of a lot of the learnings about going into the open design project that Yshihidi then got funding from Adobe to carry out. And the key thing that we learnt from these first events that were unfunded ones that we wanted to explore and wanted to try and find out some answers to was that we essentially found out that designers, by and large, really want to work on projects for good that have a purpose, that contribute back in some way to a community. And it just so happened that because Yshihidi was a humanitarian open source, the connection to for good was slightly easier for most designers to connect up with than your other kinds of open-source projects. So, we found this was a really good entryway into open-source in general. So, we formalised what we called the open design project within Yshihidi and this was, like I said, a collaboration between Adobe as a funding partner, design it as our interested agency design community partnership part. And then Yshihidi as the owner of the open-source tools, the owner of the open-source projects that we were going to pilot these different interventions, these different methodologies, these different things that we were going to discover what we needed to create. So, this project formally started as a funded project around summer last year, 2019. And the first part of the project was largely around discovering a lot of the challenges. And, well, actually, one of the first things that we needed to do was define what we wanted to try and achieve. Like, what did we want to do other than what we'd previously done with the unfunded events, the design jams? And we really wanted to encapsulate what we'd already done but take it a few steps further and kind of put it into this statement. So, we talk about designers collaborating and contributing to humanitarian OSS at Tech for Good and Challenge Gatherings. This is how we presented it to the design community. But like I was saying, there were lots of challenges. And one of the first things that we needed to discover before we could improve on the previous events that we tried was start to understand some of these challenges. Now, each one of these challenges, and there were a lot, are full many, many hours of conversation talks and discussions long. But I'm just going to go through them quickly so that you have an understanding of the things that we investigated. So, one of the first things is that most designers outside of the existing open source community don't really have a clue what open source is or can be. So, if they have heard of open source, they might see it as the typical big players, Linux. They don't even know that there is kind of such a thing like humanitarian or non-profit open source or open source that contributes to good. It was something that was genuinely surprising to a lot of the designers we were engaging with. And most of these designers are ones completely outside of the current community that were coming in and wanting to participate in something for good. That was the draw. The next part, kind of follows on, is the open source software and all the things that are encompassed within that. It's not typically part of design education, although it's slowly becoming part of some institution's design education very recently, which is really encouraging to see. But by and large, my education and many of my peers' education did not include open source as a topic. If we used open source, they might have even never mentioned that they were open source or gone anywhere near digging into the subject in depth. And this follows on to another problem, which is around if you're not told and educated and brought into this community, then how can the business world, the working world, which most designers will tend to go into the corporate commercial world, how can they use open source knowledge, open source principles to help them build their CV as well, if agencies and existing businesses that are outside of an open source world and not technology-focused, if they see on a designer CV, oh, open source, what's that? I mean, I'm not going to consider that as part of my hiring process. It was like a real chicken egg scenario around what designers saw that they could use as valuable information for their further career. So they didn't feel like it was really part of their education. So if designers know open source, then one of the things that can be a huge barrier is the existence of things like GitHub or GitLab and even just the superficial interface and how we use those systems to host and build and communicate our open source projects. Most of the designers that I work with on these projects, as soon as you sort of open up a GitHub issue, there's a sort of apprehension, a kind of sharp intake of breath about how to just get started with interacting and you really often have to take them through the process of commenting on a GitHub issue, understanding what labels are, understanding where they can search and all these kinds of different kind of basic level functions of things like GitHub. But it's really important to understand that that's the place that most designers are coming from when they want to contribute to something for good. So not only doing research into designers, we did a lot of research into existing open source communities and people that maintain open source and speaking to a lot of people that either are currently maintaining open source or looking to or own their projects, when you talk to them about design, they say things like logos and graphics or UI and that really undersells the value of design as a many splendid function that encompasses usability and user experience and service design. Lots of different things are of benefit from the design industry for open source. But it's not to downplay the use of jargon in the design community as well and how isolating that can be from the open source perspective as well. So there's a lot of work to be done on breaking down how we use our functional language within our profession and how inclusive or exclusive that can be. Around inclusivity as well, OSS project issues can be really restrictive in what, even if they know what kind of what they want to ask for as far as a design contribution, they can be incredibly restrictive. I had a lot of designers looking at issues and saying, well, they're just telling me what they want rather than asking me to explore a problem that they want solved using design. And similarly, or similarly, if you take a very open approach to say workshops with an open source project to designers, what you tend to get, and this is what we got in those first unfunded events, was that they lose focus and they lose relevancy to real issues that need to be progressed within open source projects. So, on the one hand, issues can be very restrictive and not inclusive for designers, but then when you say, improve our product, they create things which are not able to be actually implemented. What we tend to call something like vaporware or design fiction within the industry. Fascinating solutions, but not nowhere near immediately implementable. And then there's the lack of version control in various different kinds of software that designers use and also the lack of kind of a process for version control as well and a language around version control and also something about how we approach the idea of collaboration and sharing within the design community. A lot of challenges. So, I want to talk about what we did with the project. So, we investigated, we did all this research, we did a lot of interviews, we have an open repo and with all of the information and all the research hosted on that repo. But I want to talk through the activities, the workshops that we did and what we changed. So, we did two workshops, two subsequent workshops after developing a very attestable, but based off of the research that we created, attestable methodology, attestable workshop framework and a way of constructing specific, a way of constructing issues in a much more design friendly, but also implementable into the OSSY. We did one of the workshops in Bangalore in India, which was as part of the design up festival which is a conference primarily for designers. And we focused there on one of Ishihidi's crisis tools. So, Ishihidi makes a few tools that are to do with crisis response and humanitarian aid and we really focused in on the location that we were hosting this workshop. This is one of the key things that we discovered was really important. So, we focused in on the coralla flooding that happened in 2017 and 2018 and we made sure that the challenges that we were bringing to that location and those designers were ones that were relevant and familiar to them so that they had a connection that that feeling of doing something for good was embedded within their community. We did our second one in Taipei in Taiwan and we focused in on typhoons and how it affected rural farmers and their livelihoods after those typhoons. To talk a little bit about what we brought to the workshops as far as activities that we did we did a few different ones we did something called empathy mapping defining the problems ideation storyboarding and then we went into live prototyping and the idea was at the end of these workshops which we tested two different structures to the workshops was that each challenge or issue would have a tangible contribution of some kind of design at the end of the workshop. So these workshops were about a day long one of them in Bangalore that we tested a full day so from a 9am to a 6pm a full sort of exhausting day of designing and in Taipei what we tested was two halves with a remote sprint in between so we did a four hour workshop to introduce the project to introduce open source and the first exercise which was empathy mapping we did remote sprint activities which were the subsequent activities here and then we finished with another four hour workshop a week later with the sketching and prototyping in person we wanted to see whether there was a difference in these two different structures to get better contributions or more sustainable contributions. So to go into two of the very key things as well other than what I've covered already on what makes a design related workshop around your OSS really important was one of them was inviting into the process a witness so not only making that the issue of the open source relevant to that location that you're taking taking that workshop to so the designers within Taipei or the designers within Bangalore but it was bringing in a witness that had experienced the need of the software so in the case of the crisis communication OSS tool that we were building for we had two witnesses the Bangalore witness was a person that had done extensive research and delivered aid out into the Karala flooding area and she was our key witness to be able to give feedback to the designers and to bring them into the relevancy of what they were designing how close was it to the designers so how close was it to the user's need so she was really there to test whether it was working whether the solutions were working and in Taipei we had one of the farmers that had been devastated by one of the his farms had been devastated by the typhoons and a volunteer organizer that coordinated an effort to go in and relieve those farms of what they needed during the typhoons so it's really key having essentially your users of your open source there with the designers so that they can experience who they're helping the second one is the process of translating issues into design challenges so there's an example here from the repo that we worked on and some of the things that you really need to go into depth on are who are the different users of this potential issue if you have an admin state versus another state what are the problems that you're trying to solve what are the ways in which you've maybe tried to solve it before what's all the information from your team basically as much information in that issue as possible though we did realise that there was a point in which there was too much information for designers and it became restrictive in a different way rather than too little info so we've met a happy medium now with this issue here and to show you what came out of it was a series of different prototypes so each of the workshops had multiple different teams and they self-selected their teams based on their skills that they wanted to bring to that team we tried to evenly disperse different kinds of skills or at least people that were willing to perform different kinds of skills so product management wire framing, sketching lots of the different skills so that the work was evenly shared across the team and at the end they produced a testable prototype something that somebody could click through to go into the field and test with so that they could also show our witnesses how they completed so to wrap up the aims of the open design project going forward are still to increase and sustain contribution from designers to open source to support the community and that means both the design community and the open source community to build the understanding between those two functions to start to break down the jargon, start to break down the bridges that we may have constructed over the years of our operations and bringing open design to education and workplaces to start making sure that OSS is valued within the design community and within our workplaces as well as our educational institutions some of the things that you can help with if you're interested is we want to build more relationships with different OSS projects so we don't want this to just be of benefit to Isiheidi's tools this framework, this methodology all the different things that we've learnt we want it to be usable and relevant for any open source project and you can find the resources here on the open design repo so we've got five minutes and that's it we've got five minutes left for questions or you flash five minutes thank you so I come from the education background one of the things that I think is challenging for people like me who are deep in the software side is I think in the design world there's that difficulty to sharing your work sometimes because of how the industry is and you feel like that's your work that you're losing now what do you think would be a better approach to being more inclusive or inviting designers into the conversation of the language and some of the ways that we talk about specifically around education so the institution that's already has a module around open source is a technical university in Darmstadt with their design students I went to visit and it's really fascinating to see design students getting really having that educational basis so I'm really hopeful that there'll be more institutions building in modules I think that this is partly a question about what we call design ego there is such a thing it's a very complicated topic but there is not really there's only recently the examples within corporate world of actively sharing either functions or being not just critiquing like there's a good history of designers critiquing each other almost critiquing each other's work too much for the sake of critiquing but we're still building up these processes of opening up like how we did stuff like a lot of what design has struggled with over the years is it's a validity as a job function like often design is regarded as like a very enjoyable job because it's creative in a lot of ways when it's a job like many others it's a very complicated topic but I think what you can do is what I've found works is having somebody that speaks a reasonable amount of design language that the designers can connect with that also speaks a reasonable amount of open source language so that with some of the workshops we actually got developers coming along and learning design activities as well which was really cool and fascinating having that balance of somebody that can kind of be a bridge allows them to flexibly bring in the two topics on an even platform cool I don't want to take up more time because it's like we can still squeeze in a real short time oh yeah yeah agile yeah sure so I guess one of the things that might be most interesting oh so the question was around agile methodologies or things that are used in the agile process and maybe bringing some of those into how we're working here or could they be brought in and would they be valuable so as far as my knowledge goes there are agile there are not specific design agile processes but you can have something called a design sprint and one of the people that we worked closely with was the global virtual design sprints and they came out of Austin, Texas and they now do a global virtual like remote across the world design sprint so they are really trying to push the idea of global remote for good design sprints which is super cool check those folks out there are some things that I think we could benefit from retros for one thing it would be great to be able to build into this process the ability for the open source project and the designers to do a retrospective on what was created also building in structure around the sprints so I structured the remote sprint around these activities but there are further sprints that I structured that again if we get further funding or if we carry on the project that's what I would like to test next and actually the next thing that I wanted to test after these activities was a sprint for the designers that was so focused solely around user testing and how to support open source design user testing processes so that's all structured and ready to go just needs the needs either the funding or the support or yeah those kinds of things I think we can take off line Thank you