A presentation at ODI: Lunchtime Lectures in January 2020 in London, UK by Eriol Fox
Welcome to this talk Using open source for building humanitarian tools: The challenges from design.
We’ll be talking through Open Design, a collaboration between Ushahidi, Adobe and Designit from 2018 to 2019.
My name is Eriol Fox. I use They/Them/Their’s pronouns and was lead designer at Ushahidi.
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 work for 7 years and 2 years in the FOSS (Free and Open Source Space)
Ushahidi was founded in 2007/8 in the aftermath of election turmoil in Kenya.
Ushahidi’s mission and subject matter expertise is in building communication technology to empower people to raise their voices while delivering tools to help organisations better listen and respond with a dedication to providing FOSS (Free and open-source software) to those organisations, communities and individuals trying to make a difference where they are when they cannot afford to use commercial software to raise voices.
Ushahidi platform is most commonly used for advocacy, transparency, corruption and accountability monitoring, disaster response, election monitoring, human rights abuse reporting, measurement and evaluation, and environmental monitoring, and other subject areas.
Open Source Software can mean a few different kinds of things to those who are new to it but essentially its software, a ‘tool’ or project that is under a certain kind of open licensing like Creative Commons or MIT license.
It typically indicates something that you can use for free and also adapt and change in ways that are useful to you and/or your organisation. A tricky thing is that there may be technical barriers to usage like understanding how to code a certain kind of language or knowing how to ‘host’ something that was built in code and typically at the very least they require you to be registered with a GitHub or Gitlab account. These are websites where these softwares and projects ‘live’ where the code and information exists.
There are great places to get started with understanding OSS in more depth.
opensource.com opensource.org redhat.com/en/topics/open-source/what-is-open-source
One other typical characteristic of OSS is that it’s a collaborative community effort to build and improve the tech. This is often the case for a number of reasons and it’s a pretty well established part of ‘software (and sometimes hardware) development’ life. Contributing to OSS is often how most developer learn, share and mentor each other in new coding languages and skills and how they ‘give back’ to their community in a way.
So I must stress that while there are some people who are employed and paid to work on OSS many people do it outside of their commercial for-profit jobs.
So as a person who doesn’t primarily code, involved in Open Source I started to wonder ‘Where are the other people like me?’
Here in lies one of the first problems with OSS and Humanitarian use cases.
I would even go as far as to say that OSS has a technical bias in that technical solutions to complex problems are more easily taken in when the problem may have many complicated factors that aren’t just technical and that as more humanitarian related OSS tools and projects are created that they have a responsibility to be actively including other kinds of functions in the building of OSS.
In 2018 and & 2019 we piloted two design jams/hackathons where we tested whether bringing together designers around Ushahidi’s crisis communication tool TenFour to look at challenges local to Berlin and Seattle which were floods and landslides.
We put out a public event once in Berlin as a stand alone organised event and in Seattle at the IxDA conference: one of many design events for interaction designers from around the world.
We found the other people like me here, and also many individuals across many other functions in digital technology wanting opportunities and structures like OSS is for developers too.
https://www.youtube.com/watch?v=iX1HZOtN2Js
We discovered that there are a huge amount of designers working in corporations and for-profits wanting to work on a project in their ‘spare time’.
After these events we started Open Design to try to begin to investigate and solve the question of specifically, ‘Why aren’t there more designers in Open Source?’
So we started the Open design project which was a collaboration between Ushahidi, Adobe and Global design agency Designit to start to understand why designers and, by extension other digital functions like product management, data analysts etc. aren’t participating as actively in OSS as those who code are.
A lot of what we learned about designers trying to move into and thrive in OSS spaces apply to other functions that are characterised by ‘not predominantly coding based’
Open design is a project that was born from these three organisations wanting to make a difference in the OSS space with the design community through investigation, tools, methodology and frameworks.
The first phase of Open Design was largely this as well as the process of us analysing and improving on the format in the open.
When speaking with people that work on OSS projects and ‘maintain’ them. They often hear ‘design’ and immediately think either:
This leaves out a huge part of why design is becoming one of the most needed functions in software recently. Design can offer so much to digital (and non-digital) products and projects than the visual design.
But, just like development and software has it’s own jargon and ‘club’ mentality so the hidden jargon and world of design has been hard for others to break into. Leaving a limited and short sighted view of what design can offer an OSS project.
This view of design is not to be scoffed and mocked at. It’s to understand and work towards how we can as a design community open up are practices and the benefits of our craft of design to those that are just beginning to learn how it can help OSS.
You can apply this level of understanding of design to the level of understanding about any other aspect of a humanitarian project. Programs, Research, M&E. When we don’t make spaces for people with these expertises to contribute to OSS we limit the capacity for Humanitarian OSS to succeed in a community-led building way.
But a problem in OSS is that typically the pieces of work, called ‘issues’ are very specific and very granular tasks. An example might be ‘Design a form capture for new volunteers that includes Name, Email and Address’ This ‘issue’ is largely dictating what is needed and leaves little room for exploration of what is the core need.
Why is this form needed? Why those data points? 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.
As a predominantly coders space OSS issues sometimes lack a flexibility that could offer a different kind of solution to the proposed problem. There’s also the risk that you won’t engage the designers wide skill set, user insight and contextual design expertise as well as lacking in enthusiasm.
That’s if there are issues for design (or other functions!) at all in the project!
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.
Education not teaching designers what it is and how design can be involved.
Agency/Inhouse/organisation not promoting it as a viable source of development for design skills.
When speaking to designers and other roles about what OSS can be they’re often surprised by the diversity of projects. Especially those that are on the humanitarian side seeing these as potentially more accessible than the ones that are about tech for people who build tech.
Github sends a message in the way that it’s set up that suggests it’s a place only for those who can code in some way.
Historically, that may be the case but more and more designers or coders are becoming hybrids or interested in the process of how tech is built.
But while people who code might learn how to use Github, terminal and how to set up their own repos to look at OSS project designers aren’t often equipped with the knowledge on how to do this or even the ways in which to find comprehensive guides in order to set up an instance. If a designer can’t see or experience the OSS through a ‘user facing’ interface or if there are parts of the OSS that are inaccessible unless you can set up an instance then that’s a part the designer will not have access to in order to contribute.
Currently the hiring design industry doesn’t see much in the way of OSS design contribution. Preferring a ‘personal/passion projects’ approach and un-paid internships. This is a problem in many industries including development/coding (especially when you’re junior)
Often the perception of Design is that because it’s visual that it’s ‘fun and not a job or work’
Designers are becoming more finely attuned to this and if they don’t know about the ethos of OSS, they can mis-understand the request for contributions as a ‘Free work’ request.
There’s a process in coding and software development called ‘version control’ which is where multiple people can work from a single source at a time by ‘branching’ their own contained version of the main project to work on and then merge that branch into the main source when they’ve finished.
However, if another person in their own ‘branch’ has worked on the same part but done something slight different a lot of ways of coding will flag and show notifications for ‘conflicts’ and ask the people involved to take a look at the conflicts and reconcile them. This is how software developers stop overwriting each other work while working on code on their own machines and it’s also part of the way they track and maintain ‘versions’ of the project.
In design theres 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.
Building connections & Partnerships with organisations already doing parts of the design process openly, or in open source technology well already.
(we’re not looking to re-invent the wheel)
Organisations listed on the slide include:
The Hague Hacks Open Source Design Open Ideo Global Virtual Design Sprints Adobe Designit Design for Bharat
and many more organisations and individual advocates we’re discovering.
github.com/ushahidi/opendesign
If designers want to get involved in OSS projects then we need more OSS projects involved with us!
Bengaluru, Taipei, Nairobi and London
In Bengaluru we focussed on how designers working on TenFour (Ushahidi’s crisis communication tool) could help people affected by floods.
In Taipei we focussed on how designers working on TenFour (Ushahidi’s crisis communication tool) could help farmers affected by Typhoons.
In Nairobi we intend to focus on how designers working on TenFour (Ushahidi’s crisis communication tool) could help people in terrorist situations.
In London we intend to focus on how designers working on TenFour (Ushahidi’s crisis communication tool) could help people in tower fires and urban settings.
These design activities help both the designers better understand what the OSS projects are really asking for help with by pulling apart a real issue in the repo and working on best practice UX research and design thinking activities in collaborative groups.
The OSS projects get a real idea of how valuable design is beyond ‘just buttons’ or ‘just UI’ or ‘just logos’
Increase & sustain contribution. Support community. Build understanding and education between design and OSS.
github.com/ushahidi/opendesign @opendesignis @erioldoesdesign
