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

Welcome to this talk delving into open-source design contributions focussing on our workshops project called ‘Open Design’.

Hi, I’m Eriol.

They/Them pronouns. 10 years in digital product design & UX. 7 years in humanitarian sector 2 years in (FL)OSS. PhD student researching Humanitarian OSS + Design Designer at Open Food Network.

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

When I started as a designer at an OSS organisation i observed how developers and coders participated in the growth of the OSS through comments. Because the software was open, I saw how this played out from a distance and, as a designer I wondered ‘Why aren’t there many design related contributions to OSS?’ I spoke with the one other design colleague at that same organisation to see if there was anything we could do, as staff to investigate this.

Open Design

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?’

This was a collaboration between Ushahidi a humanitarian data collection open source software organisation based in Kenya where I was working on design, 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.

Berlin 2018 & Seattle 2019

In 2018 and & 2019 we piloted two design jams or hackathons in Berlin and then Seattle, where we tested bringing together designers around Ushahidi’s crisis communication tool TenFour. We ran these in an open and explorative way, to see if current established formats of hackathons/jams worked for designers working on specific OSS software.

https://www.youtube.com/watch?v=iX1HZOtN2Js

Designers want to work on projects ‘for good’

We discovered that many designers working in corporations and for-profits want to work on a project in their ‘spare time’ that has a ‘for good’ purpose.

‘For good’ is often obvious when looking at OSS that tackles specific humanitarian topics but I try to help designers understand is that regardless of the nature of the OSS, all OSS does ‘some’ good by the nature of being OSS, open and part of the open web whether it’s a ‘dev tool’ or a software for crisis communication.

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

So we started the first phase of Open Design, which was largely based on the statement “Designers collaborating and contributing to ‘Humanitarian’ OSS and tech for good at challenge gatherings.”

However, we also wanted the process of us analysing and improving on the format to be open source and done ‘in the open.’

But there are a lot of challenges.

But there are a lot of challenges with Design and open source contribution

Most designers don’t have a clue about what OSS is or can be.

When speaking to designers about what OSS is or can be they’re often surprised by the diversity of projects from subject matter, build, tech stack to output…OSS is hugely varied.

However, OSS that has obvious humanitarian purpose are seen as more accessible than the OSS that are dev tools or tech related.

This connects to my previous statement about trying to help designers understand why OSS is inherently ‘for good’ to extend their perceptions.

OSS isn’t part of design education.

Formal and informal design education does not typically include OSS as a topic and is rarely mentioned through your learning and growth as a designer. Even when you may be using open source tools for FE development or designing!

This is changing and some institutions are introducing OSS specific modules.

Workplaces rarely promote OSS as a viable source of development for design skills as is the case with developers/coders more so.

This also has a knock-on affect in the hiring process where design contributions are mis-understood from an organisation pov as a metric to include when assessing candidates and here the cycle of design in OSS is undervalued institutionally and also seen as not helping you progress in your design career.

Even if designers know about OSS, Github and Gitlab can be a barrier.

Github and Gitlab send a message structurally, functionally and through the interface as a place only for those who can code.

When i speak with designers about contributing to ‘projects for good’ and then go on to speak about accessing them through Github and GitLab they often get a look of horror and assume this requires proficiency in terminal commands, coding and the onboarding curve becomes steep through the way that Github and Gitlab have been and are seen culturally for many years.

It takes a long time for a designer with no prior interest in ‘development’ to embark in discovering projects in these places but new features and improvements like design management in GitLab go a long way in helping bring design cohorts into OSS contribution.

Gitlab’s ‘design management’ feature helps to improve this and UXBOX.

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 either:

  1. Logos
  2. Graphics and icons
  3. UI

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.

OSS project issues can be restrictive…

Restrictive a technical/coding focussed issues in OSS can be seen as restrictive to designers looking to solve problems with not just a technology approach. Even for issues that are ‘small’ and ‘tech specific’ there could be space to include design perspective on solving a wider problem.

As a predominantly ‘developer’ space OSS issues sometimes lack a flexibility that could offer a different kind of solution to the proposed problem.

Designers in particular need the context surrounding a task or problem to effectively design. Not all designers operate this way but most think about the wider impact of what they design.

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.

…but open workshops often lose focus and relevancy.

But 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 or implementable.

This is sometimes called ‘Design fiction’.

Lack of version control in software and process for designers.

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 unless you have a conversation. In OSS this can become even more difficult across timezones, countries and softwares.

This is also often why designers tend to work on separate parts of a project to avoid conflicting or duplicate design work.

However, though our tools are improving and including design version control process versioning for designers means digging into why designers can be ‘protective’ of design. Historically we haven’t needed to share and open our works in progress or thinking and OSS contribution challenges that for designers.

Reworking the OSS and design workshops.

So after learning these challenges we re-worked the open design workshop format.

Design activities.

Our design activities were: Empathy mapping, Defining the problem, Ideation, Story boarding and sketching and prototyping.

We did these during the open design 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.

The work created in the workshops was also contributed to the issues/challenges in our repos.

We encourage including these in your OSS as issues and including in workshops.

Reworked workshops

The workshops we delivered were in these locations due to the crisis/natural disaster topic of the OSS, TenFour, we worked with the designers on

Designers and people impacted by the Kerala floods in Southwest India.

Designers and volunteers working to recover from typhoon crisis alongside farmers in rural Taiwanese farmers.

From these we learned several key editions to making design OSS contribution workshops successful.

Invite into the process a ‘witness’.

It was essential to include people that had deep and inherent knowledge of the purpose of the OSS tool in the workshops. We referred to these folks as ‘Witnesses’ and they were part participant and part facilitator.

The Designers in attendance looked to them to validate the assumptions and ideas they had around the OSS issues.

In India we were joined by Akhila M from the centre for Migration and Inclusive Development.

In Taiwan we were joined by Mei Mei Chen and Hung Wen Lu who founded ‘go honour’ to help typhoon victims.

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

Translate issues to design challenges.

Taking existing OSS issues and transforming them into design challenges that use language that is ‘design friendly and encouraging’ was key to helping the designers understand the problems they are helping by contributing to.

The process of changing the issue into a challenge was done prior to the workshop by people with a knowledge of the OSS tool and some design experience too.

https://github.com/Erioldoesdesign/opendesign/blob/master/translating-issues-to-design-challenges.md

Prototypes.

One output of the workshops was prototypes that are clickable visuals of a design idea for an issue. This is important from a perspective of giving designers the ‘concrete’ feeling of contribution that feels like an achievement for designers and is a useful ‘tangible’ item for OSS maintainers/developers to experience.

These are the core aims of Open Design...

These are the core aims of Open Design in supporting and encouraging design and loss crossover

To help increase and sustain design contributions to OSS tools.

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.

We want to build relationships with more OSS projects.

If designers want to get involved in OSS projects then we need more OSS projects involved with us!

Open methodology, frameworks and processes to use and remix

Here is where you can find the Open Design project OSS to fork and use. There’s also a GitLab version: gitlab.com/Erioldoesdesign/opendesignis/ https://github.com/Erioldoesdesign/opendesign/

This is the future of design.

Designers and developers collaborating together, openly across borders and organisations. This is the future of design.

opensourcedesign.net

A community of supportive designers in open source opensourcedesign.net

Thank you!

All the information and scenarios included in these slides have been complied and inspired from research from Open Design: Phase 1 funded by Adobe fund for design. Thanks to Adobe fund for design, Designit and Ushahidi for funding, supporting and hosting the initial phase of Open Design. Thanks to Open Source Design, Simply Secure and Newcastle University for supporting the next phase of Open Design. Open Design is still seeking funding for the next phase in supporting more OSS projects to work with design as an open source contribution. Contact opendesignis@gmail.com for more details.