Design Ops in Open Source

This post is from a talk given as part of the Joint Futures conference and is the transcript presented. You can find the full slides here.

Imagine a space where anyone can comment on everything you create. Where people across the world unite to create something given away for free. Where no matter what your skill you could turn up, contribute and be part of creating a widely used product. That runs async, fuelled by passion.

This is WordPress, an open source project. I want to show what happens in the project, how design works and functions within open source. The challenges, but also some solutions, some ways it’s starting to evolve.

There’s a phrase used a lot around OS of ‘free as in beer’. I personally prefer the phrase I’ve seen used of ‘free as in kitten’. A project is relatively easy to set up, but the maintenance, growth and nurturing… that is where the effort needs to be. You’ve got to grow your kitten, feed it and keep it safe. Design Ops brings that to design, you sow the seed, support and then weed.

Open source isn’t just a checkbox, you can’t declare something OS and it’s ‘so’. An open source project needs process, boundaries and a community needs to have structure otherwise it isn’t open source it’s a free for all and the kitten goes without food and maybe just walks away to fork itself into another project. Open source is made of people, something we often forget when downloading a project. It’s made of their passion, often their spare time.

Open source projects are typically remote by default. People collaborate around the world, from wherever they are. The way communication happens in a project like this is usually async. This could be on a variety of platforms from IRC to Slack, forums to message boards. 

Each format typically has specific types of communication, more suited to them. Mixed in with this is tracking systems and ways to work on issues and projects.


There are a number of often unique or amplified challenges working in the open. I want to spend a little time highlighting a few before showing how a more operational approach to design can ease them. It’s important to note that whilst this talk is focusing on design, the challenges bridge often across roles. Within a project, the roles often blur far more than in a company structure. Like any design problem, by knowing the challenges you can suggest solutions.


Imagine you start contributing to an open source project. You are excited to be part of this amazing project. You maybe get an introduction at a contribution day, or you turn up to a meeting in Slack. Everything seems calm to start off. Then pretty soon after replying to a few things the emails start coming in, first just a few, then as threads of issues get longer they grow with each comment on an issue and ticket. You subscribe to a few key blogs for the project. Then you start getting notifications as you participate. Before you know it when you wake up your notifications are lit up across multiple platforms.

This isn’t unusual, the firehose is real in big projects. Most rapidly are hit in the brain for 1000 points within a very short time. This all assumes you can even find a way into the project through the firehose, that’s often where the first problem starts. 

Raining Stick-holders

Whenever someone says stakeholder my mind skips to seeing them as stickholders, often waving those sticks. It’s just not a great word. In a project depending on the size you can have quite a few of these. Not only might you have project leads, focus leads and team leads. You have the added angle of drive by stickholders. Someone can come into an issue on GitHub for example and derail or kill it with one comment. 

I’ve seen cases where social media is used to rally opinions and almost campaign like approaches.

Jumper Thread issues

Often even starting is a mirage, what seems to be one thing rapidly turns into something else, you pull that jumper thread and suddenly realise it’s unravelling. This could also be entitled good first issues are a trap! So many things in a large, established project are just not as simple as they seem. To someone new to a project this is a horrible experience, you turn up and as a volunteer end up in a spiral, stuck. 

Herding time-warping cats

I use this term lightly and with respect because when everyone is a volunteer and you are trying to coordinate a project timeline, it can truly feel a little like herding cats, not only cats but ones that time warp, in different timezones. You can’t demand to keep to a strict timeline in this case… Volunteers are the fuel that runs open source projects. 

If someone is a volunteer they might have a lot going on and only be contributing on Sundays, once a month. They also might rightly only want to contribute to a certain thing. Not all tasks though are attractive.


By it’s nature a global project needs a different mindset to a local one. When you mix in async and also multiple languages, you get quite a complicated experience.

Familiarity breeds exclusion. I know I’ve fallen into this. As you know someone you have a shorthand for communicating and understanding. My own communication style also defaults to casual, emoji fuelled. Checking this is a quest, but an important one. You have to be careful also of regional references and emojis.

Imagine someone contributing in Australia, their experience is often getting up to decisions having been made and going to bed leaving messages in hope they get included.

Nothing Fits

The reality is most tools, from tracking systems to testing in open source are created by developers for developers. It’s like from the start even the tools are saying you aren’t one of the project, you are other. 

GitHub opens up far more potential, however it still can be used to suppress voices, through thumbs down drive by emojis that you can leave without commenting. The tools that are offered from setting up a testing space, to running a patch easily without one, to even reporting a bug and giving feedback, they are often ill fitting and the last worked on.

In practice

In truth Design Ops as a practice has existed for a quite some time. It is important to not see anything being done here as new. It’s often interpreting existing organisational psychology.  You need to always look outside and learn. Within WordPress the community team is a great source of knowledge and insights. How does designOps work in a project like this though?

Adapt, morph, bend

DesignOps should not be static, be like a reed.

This is one thing I think sometimes is forgotten in this work is like design it needs iteration. You don’t release a design and say that’s never changing, so why would any operational practice in design do that? Just like design, it should respond to feedback, testing and data. It also shouldn’t be applied without feedback, testing and collaboration.  

It’s a journey not a single destination.

Focus on soothing tasks

Often in thinking about how to aid, the impact is focused on. Actually the biggest way to help is by soothing tasks. There’s a lot of hitch points in OS and finding little ways to ease is really the best way forward. Support comes from giving structure, clearing the way for work to be done.

From an operational perspective, because everyone has their own way of working, it’s about adapting, suggesting, sprinkling not dictating.

Contribution is a design problem.

In practice

I loosely break down how Design Ops works in open source as sow, support and weed. I wanted to dig a bit more into how that flow works with some examples. It’s a flow, constantly moving through each phase and repeating. Like crop rotation and companion planting, sometimes running at the same time or staggering.


Activate design across roles

Most projects aren’t overwhelmed with number of designers. It’s a fact that is slowly improving but even in WordPress which arguably has a larger number than most projects, it’s not a high number. 

As a result, one focus that is key is enabling and empowering design across roles. A dev can create a good first idea when supported and given space.

Related to this is having a design system that supports a dev exploring. In WordPress this is at the very early stages but already seeing rewards of easier prototyping.

Clear space

Design needs to be given space to thrive. 

I love simulation games, so imagine you are playing a farming game, you set the clear space where your field will be, set the boundaries out to denote the field. Like in games, the clearing is key. Show ways people can contribute and then signpost, show options, paths. 

By breaking down into tasks, clearly defining stages, phases, this helps designers get on with designing.


Single points of failure will end up failing so constantly looking at those is key to where to bring more people into tasks. Note taking for example is a great starting point.

To grow, that needs nurturing, trust and a starting point. Just saying people are design leads is a pretty sure way to have that not work. There needs to be some structure in place to support that role.  There also needs to be opportunities beyond big project leading.

Establish cadence

Regular practices bind an open source project. Be it the weekly meetings or updates. 

An agenda posted 24hours before the meeting ensures anyone no matter what timezone can comment. Similarly notes and using Slack to record meetings, linking archive in notes, ensures anyone unable to attend can still comment and have their say. 

Humans are creatures of habit. It’s easy to forget this. If you as a team have a strong weekly cadence it soothes and people know what to expect.

One way to reduce the firehose here if a schedule seems overwhelming is to highlight what is required and what is optional. By doing this you give people options for deep work and to ease the pressure.

Document everything

Documenting leads to future contributors needing less hands on, which opens up to timezones with less active contributors. For example, a contribution day in Taiwan can run by itself for design as there is a contribution guide in the design handbook. 

There is a lot of oral history in a project that’s been around a while like WordPress, this needs to change. Breaking this down into simple workflows, small actionable flows that someone can follow is great to enable people to do for themselves. For example, how to run a triage session or even lead a focus.


Just setting and forgetting isn’t an option. You need to check/iterate and adapt. Static ops are death. Constantly you need to check how strong your feedback loop is.

Make triage daily practice

In design, we also run triage sessions twice a week as a team. The time is the same each week and this gives an opportunity for people to come along and start participating. Also as a group, we are working together, something really important for designers. It’s a way someone can start to give feedback. You don’t need to get over the hurdle of technology, just turn up and join the conversation remotely.

Triage is not just an event though, it should be a daily practice. Both issues but also of processes. If something isn’t working, weed it out.

Roll up your sleeves

In some spaces an operational role means that person doesn’t get involved with the design, this just isn’t one of those. It’s important to see where you can best help and do that. Perhaps you need to get deep into triage, perhaps break down a project into tasks and dive into a plan… other times you need to boost some mocks or run some usability tests.

You walk together, as a group. Whatever clears, whatever keeps the pace going and flow of a project, that’s what working in this space is about.
The nature of OS means often it’s all hands on deck, that means everyone.

Anyone coming into this can’t sit in an ops tower looking down, you have to get hands-on, that’s the nature of this space. I actually would argue that this should be the way Design Ops happens

The future

What of the future? Everything is done today is foundational.  Projects are starting to recognise the need for design over designers being seen as pixel pushers and ‘i dotters’. 

Code committing though is still the top currency and that model doesn’t work so well for non-developers, so there’s a way to go.

For many, working async brings an inclusion that working sync doesn’t. Remote brings opportunities to those that would have to move otherwise. Open source projects are spaces where people can skill up, often even changing their careers and running their own businesses.

Open source allows you to reach beyond your perspective. Being involved in a project can open you to different cultures, views. It also allows people to make a living without some of the barriers maybe they have due to location or economics.

We don’t need to shout as loudly as have in past, Design Ops is at the table and recognised.

Design is part of Design Ops and we can’t lose the design process in its practice. Getting fixated on it being the solution in isolation only harms. It has to respond, blend with other practices like DevOps and become part of the process. It only works when done like this, when it’s something not separate, but part of the holistic practice, entire solution.

Open source can truly change the world and people’s own worlds. 

For a designer, it’s a truly exciting space, one of experimentation and so many opportunities to improve experiences. 

As an individual you can make an impact in a project, but also through your work you can truly make a difference in the wider world, to reach further than you have before. Open source can enable everyone to have access to good design that does good. Access can also be open to anyone that wants to learn design.

These projects need DesignOps to open up those opportunities, to sustain growth and create a space where design flourishes. The seed has been sown, it’s now about supporting, weeding and watching it grow.

Leave a Reply

Your email address will not be published. Required fields are marked *