When I first started working at the Open Technology Institute (OTI), I was consistently challenged with the question: "Why would a UX designer want to work at an open source organization?" The truth, in my opinion, is almost all design and usability work is by its nature open source.

Designers build on and adapt from design patterns that we see and experience in the world around us. We are constantly sharing and testing our ideas with our peers and collaboratively iterating on concepts because good design is widely understandable. There are great resources around the Internet [see below] on usability and design best practices, and many of the open source user interface frameworks are building these principles into their toolkits, so that the lines between developers, designers, etc are even more blurred.

The question remains though: Why do we so rarely see usability professionals and designers in the open source community, and how we might begin to change that?

Open source processes and projects are also not highlighted as frequently in design and UX schools and conferences, limiting the awareness in design communities of the needs in the field. Additionally, as I touched on above, the evolution of software frameworks, libraries, and toolkits, such as Twitter Bootstrap, and AngularJS are allowing the roles to blur, and making it easier to "fake it until you make it." While on the one hand it's become clear that usability and design are crucial needs for both user facing and developer facing projects (APIs need to be usable too!), there seems to be a divide as to the percentage of designers in proprietary versus open source software. In the past, small projects have viewed user experience (UX) as a luxury and therefore not invested in staffing their UX needs. Also, I imagine that the market demand for designers keeps many of them occupied in companies who can pay them competitively, where many (not all!) of open source projects are volunteer run, or operate on smaller budgets.

However, I believe that one of the main reasons that we don’t see as many designers and usability professionals in open source is that they aren't sure how to participate in projects and may not have had exposure to open source projects in the past.

Kristin Williams (left) and Katrin Verclas (right) working with me (middle) on personas and information hierarchy for the Commotion Website and Router platform. Photo credit: Preston Rhea, Commotion Team, Open Technology Institute

At Open Technology Institute (OTI), we've been working on opening our user feedback process as a way to improve our internal processes and collaboration, engage our user community more, promote non-developer contributions, and think more broadly about how open source process plays a role in the Commotion Wireless project, a free and open-source communication tool that uses mobile phones, computers, and other wireless devices to create decentralized mesh networks.

For the official Version 1 release of the software, we decided to do a full overhaul of the user interface, focused primarily on the version for wireless routers, but also on aligning the other platforms (Mac, Linux, Android, Windows, iOS) to the router. Mesh networking firmware is not your everyday project—our development team frequently is focused on how to add more functionality while simultaneously making the files smaller so that they can fit on hardware with very little space (only 5.2 MB!). Meanwhile our field team, of which I am part, is researching how mesh networks can leverage existing social relationships, developing training and adoption frameworks, and testing these ideas out with communities who are interested in experimenting with community-owned infrastructure.

In my next article, I will expand on these 5 tips that we learned from our user-centered design review of the Commotion interface.

5 tips for leveraging user-centered design in your open source project

1. Track usability and design issues.

Gather context as well as feedback. Don't respond (with software/design changes) to each piece of feedback. Synthesize issues for themes.

2. Understand who you want to design for.

When making design decisions, you often have to prioritize which type of user to design for—novice or expert users.

3. Make prototypes.

Leverage the style of the prototype (low-fidelity vs high-fidelity) to get the type of feedback you need.

4. Understand how the software works from the user's perspective.

5. Use usability/design iterations to build your community: hackathons, mailing lists, and distributed tools.

Additional Resources

View the complete collection of Women in Open Source Week articles.