Eriol Fox – Design contributions to OSS: Learnings from the Open Design workshops project

Hello, everyone, welcome to the Everyone can contribute track for 2020, GitLab Commit event. My name is Annie and I am a community advocate here at GitLab community relations team. It's an honor to introduce our speaker Eriol Fox.

Eriol Has 10 years in digital design and user experience and also has been involved in community work for seven years and two years in free and open source space. S. Learnings from the Open Source Project.

We will dive into open design to try to investigate and solve the question of why aren't there more designers in open source? Hello and welcome to this talk, delving into open source design contributions, focusing on our workshops project called Open Design. So my name is Eric Fox, my pronouns, are they them theirs, and I worked as a lead designer at Ushahidi and I worked on a project called the Open Design Project, which was looking at open source design contributions.

I've been in the design industry now for around about ten years in different places, the humanitarian sector for around about seven, both voluntary and working. And I've actually only really been in the open source space for the last two or so years. So I'm quite new to open source, really.

So I'm also doing a PhD starting in January, 2021. And I'll be looking at the research that looks into the humanitarian open source projects like the ones I'll be talking about today in this talk and how designers interact with those as well. So doing lots of research around this subject.

And I now work as the lead designer at the Open Food Network, which is an open source tool for producers and farmers and people that make food to sell their produce through an open source ecommerce tool. So when I started my first job in an open source technology organization, like I said earlier, Ushahidi, I was working on all the different kinds of things that I was used to as a designer, lots of technology products getting used to reading issues in our repositories and interacting with our other people that I work with in those same repositories and in those issues. But as I grew to know more about what the open source ecosystem and community was, I was seeing something happen in the issues that the developers were working on, where they would talk to members of the community.

And this was not my first time that I heard about open source software. I'd heard about a little bit before in some other roles when other developers that I worked with started talking about how they engage with open source. And I was curious and ask them.

But really, this is my first time working on a technology product where I came face to face with community members and people working voluntarily on the same things that I was working on as a paid member of staff. And one of the big questions I had was that we had all of our design issues, as well as our development issues and technology issues in the open source repo. But I had this question, which was, why aren't there many design contributions to our open source software at the time?

So I was getting quite envious of the developers having this connection to the community and having community members engaging with what they were working on. And I just didn't see it as prevalent within the design side of our tool. And I had conversations with the other designer that I was working with at the time around, whether he had also seen this happen in other organizations that he'd worked in.

And he had noticed as well. There's just not as many contributions to open source software in the design side of things as there is in the coding and development side of things. So as designers typically are, we got quite curious about why this is and whether we could change this and started in to investigate this question.

And one of the things that we decided to create as a prototype, as a test was a project called Open Design to really delve into this question about why designers aren't necessarily contributing as much as developers in open source. So we had a few different conversations with organizations like the Mozilla Open Design Organization to see what they had done previously and started to talk to different people, different open source organizations about how they did any open source design work and still really found no clear, large, sustained projects that were dealing with open source design contributions at the time. So as we were delving into this question through different projects, different engagements through Mozilla and a few other organizations that we worked with through our work at Ushahidi, we came to know two different organizations, one of which was a global design agency called Designit, and the other was Adobe.

And they were also curious about this question. So they initially engaged with us because they were interested in humanitarian work. But we came to a deeper conversation about how to engage designers both in humanitarian work but also in the open source contributions side of things.

So together, these three organizations, Adobe, Designit and Ushahidi. Piloted a couple of different workshops in Berlin in 2018 and in Seattle in 2019 for the IXDA, the Interaction Design Conference, we did these two test events trying to basically see that if you got designers together in a space around a particular open source tool or a particular open source product, which you have any tangible or tangible design contributions to that tool. And what kinds of challenges do those designers have when they're working together in groups on an open source tool or product?

And we basically just really wanted to learn what we could do to encourage and explore this question of open source design contributions in more depth. So after these two events, which you can look at a promotional video that Adobe created online, which I can share with the GitLab team so that you can take a look at that, we really learn quite a few key things about how designers engage with humanitarian challenges and also open source software. But the key thing that we took away from these two pilot events that that we ran was the designers, regardless of where they're coming from, whether they're coming from a commercial and corporate background and never done humanitarian or nonprofit work before or whether they had some kind of humanitarian experience or some kind of open source experience before they still really wanted to work on projects that were for bid on projects that had a purpose in both their spare time and ideally with some time that they have work as well.

Forget is often really, really obvious when you're looking at a particular humanitarian topic and the things that Ushahidi had created were really clear to understand the humanitarian purpose, the tool that we worked on and talked to designers about in these workshops was a crisis response and crisis communication tool. And that was really easy for the designers to understand. The humanitarian purpose of and then opensource was kind of something that we taught alongside the humanitarian purpose.

But one of the tricky things that we had to tackle was when designers really told us about wanting to work on forgood projects. Was that really from our perspective, all open source software does some good by the nature of it being open source software. It's foundations of the open web.

They enable us to make other humanitarian tools. A lot of these open source software development tools are the things that enable people to create things for good. So we then started to tackle this problem about how to better explain the purpose of open source software in this forget frame.

We then regrouped as three different organizations wanting to still continue to tackle this problem of designers contributing to open source software. And we came around this one statement, which was we wanted to continue to work on open design projects and the open design workshops and continue to enable designers to collaborate and contribute to humanitarian open source software. And tech for good at different challenge gatherings.

And we also wanted to investigate and research and analyze what we were doing alongside running the events. So we also wanted to make sure that we were doing this in the open as well. So making sure the research, the planning and all of the different aspects of investigating this problem was also in open source and sharable way so that we could use it to also teach the designers how to work openly, work more openly.

But as we started to investigate this in a formalized way, after talking to Adobe about certain funding to support the project and support the open source tools that we wanted to work on with the designers, we started to discover multiple different challenges with the problem around designers within the open source contribution space. This is just a sample of some of the challenges that we discovered in the next phase of our research around open design. There's actually really not enough time ever to talk about all the different nuances of the challenges around open source design contributions.

But let's take a look at just some of them. So the first one is that when speaking to designers about what open source software is or can be there, often really surprised by the diversity of projects from both subject matter point of view to the belt of a certain open source software and the tech stock to what the output actually is for the open source software. And the idea of open source software being hugely varied was really, really confusing for a lot of designers, because, as the statement says, they really don't have much of a clue about what open source software is or can be.

And we found within the first steps of our research, the obvious humanitarian purposes are more accessible and that things like dev tools and things that are tech related are the things that designers might assume they think of when they think of open source software. But it's harder to connect that that for good purpose and it's harder to understand where they fit into those other tools. So the idea about designers not really having much of a clue about open source software and not really knowing where to start is a huge challenge for for the project going forward.

The next challenge. Is the open source software as a whole really isn't included explicitly within designers education, both formal and informal. So this is when you maybe go to school for design, but also maybe when you're learning design, like in the evenings in your own time, it's not really explicitly described within the different kinds of things that we look to, to grow our design skills.

And this is really interesting when you think that a lot of designers often use open source tools within some of the things that they learn as designers, whether it's front end development or whether they're actually maybe using an open source design software tool. There are some institutions now introducing open source software specific modules for designers, but it's still quite rare. And a connected issue to the fact that open source software isn't really explicitly educated within design design spaces is that even if it was and it became a norm now for students and designers coming up in the industry, if we aren't doing the education piece from another aspect, like in workplaces where people have been maybe in the design industry for many, many years, when they're looking to hire new designers, new graduates, if they're not as educated on open source software from a design perspective as well, they're going to find it really confusing, really difficult to look at these new portfolios from designers and see lots of design contributions to open source.

And if they don't value that as interviewers and as workplace is looking to hire designers because they haven't had the opportunity to learn about it, then the designers using it and learning about it as they grow in their skills. The students of the early career designers, you know, it's just it's just going to be this kind of this problem that comes from two different angles to different aspects where the younger the early career people are not valued for taking on this new way of doing opensource design contributions and building their portfolio pieces from it. If they're not getting recognized when they want to be hired for that, for that engagement, for that those contributions.

So it's a really tricky challenge in the education piece. The next challenge is that if designers know about open source software and some of them do, some of them maybe have come from a coding background or maybe they've like me, heard developers talking about it in their roles and been curious and ask questions. They really, really struggle when it comes to actually engaging and find engaging with and finding those projects.

And I have to say that one of the biggest barriers, one of the biggest challenges is using interfaces like GitHub and GitLab to really explore and learn about these projects. They're seen as places really for people that can code and people that use terms like pull a request and merges and know how to use the terminal. So when I speak with designers about contributing to open source software and contributing to projects, forget it and then go on to speak about accessing them through these places like GitHub and GitLab, they really do get this look of horror and assume that it requires this proficiency in coding terminology and coding language.

And really, this is a challenge about changing how these spaces, these places where we access open source software are viewed who are viewed for that very explicitly includes many other functions, as well as coding functions and developer functions. It really does take some time to help a designer to onboard onto these spaces. And being patient and helping with that really goes a long way, as well as new features like the design management feature and GitLab and lots of work being put into these interfaces and these places to be more welcoming for these other functions like design.

So the next problem, the next challenge is the when you talk about design to open source software projects and maintainers and contributors that look after the these open source software, they often hear when they hear the term design, they'll hear something like logos or graphics and icons. And maybe if you're lucky, they'll start talking about UI or maybe even design systems. And this is really this is really tricky because while these things are really valuable contributions from designers and they're really needed and they're really valued things from from an open source, software maintainer and contributor and project point of view.

They really leave out a huge part of the design contributions that could be offered and also leaving out really key aspects of product development, such as user research or user experience or even things like service design and interaction design, especially when you're talking about digital products where people interact with and use an interface. One of the tricky things about this problem specifically is to do with terminology and jargon, so just like how development and software has its own jargon, design has its own jargon as well. And maybe some of the terms that I just described of design and service design and maybe UX or user research, maybe these are the first times that you're hearing about some of these design terms.

And that's really, I think about how we as different functions across a product software cycle, regardless of whether it's commercial, proprietary or open source, how we help each other understand the jargon that we use within our roles and how we include people in what we mean when we talk about what we do and what we can contribute. The next challenge is kind of a difficult one to explain, but I'll do my best. It is about how we construct and words are issues that we have in our open source software repositories.

So this this could be a quite a controversial challenge, because what it really means is that we have a lot of issues in open source repositories that I see that are very focused on a technical problem. So they might be describing something like a bug or maybe a new feature for an open source software. And what we assume when we write those a lot of the time is that they're purely a technical coding problem.

So we write them in a way that we need a coding solution, a fix for this book that is to do with writing some code. And the problem here is that when you restrict an issue to just a problem around code, it means that somebody else from a different function couldn't step in, understand what that issue is trying to solve and come at it from a different kind of perspective. So this is especially important in things that could not could be out like broadened from just a coding problems.

If we're talking about new features or even bugs that might have a slightly different solution than just, you know, fixing fixing it in a certain way. It could have a different kind of problem to solve. But this is about taking how we write issues and how we think that we should be writing issues just for one audience that maybe knows how to code in X language and needs to fix this and how we can possibly take it wider and explain and write issues in a way that could invite other kinds of contributions to that issue.

So it's about not being restricted by what you think this issue is trying to solve and opening up more on the flipside of that challenge is a similar challenge, which is about how designers engage with certain ways of working on a problem. So as well as things being restrictive, being being tricky for designers to engage with, when you've got something that's really open to open, you might say what can happen. And we saw this in our workshops, our early workshops is that designers can really lose focus and lose relevancy and they actually then create things, design solutions, which don't take into account the restrictions of your your technology.

And this can get really close to something we call design fiction. So they might create something which is nowhere near implementable because the the issue or the epic or what you've asked the designers to engage with is so broad and so open that they kind of go really, really wild with the kinds of solutions that they come up with. Another problem is about version control, version control doesn't really exist in our software as designers at the moment or in our language and processes and how we communicate to each other.

If we want to do version control as designers, often we have to have a conversation. We're not quite used to having conversations about what we're working on, whether it conflicts. And until we really have software and tools that help us do this, this is going to be a challenge for designers around learning how to communicate version control in a using our voices and using communication methods.

So version control very much a new concept for designers. So after learning about these challenges and a lot of other ones, we reworked the design open design workshops from the initial ones. We included five key activities in these workshops that we think are accessible ways to start doing design contributions to open source software.

These are empathy, mapping, defining the problems, ideation, storyboarding and prototyping and sketching and prototyping. These are really great things to include in your open source repositories for designers to work on if you're curious about what will get contributed. But they're also great ways for the designers to really explore your software as well and to learn more about your open source software from a design perspective.

We then did two more workshops in two different locations, one in India and one in Taiwan. We focused on one of Ushahidi, open source software, and we focused on the crisis as a problem to solve. And we learned many, many things.

But two key things I'll talk about in my last few moments of this talk. One is about inviting users or experts or what we then called witnesses into the process of how your designers contribute to your open source software, especially in a workshop context. What the designers will do for it with these witnesses is they will use them to validate what they're designing and they will ask them questions about how they use the software that they are designing for.

So these people, these witnesses are absolutely key to the process of including designers in open source software. Is about translating the design of the issues that are maybe written in a technical way to more of a design challenge language. You can see an example by following the link, and it's just about explaining what you need to solve in a more user focused and design friendly way.

The last thing that I want to put across to the folks listening is that designers are very much the same as coders and that they really felt great when they offered a tangible design contribution at the end of the workshops or at the end of their or within their process of contributing. So adding in prototypes, clickable prototypes that are created in the design software of the designers, designers, choice is a great way of encouraging that kind of real, tangible, real clickable contribution by designers to your open source software. And the aims of open design as a project going forward into the next phases are about helping to increase and sustain contributions to open source tools, not just using Ushahidi's tools that we worked on in the initial piloting and in the phase one of these next rounds of workshops, but opening up to other, different, more open source tools to support the community going forward to make sure that they have support networks to ask questions and learn different skills around open source software for them to build understanding between design and open source to keep that dialog going and that understanding of different jargon, different terms.

To bring open design and open source design to an education and a workplace environment to help build those bridges between these different functions within the open source software kind of framing. One of the key things about doing lots of talks at different kinds of places like the GitLab here at the moment is that we want to build new relationships and more relationships with open source software going forward so that we can deliver more workshop and support, support more open source software in their relationships with designers going forward. And if you would like to take a look at the methodology and take a look at the frameworks and all the different resources that we created in the open design phase one and ongoing, as we create more resources and learn more things about open source design, you can find it if you follow the link on the screen at the moment on the sites.

And the last thing is that I would love to see folks engaging in the community forums at the open source design on that website and on the forums that we hosted there, there are lots of designers currently on the forums having conversations about design and opensource, and we would love to have more people having the same conversations and having different conversations with us. So with that, I would like to say thank you very much for listening to the very quick version of the open design workshops and open source design contributions. Thank you very much.