In an exasperated voice “Why is it so hard to get designers in open source.” I hear this all the time. Well firstly, it depends on what sorts of skills you’re talking about. Just like in code, there are small tactical problems that are good first bugs. Even the simplest issue requires a knowledge of the design patterns that the site employs.
Many of the bugs, however, require a deep understanding of why the product exists in the marketplace and a thorough understanding of the research that underpins the project. These strategic questions are analogous to what a software architect would do. I was on the Persona project full time for three months before I felt confident making significant choices about UX.
Open source generally isn’t welcoming to designers. A shock, I know! There are many reasons for this.
- In general, coders don’t know what to expect from us. My conception of what I do often bears little resemblance to what coders think I do. When I join a team that’s never worked closely with a UX designer, I have to educate them. Otherwise, there’s a gap of misunderstanding that leads to stress and unhappiness. We get up in your business and ask you to change things that you don’t want to change because
- It seems trivial and unimportant.
- Conversely, it’s too hard.
- You don’t agree.
- Ultimately, we’re beholden to convince a dev to implement our bug, likely because we don’t code or even if we do it’s not the best use of our time to be implementing. (If you want to pick a fight, insult a designer by asking why we don’t “just learn to code.”) We’re starting from a disadvantaged position. In version control systems such as github, code talks and designers don’t speak the language.
- Probably the most daunting question for projects without any design lead that has the trust of the team is, how do the devs know if the proposed design is correct? Without that trust, bugs quickly devolve into nasty arguments. How you build that trust has been the subject of entire books. But the question remains, who and how do you approve a mockup? The code review process works great for just that… code.
- Github issues and their parallels track problems at a level of granularity that’s useful for devs. The UX problems that constitute my work are of a much larger granularity. When I add such a strategic issues to the tracker, it makes devs uncomfortable. There’s nothing actionable here. There’s nothing to implement. My job is to think through big issues. By the time I’ve converted it into something a dev would recognize as a bug, my work is done. Thus, representing the work of a designer requires a shift in culture of the dev team so that they won’t close down my issues.
- My UX bugs are all tracked publicly in Persona’s github and yet I can count on one hand the number of UX volunteers that have contributed to the project. It’s not that there aren’t any good first bugs, its that there is a shortage of UX/UI designers in the market. Yes, I’m sure Mozilla could do a better job of getting designers to volunteer. We know it and we’re working on it.
The solutions to all these problems lie in communication and building a trusted relationship. It’s a higher barrier for designers that takes time to overcome. I’ve found all of my team to be receptive when I’ve taken the time to explain the principles that guide my decisions. I work with an awesome group of super smart folks! They just need to know I’ve got this handled. The longer we work together, the more shorthanded my explanations can be. Designers start by renovating small stuff and move up to innovating as they build their reputation. As the paid UX designers in Mozilla change the culture, it will become more welcoming because we will have laid the groundwork. Recommended reading: How to socialize UX into your project and the post I wrote a year ago about design leadership.