Design contributions to OSS: Learnings from the Open Design workshops project

A presentation at Open Source Community Africa Festival 2020 in February 2020 in Lagos, Nigeria by Eriol Fox

Slide 1

Slide 1

Design contributions to OSS: Learnings from Ushahidi and the Open Design project.

Welcome to the talk about Design contributions to OSS. What we can learn from the Open Design project between Ushahidi, Adobe XD and Designit.

Slide 2

Slide 2

Introduction slide to Eriol

My name is Eriol Fox. I was lead Design at Ushahidi from January 2018 to January 2020, a non-profit, humanitarian organisation that makes open source tools for challenges such as Election monitoring, Democracy, Crisis response and human rights advocacy.

I’ve been working in the digital product design and UX space for the last 10 years, since before UX had a name.

I’ve also been involved in Humanitarian work and community development work for 7 years and 2 years in FOSS.

I’m part of the core team at Open Source Design.net a volunteer run, community of designers dedicated to advocating for design in OSS.

Slide 3

Slide 3

Why aren’t there many design related contributions to OSS?

When I first started working at Ushahidi, I wondered, where are all the design contributions?

We get developer, coding, documentation and translation contributions why not design? why not user testing? why not graphics, visual insight and suggestions?

We talked about this internally and two of us did Mozilla open leaders projects on opening up User research contributions and design contributions.

This laid the groundwork for the open design collaboration with Adobe and Designit.

Slide 4

Slide 4

A video of the pilot workshop on Berlin 2018. See the full video here: http://bit/.ly/Open-design-jam

Two years back, we joined forces to enable design contributions to humanitarian open source software.

In 2018 and 2019 we piloted two design jams in Berlin and at Interaction 19 in Seattle, to bring together designers to focus in on Ushahidi’s crisis communication tool TenFour, to work on crisis scenarios that were applicable to them living in Berlin and Seattle, which were imaginary floods, and landslides.

Slide 5

Slide 5

Designers want to work on projects ‘for good’.

We discovered that there’s a huge amount of designers out there that are working commercially in companies and agencies, that actually want to work on projects that give back to the world.

Unfortunately in OSS there is an absence of contributions that aren’t code and many OSS projects don’t think outside of their typical ‘developer bubble’.

But Open Source Software, especially humanitarian projects, are in dire need of multi-functional product cycle support, including design, in order to make critical, needed software usable in truly difficult situations.

Slide 6

Slide 6

Introduction to Open Design.

After our two pilot events in Berlin and Seattle, Ushahidi, Adobe and Designit began a collaboration under the name ‘Open Design’ to further investigate and solve the question of specifically, ‘Why aren’t there more designers in Open Source?’

We wanted to have a deeper understanding what is keeping designers off of participating as actively to OSS as developers do.

And we wanted to start removing roadblocks, to enable more design contributions to that space.

Slide 7

Slide 7

Designers collaborating and contributing to Humanitarian OSS and tech for good at challenge gatherings.

Our aim with Open Design was first to research, which we did a year of, apply this research to improve what we piloted in Berlin and Seattle and carry out improved workshops.

We worked openly by default, encouraging communities and people to remix, use and build from what we had.

Slide 8

Slide 8

But there are a lot of challenges.

But we discovered many different challenges with Open Design contributions.

Theses are just a few!

Slide 9

Slide 9

OSS isn’t part of design education.

Design education both formal and informal does not typically involve learning about OSS. Even if we are using OSS we might never know! because of this, most designers aren’t aware of what open source is or can be.

Now some design institutions are introducing OSS modules for students.

But we need to connect this with our workplaces. If we’re not including OSS and a valid part of our education then when we move into the world of work involvement with OSS will continue to be seen as a non-viable source of design practice.

Slide 10

Slide 10

Most OSS projects understand design as ‘logos’ and ‘graphics’.

When speaking with people that work on OSS projects and ‘maintain’ them. They often hear ‘design’ and immediately think visual design only.

This leaves out a huge part of why design is becoming one of the most needed functions in software. Design can offer so much to digital (and non-digital) products and projects than the visual design.

This speaks to the historical and cultural segregation of design and development, however this is changing and more OSS projects are becoming aware of usability and the need to be human centred by design.

Slide 11

Slide 11

OSS project issues can be restrictive…

Short, technical, jargon, dev-readable.

Designers in particular need the context surrounding a task or problem to effectively design for it in a sustainable way. Not all designers operate this way but the ones that have a healthy amount of curiosity about the wider impact of what they design.

Why is this needed? For how long? How does it change over time and culture? How should this be stored?

Designers in particular need the context surrounding a task or problem to effectively design for it in a sustainable way. Not all designers operate this way but the ones that have a healthy amount of curiosity about the wider impact of what they design.

That’s if there are issues for design (or other functions!) at all in the project!

Slide 12

Slide 12

…but open workshops often lose focus and relevancy.

On the flip side, when you have a challenge that is is not directly attached to a specific issue or scope of work for the OSS and then designers tend to create designs not grounded in the reality of the current technology function often called ‘Design fiction’.

What we wanted to figure out is how to achieve actionable design contribution to current issues/tickets in the OSS repo while engaging designers in the OSS’s purpose.

Slide 13

Slide 13

Lack of version control in software and process for designers.

In design, there’s no real way to know if another designer working on the same project has changed something in a file that you have also changed. You have to create a whole seperate file, have a conversation and point out the differences and discuss them.

This is also often why designers tend to work on separate parts of a project than the same to avoid conflicting or duplicate design work. We need ways to work with this remotely across timezones and borders if design for OSS is to be successful but also, as designers, understand that someone looking at our ‘master’ design file and changing something to suggest something better isn’t a threat to our design but a way of collaborating and globalizing our design to make it better and more relevant for everyone around the world.

Versioning for designers means digging into why sometimes we are particular and precious about holding our design files tight an not allowing them to be more flexible and participatory.

Slide 14

Slide 14

The Open Design workshops in 2019 that tested our new methodology and framework.

Designing for crisis communication open source TenFour with survivors of the Kerala floods in Southwest India.

Designing for crisis communication open source TenFour with against typhoon crisis alongside farmers in rural Taiwanese farmers.

Slide 15

Slide 15

Design activities.

Our design activities during the workshops were focussed on building team cohesion and entering into the problem space of the OSS. Not about particularly complicated or fancy methods that could isolate and put-off any non-designers or early-career designers.

We did Empathy mapping, Defining the problem, Ideation, Storyboarding and sketching and prototyping.

Slide 16

Slide 16

Location specific builds community.

Because design in open source is relatively new and our processes and communities aren’t structured or socialised in the same way as developer communities we need design workshops for OSS to be location specific in the beginning. This means this location should be where the OSS is used e.g. TenFour for crisis used in Bangalore and Taipei where there have been floods and Typhoons and these workshops should bring together the local and international community at that location the best it possibly can.

This allows designers to try out all the things that are involved in building a team: Meeting new people, discussion, collaboration, sharing and bonding. As well as having a location based, personal connection to the OSS through either first-hand or extended personal experience. This also allows you to bring in witnesses or ‘users’ from these same locations and extend the bond from designers to designers + OSS + users of the OSS.

You can facilitate remote involvement but it’s very important to build a connection between designers working on the OSS challenges.

Slide 17

Slide 17

Invite into the process a ‘witness’.

https://github.com/ushahidi/opendesign/blob/master/witness-brief.md

As we just mentioned, having a ‘user’ or what we call ‘witness’ (it’s more humanising than ‘user) present will allow your designers to fully connect with the purpose of what they’re designing for and the need for the OSS.

We invited (and paid for their time!) witnesses with experience of the Kerala floods in Bangalore and of the Typhoons in Taiwan. These folks were invited to speak for 30-45 minutes on their experiences and then for the designers to ask them questions, clarify the needs, empathise with the witnesses and validate assumptions.

The witnesses also gave feedback on the prototypes the design teams created in response to the OSS design challenges.

Slide 18

Slide 18

Translate issues to design challenges.

We mentioned early that there’s a balance to how we communicate our issues in our repositories. Many are catered towards developers and technical speak and may include the phrase ‘As a user I want to do X Y and Z’ if we’re lucky.

If we want to include designers in how we solve our needs in open source software there’s a way to make these issues more inclusive to designers by writing them as ‘challenges’ you can see an example here: https://github.com/ushahidi/tenfour/issues/112

The main thing is to not offer the solution and not believe you have all the answers. It’s to describe the problem people are having with the OSS when they try to do something and to present the problem to designers so they can develop an understanding and design a solution that isn’t restricted by what a project or individual might think but allows for exploration of the best solution within reasonable technical and logistical constraints.

The worst thing you can do is detail exactly how you think a design should be done and restrict creative problem solving but also, to allow for complete freedom you’ll get a design solution that is not implementable within a sprint/cycle. Be balanced.

Slide 19

Slide 19

Prototypes

The teams at open design workshops are encouraged to produce a ‘prototype’ for the design challenge/issue. So that the OSS team, other designers and the witnesses can see what they’re proposed solution to a problem is and that other designers around the world could potentially build on and collaborate on this design in an ‘open source’ kind of way.

The tool that’s used for this prototype isn’t as important as the act of contributing. The OSS project can request and suggest they’d like design received from a certain tool or in a certain format but ideally, this would be a format that all designers globally could contribute in some way to.

Accessibility of tooling is a whole other topic that’s deeply complex and speaks to privilege and access.

Slide 20

Slide 20

Increase & sustain contribution. Support the community. Build understanding between design and OSS. Bringing Open Design to education and workplaces.

The goals of Open design are:

To help increase and sustain design contributions to OSS tools like Ushahidi.

To support a community of collaborative, peer-led designers who learn skills and new ways of working together.

To build the understanding of OSS in the design community as alternative to ‘speculative’ ‘design for free projects especially for early career designers.

To help OSS projects understand design beyond graphics and UI and into the broad skills design can offer OSS.

To support OSS projects in building and receiving design contributions that are meaningful to their projects.

Slide 21

Slide 21

We want to build relationships with more OSS projects.

If you’re an OSS project interested in Open Design, contact the open design project on slack at: https://join.slack.com/t/open-design-is/shared_invite/enQtODMwMzE0MTgxMDkyLTk0MGViYWI0NWJjNjQ3NDM5MzNjNDcwYjNmYzc3NmFlYTZkODVlMzY3ZDc3NTY5MzI5M2E5NzM2ZWU1YjMxNmE

or twitter here: https://twitter.com/opendesignis

Slide 22

Slide 22

And with designers and developers globally.

If designers want to get involved in OSS projects contact the open design project on slack at: https://join.slack.com/t/open-design-is/shared_invite/enQtODMwMzE0MTgxMDkyLTk0MGViYWI0NWJjNjQ3NDM5MzNjNDcwYjNmYzc3NmFlYTZkODVlMzY3ZDc3NTY5MzI5M2E5NzM2ZWU1YjMxNmE

or twitter here: https://twitter.com/opendesignis

Slide 23

Slide 23

Open methodology, frameworks and processes to use and remix:

Go here and check it out: github.com/ushahidi/opendesign

Slide 24

Slide 24

A community of supportive designers in open source opensourcedesign.net

And join the Open Source Design forum: https://discourse.opensourcedesign.net/

Slide 25

Slide 25

Thank you!

Thank you!

Slide 26

Slide 26

OSC Africa and Sustain Africa are awesome!

OSC Africa and Sustain Africa are awesome!