How to get designers involved in your software project

No readers like this yet.
Participation text on a field

I attended Una Kravets' OSCON talk, "Open Source Design: A Love Story," after interviewing her recently.

To begin, Kravets reminded us that we all gathered at OSCON to be inspired to innovate. She also noted (as we all know) that the technology sector is not as diverse as it should be—and that this problem is particularly bad in the open source world. And when Kravets talks about diversity, she is isn't referencing gender and race, but a variety of skill sets as well.

Kravets showed us a report she found. It reviewed 23,493 GitHub projects and found that 75.3% had no gender diversity at all. This brought Kravets to the following quote from Malcolm Gladwell: "The world that we could have is much richer than the world we've settled for."

The world we have settled for is broken, Kravets said. We love open source and open source communities—but it's broken. But Kravets suggested we have the power to make it better.

To explain how, Kravets shared with us the story of the road. This story has three characters: the designer, the developer, and the business person.

The business person says, "We need to get from Point A to Point B," and he tells this to the developer. The developer says, "Good idea, let's build it with this new technology." The two then approach the designer, and she says, "Let's build the road on the coast so that people can enjoy the ride."

The moral of the story? Diversity creates better projects. So, why aren't designers participating in open source?

Kravets answered this question in two ways:

  1. Because many designers harbor the idea that they have to be paid for their work. We must fight against the idea that it's bad to do work for free.
  2. The second reason is the 'museum effect'—people are scared to touch things and break things.

Kravets then proposed two ways to encourage designers to participate in open source projects.

Encourage a more open design/development workflow

Don't design alone, Kravets said. Design in the open so everyone gathers feedback along the way. If you let a designer go off to work on her own, when she returns with a final product she might be frustrated by feedback and requests for change. Instead, ask the designer to work in the open as part of the team. (Git can be a starting point, Kravets said.)

Kravets created gulp-starter-env on GitHub in order to give designers the tools they might need to do their work. The next key to making this work is to share excitement. So when Kravets's team of designers figured out how to push to git, she celebrated those wins with them. Telling a designer she must learn to code will make her defensive, whereas sharing your excitement about code with her will make her curious. This is what was want to do, Kravets explained.

Foster design participation

With Kravets's team, this was easy—because they were already using GitHub and excited about it. But how do we do this with others? For this, Kravets gave us the CARE acronym.


This is as simple as letting people know that we want their help. In GitHub, we can label things "design" in order to show designers the issues they can work on.

We can also create project boards. These can include all the information about ways designers can get involved, and list our design standards (such as colors, style guides, etc.).

Using GitHub, we can create a "checklist" that functions as a visual way to get designers involved in our projects and helps them visualize their progress.

And finally: Use a lot of images! Designers are visual, and these images help people see how things are supposed to work.


Ask yourself: "Can people get started with my project?" Always be sure to have "getting started" documentation. "Readmes" on git are notoriously useless, so make yours more accessible and helpful. Assume the person reading it has no coding experience. Create a lexicon to help new participants. While devleoping, we all use jargon, but newbies don't understand all of it.

Kravets did an informal study and found that projects with websites, documentation, and demo exhibited more diversity. And projects with more diversity were more likely to have documentation, websites and demos. So documentation increases diversity, and diversity increases documentation. I found this interesting, as a female documentation manager on a project (Koha) that didn't have a complete manual before I started participating.


Design builds community. We can see this with logos. A logo creates a visual asset around which people can gather. Kravets showed us a GitHub thread that featured a community trying to design a logo together—but things went horrible wrong and started to attract trolls. Respect means more than just needed to attract designers; it's needed to keep open source projects going.


Open source is about people! We should treat contributors as we treat our families. There is an argument culture in our communities, where it's more important to be technically correct instead of listening to ideas and working as a team.

To conclude her talk, Kravets suggested we set up feedback guidelines for our communities:

  • Ask don't tell: "Why did you decide to..."
  • Be specific: "When you are calling the..."
  • Explain yourself: "Check out this blog post..."
  • Offer solutions: "Maybe try..."
  • Avoid hyperbole: Avoid "Never," "No," and "Don't"
  • Use emojis: Because they make everything better

This article is part of the OSCON Series for OSCON 2015. OSCON is everything open source—the full stack, with all of the languages, tools, frameworks, and best practices that you use in your work every day. OSCON 2015 will be held July 20-24 in Portland, Oregon.

User profile image.
Nicole C. Baratta (Engard) is a Senior Content Strategist at Red Hat. She received her MLIS from Drexel University and her BA from Juniata College. Nicole volunteers as the Director of ChickTech Austin. Nicole is known for many different publications including her books “Library Mashups", "More Library Mashups", and "Practical Open Source Software for Libraries".


Being a designer looking to get involved in an open source project, should you then use open source software to create those designs?

Thanks for the kind shout out, Nicole! I very much believe that open source is the most viable way to run a design shop. Going strong!

In reply to by ncbaratta

Thanks for this! We definitely need to make open source communities more welcoming to designers of all stripes, and more respectful of their skills.

However, there's one specific point where the phrasing concerns me: "Because many designers harbor the idea that they have to be paid for their work. We must fight against the idea that it's bad to do work for free."

Folks with valuable skills *should* expect to be paid for their work. We may choose to give freely of our skills as a gift, but in those cases, it's because we find the contribution process intrinsically rewarding, such that the personal benefits we get out justify the time we put in.

There are very few open source project environments where I'd be willing to tell a designer that participating openly will see them well rewarded for their efforts - they're far more likely to drown in a sea of nitpicking and attempted design-by-committee.

About the only thing I've seen work well in terms of bringing a design mindset into an environment where designers are not yet respected is for senior developers to step up as advocates for deliberate user experience design, and to actively shield designers from pointless bikeshedding arguments (while still passing along any actually useful feedback), as well as accepting responsibility for any design decisions that turn out not to work as well as hoped.

This ties into the CARE aspect of the article - it isn't designers that are the problem, it's the fact that the way we communicate is far too often actively hostile to good design processes. When we start caring about design, and appreciating it as a skill distinct from development, then we can start to provide environments that designers find as welcoming and intrinsically rewarding as developers do.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.