For the past few months, I’ve contributed to ChRIS (Childrens’ Research Integration Service) as a user experience (UX) designer.ChRIS is a cloud-based, open source framework for processing medical imaging data; it was originally conceived by a team at Boston Children’s Hospital and successfully executed with help from the Mass Open Cloud (MOC) and Red Hat.

Working on the ChRIS project is fulfilling in a direct way; it applies open source technology and principles to improve patient care. Doctors shouldn’t have to be computer scientists to be able to use the best innovations in medical image processing technology to improve their patients’ outcomes.

Enabling doctors to make use of leading-edge, yet frustratingly esoteric, software to improve patient care is an example of the larger challenge of UX in open source. Open source software is ubiquitous: it’s running and improving systems and services around the world, and sadly has a well-earned reputation for terrible UX. Technology’s core functionality is not enough: a great UX is necessary to unlock its full potential!

Let’s talk about some of the reasons open source UX came to be this way, and actionable things we can do to make it better.

Inconsistency and lack of integration

Software workflows often involve different tools working together.

Consistency across tools at a surface level involves properties such as tools that use the same icon set, have a compatible look and feel, consistently name functions, and consistently position and label buttons and menu items.

The integration of tools involves individual tools interacting with each other that make cross-application workflows more seamless; for example, sharing accounts, data, assets, and settings.

Open source projects tend to form around individual tools rather than higher level workflows. The latter requires cross-project coordination and agreements to provide consistency and integration.

UX debt

Choice can be freeing, but it can also be a tough burden. The more choices we as the creators of software “push onto” the users, the more UX debt our software accumulates over time. If a piece of software requires configuring 20 separate options in order to be usable, it’s accumulated far too much UX debt to be usable by most people, as it requires specialized knowledge that only a limited number of people have.

I think open source projects tend to have a lot of UX debt because we sometimes conflate software freedom with choice at a low level. It’s actually more oppressive to overwhelm users with esoteric choices than to provide a streamlined set of options.

Itches, not requirements

The origin story for a lot of open source projects is that the initial creator of the software had an itch to scratch. In making a custom thing for themselves, they didn’t focus on selling it to a lot of people and meeting the needs of a broader population, and have a hard time clearly seeing its quirks from using it for so long.

It’s not all gloom and doom though. We can fix this with UX design; let’s talk about how.

Ways to address UX and open source challenges:

Avoid echo chambers

The current user base of a lot of open source projects consists of highly technical users that often are contributors to open source projects as well. To avoid the whole thing continuing to be an exclusive echo chamber, we have to work to be more inclusive.

The users of open source right now aren’t necessarily the users open source needs to expand software freedom to all. When seeking feedback or usability testers for your open source application, be sure to include some folks who are not current users hooked into the community.

Establish boundaries

In open source projects, there isn’t always an explicit structure for decision-making or clear accountability for decisions. Open source communities tend to be more fluid. Design decisions can span across a lot of parts of the software (and across different applications) and can require buy-in from a broad base of the community. It can be challenging to get consensus in this kind of situation—freeform design discussions can lead to chaos, flame wars, and indecision—so establishing boundaries up front and setting up a framework for decision-making can be particularly helpful for practicing UX design in open source.

For example, when sharing design artifacts for feedback, make clear what kinds of feedback you’re looking for on which parts, and also make clear what you’re not looking for feedback on. Also make clear who is accountable, and who is making the final decision.

Avoid conflict with transparency

Be transparent from the start with any open source design process. Start with the problem you’d like to tackle, and as you research, learn, and prototype along the way, make sure you work on communications within that community so any final designs don’t catch anyone by surprise.

Red Hat’s open source Open Decision Framework is a great place to learn more about how to do this.

Add functionality with caution

While this is true for all software, it’s especially true in open source because there is a lot of pressure from users—who interact directly with the software’s contributors—to add functionality. Sometimes that pressure may be a pretty tempting, fully-coded patch contribution that implements the requested functionality. Adding functionality can become a form of UX debt. When you have more functionality than a project can commit to, or when you allow users to come to rely on something you can’t fully commit to, it can negatively impact the user experience.

Fortunately, ChRIS is an open source project that focuses on higher level workflows and actively prioritizes user experience. I hope the project inspires other open source advocates to realize the importance of UX in their projects and take action.

Get involved in ChRIS

Experience the "Creating ChRIS" series