Design is Your Friend: Harnessing the Power of Design (and designers) in Open Source

It feels like an age since we all met up in person. But instead of a conference this year, we’ve put together a report gathering up some of the issues and opportunities that the open source community faces today. It’ll feature knowledge, experience and discussion, some of which grew out of conversations that happened at the 2020 Sustain event held in Brussels, Belgium.

The full report is coming soon. If you want to be among the first to know when it arrives, and keep up with other news from the sustain community, sign up at https://sustainoss.org/

How can we ensure our projects work better, make more sense to our users, and break through the noise?

Better design.

It’s one of the great opportunities we in the open source community. There’s a growing community of designers desperate to learn, develop and to build a portfolio of work that has real impact.

And they’re interested in joining us too. Open source software provides an ideal platform for designers to develop their craft. And they’re motivated by the idea of contributing to the commons, and building and shaping things for the greater good.

So what’s stopping both groups from leaping at that opportunity?

At Sustain 2020, Georgia Bullen led a conversation about the challenges that stop developers and designers from meshing effectively in open source. So what’s standing in our way, and are there any approaches that have worked so far?

So what’s Stopping Us?

The full benefits - and opportunities - of design may not be apparent to some developers.

Design is illustration, design is copywriting, design is experience, design is look and feel.

It’s not uncommon for developers to be unenthused about the idea of dedicating time and attention to design, because they see just a sliver of what design in a software project entails.

When we talk about design together, we need to be clear about broad the scope - and impact - of design is, and how each of those facets of design can transform a project.

Design is often about questioning assumptions and building empathy with users, which can introduce tensions within a project.

Designers often face an uphill struggle when working in open source.

A developer creates a project to ‘scratch their own itch’. All of a sudden, they’re joined by contributor-users who are as invested in the solution as the process of building it.

This pattern continues, and inevitably an idea becomes entrenched: that those with the time and skills to implement ideas as code are the de facto decision makers.

Design is often at odds with other contributors in this situation. As a process, design seeks to understand users and to place their needs at the centre of the decision-making process.

This can set the scene for conflict, but it needn’t be this way. Design can provide insights that can temper or complement views, bringing a diverse set of informed perspectives and frameworks that can accelerate development and empower other contributors.

Open source has a diffuse and illusive userbase

User research is a key aspect of the design process, but open source’s distribution model is nebulous. While platforms might provide some insight into who is using a project, they often don’t consider all of the possible users for a project.

As a result, designing for their needs can be incredibly difficult. Open source projects often speak the language of bugs and errors - the ubiquitous flyby GitHub issue - but they rarely speak about user needs, pains and ambition. Knowing how to harness the user base for user research is tough but a significant part of the designer’s toolbox is dedicated to doing just that.

Open source platforms are developer-centric and asynchronous communication is the norm.

There is also a constant battle: working against platforms that are not built for designers.

Versioning systems are typically made for developers, and the platforms built around them understandably focus on that core group of users. As a result communication is almost always asynchronous and, dare we say, transactional — issues, comments and reviews drive collaboration.

There are advantages to this approach of course, but a tendency to demote or defer synchronous communication considerably hinders and hampers aspects of the design process. Most designers will tell you they learn more from observing and prompting over surveying and interrogating.

Open source projects often aren’t conducive to design contributions

We’ve already established that developers and code are the de-facto deciding factor in the direction of open source projects. As a result when designers are invited into a project their efforts are often tacked on to existing initiatives.

This severely limits both the creativity and energy that designers could bring to a project. No one wants to be asked to hold the crayon or draw the rest of the owl.

This often happens in projects with a core maintainer or group, where power and decision-making is centralised. This can lead to a downward spiral into burnout for those who place themselves in the eye of the storm.

Large projects, often with the support to actively complement their contributor base with designers, also see the same problem, but for different reasons. These projects have etched their roadmap in stone, resisting the urge to be inspected, questioned and judged.

How can we improve things?

As we can see, there is plenty of room for improvement here.

But how?

Well, we’re happy to say that some very smart people are working to improve issues like this all over the world. So - if we keep our eyes and ears open - we’ll no doubt hear about new and exciting ways they’ve dealt with them.

But what approaches have worked in the past for members of our community? Here’s a few we’ve come across, where subtle, powerful changes can give both groups of experts an opportunity to work better together:

Start with the user

Good designers stress the importance of making life easy for the user. And - let’s be honest - it’s something we should all focus on.

Often users of open source software become disillusioned when they don’t see their contributions rewarded, or when they’re shut out of the decision-making process.

Bringing everyone together on an early prototype is a sure-fire way to engage users, and inevitably leads to informed, considered and defensible design.

Utilise local venues or core interest groups

When possible, using local communities in order to bootstrap design decisions works well — if it’s possible to scope project decisions to that community.

In particular, this works well with localisation and internationalisation efforts, where working together with a small group of dedicated users drives development.

Finding passionate people who will invest themselves is the key to making design work sail faster. In general, localisation communities are more invested in their domain than larger ones.

Use appropriate communication channels to reach your audience

Why channel everything into issues and pull requests?

Casual conversations, watching a demo video, playing with a prototype, discussing pain points in threaded comments and dissecting an approach in a ranging diatribe on your blog are all valid contributions to the design process.

Make sure the conversation is properly scoped and focused. But meet users where they are - whether that’s Reddit, HackerNews or Twitter.

Present usability and design as a technical challenge

Sometimes the most effective way of getting buy-in for design is to explain why a core problem is also a technical problem.

If the documentation project is poor, navigate the discussion by talking about different possible implementations that will lead to less confusion for users, resulting in fewer issues for the team to triage and prioritise.

If the docs need to be overhauled, explain how the current system is technically flawed before explaining that it could be used more by new beginners if a new system is adopted.

Reframing the language of design problems for developers can be difficult, but it also makes it easier for others to follow and interpret the design process. Again, meet people where they’re at.

Enforce coherence in design across a project

Large open source projects which have matured beyond the single maintainer stage are rarely a single artifact; they have a website, docs, maybe even marketing materials.

A designer who has the ability to include all of these in their purview will find it easier to normalise a design philosophy, build engagement and respect from the team, and to build a process to support other designers to evolve an approach.

Style-guides help both designers and developers share a common language around design, making it easier to communicate. But there’s another benefit that’s often overlooked: improved issue reporting. Style guides create consistency, and cConsistency breeds intuition and expectation. And when these expectations are not met, users will find it easier to communicate their disdain using the framework provided by good documentation, and guidance and a solid sense of the right way for a project to tackle a problem.

Personas, stakeholder maps, user stories, ‘jobs to be done’.

These are but a few of the frameworks that largely achieve the same goal: building a basis of shared understanding about who your users are, what pains they are experiencing, and how they are easing them today.

Stepping away from generalisation, individual inspiration and insight, and instead jumping two-feet into the shoes of your user is a huge step toward building an appreciation of the thought and craft of design, supporting developers who wish to dabble, and encouraging new designers to join you.

Find your tribe

You are not alone. The design community is late to the party, but it is there.

Organisations like Open Source Design and Simply Secure are taking on the work of creating spaces and publishing guidance for designers working in open source. Seek out designers working on similar projects, solving similar problems or voicing the same concerns. Attend or propose co-design sessions as part of developer events. Oh, and let’s talk about design in open source whenever the opportunity arises…

Talk about design in open source

Finding collaborators can be useful - but it’s equally important to simply normalise the discussion about design as a valid and valued component of open source production, especially in nascent design communities.

Sharing difficulties and blogging about the process of solving them teaches others about pitfalls they can avoid, and helps educate designers who may eventually come to be collaborators. Many designers get contracts by building networks through this sort of self-marketing as well, so it isn’t necessarily a loss leader strategically.

Where do we go from here?

In the last decade we have seen software developers rise from something akin to Internet carpenter to corporate kingmaker. Open Source Software has gifted a generation power by giving participants a means to practice, perfect and publish their work in public.

By integrating the design community better, we have the opportunity not only to share those benefits, but also to take our work to the next level. Better design will enable us to build a new generation of publicly available tools and technologies; tools created with an understanding and empathy for users that will strengthen their reach, their impact, and their potential.

With a little work, we can make it happen, together.