[December '21]

Please tell us about yourself

Eriol: My name is Eriol (they/them). For the majority of my career I’ve been a designer, so now I’m a hybrid between a product manager and a designer for open source and security privacy tools. At Simply Secure my main role is Product Manager for an open source tool. While I’ve been designing for over ten years, I started working on open source projects in the last four or five years, both as a paid and unpaid contributor. I wrangle and help organize several open source communities, the most notable being the Open Source Design community and the Sustain Open Source Design and UX Working Group. I also enjoy giving talks about designers in open source. One talk in particular focused on helping designers contribute to open source through the lens of social good (this was related to my work on a substantial project at Ushahidi).

Kelsey: I’m Kelsey. I’ve been a designer at Simply Secure for two years. My background is in art, business, and teaching, so I bring different perspectives to my design work. So far at Simply Secure I have worked on exploring institutional trust with data collection, simplifying digital security practices, and serving diverse communities through participatory user research. I’m excited to continue to contribute more to open source, because I see a lot of opportunity for design and design methods to help teams build tools that are more beneficial and usable to their end user.

What are you working on right now?

In collaboration with Internews and Okthanks, we are working on USABLE, a project to provide design resources to open source tool teams. USABLE resources focus on supporting developers and tool teams to better understand design practices and how that can help them create more user-centered tools.

Through previous experience, we know that teams have similar questions about design and even some misconceptions about what design is. To lay the foundation for USABLE, we interviewed several tool teams to understand how they incorporate design into their team and how they work together. Our resources can guide teams if they don’t have access to a design expert or funds to hire one. And if they do have a designer on team, these resources serve as a base for design activities that everyone can reference.

Our first design topic that we explore is user testing. This is a big topic, so it’s split into a series with three parts.

First is a short and consumable FAQ, “User testing can be fun", which lays the groundwork to introduce user testing. There might be hesitancy or difficulty adopting a user testing practice, so this resource provides reassurance, because we believe research is the cornerstone of UX design.

The second resource is a primer called, “A dev’s guide to user testing,” which provides the details about the user testing process. Instructions, considerations, and templates break down user testing into a formula, so that the process is accessible and adaptable. It’s a supportive presence that exposes the inner workings of how designers plan and facilitate user testing so that it’s demystified.

The third resource (being drafted) closes the loop on the user testing process by helping teams synthesize their research results. Synthesis is the essential part of the process where you all come to agreement on what can be done after learning from the user testing. This part of the process can often feel daunting because it is making sense of what you’ve learned and there can be different perspectives on how to interpret those results.

We will kick off 2022 with more resources related to working with designers.

What is most interesting about that?

There are many resources about design and design research. We specifically wanted to make guides that were digestible and applicable to the open source software community. In addition, we set out to engage with the community. The resources are paired with engagements that take a variety of different forms and platforms, trying to find those places where we can meet the community. We believe that design offers so many opportunities for open source tool teams to be led by their users. That’s including the users they know or the users they don’t - there’s opportunity to include new users.

How did you first discover FOSS?

Eriol: My first discovery of FOSS was when I was working as a designer on proprietary, non open source tools. Many of the developer coworkers talked about open source and I didn’t understand it at first. I was curious to know what they were talking about, because sometimes they would recommend open source resources, like an open library for a specific functionality. So they were kind and gracious enough to talk me through using an open library for our work. Yet, I didn’t really get involved in open source at that time.

Kelsey: My job at Simply Secure was my introduction to the open source community through partnering with open source projects and coaching Prototype Fund grantees in UX design. I’m slowly piecing the concept of FOSS together through working on various projects and still learning a lot about it.

What prompted you to start contributing to FOSS?

Eriol: I asked one of the developers that I was working with about when they contributed to open source and they told me that a lot of developers contribute to open source as part of their non-work hours. I was fascinated by this part of contributing to open source software that was culturally-embedded with the process of being a coder or a developer (if you decided to participate). I started looking on forums and learning about open source more in general. I wondered if there are designers making contributions to open source.

Kelsey: It is my job to work on open source projects at Simply Secure.

Why should others get involved with FOSS?

A great thing about open source software is that it’s remote global and open, which means that the USABLE resources are open to tool teams, but also other designers’ contributions. We hope that in the future these resources are not just representative of our (Kelsey and Eriol’s) knowledge and experience, but that they can be improved or expanded over time by designers of different backgrounds that have different experiences working on other projects. It’s important to have these USABLE design resources as open as possible in and of themselves, so that it doesn’t end with our knowledge.

How should they get started?

The first step is just to read a resource or attend an engagement and remind the people that you work with that these resources are there for them. If you have questions, let us know. We welcome anyone to try the USABLE resources and give us feedback. We’re excited to change, improve, clarify, and tailor the resources to the open source community.

What difficulties and limitations do you see with FOSS?

As we discovered in our interviews, perhaps one of the biggest fears that developers face is that design feels like the process of being corrected. Design is not just about pointing out where assumptions have been made about tools or about how users use tools. The limitation is understanding the role of design in any kind of software. One of the hardest things is about changing the perspective of how designers participate. Because we want to see a great tool created as well.

How can they be solved?

Instead of a combative atmosphere, we can face the same direction and work together. We would love to see tool teams embracing designers from an earlier stage of the process. If you’ve ever caught yourself as an open source tool team saying, “We’ll talk to a designer later” or “Let’s wait until we’ve done this bit to include designers” or “We’re not quite ready yet,” we would encourage that you take the leap and include them earlier. That’s how you can start the process of walking alongside each other rather than perpetuating the old-fashioned narrative that designers are consultants that come in at the end and do corrections.

Where do you see difficulties in contributing?

Eriol: With design, it’s harder to see the outputs, especially if it’s user testing or UX research, and not UI and visual design. So it can be hard to practically contribute that kind of work because it’s conversational, written, and interpretive. It’s the how and the why, rather than the what (the execution). And design takes a longer process. It’s harder to create a set of issues, a spike (a research, discovery and scoping task commonly done by developers to investigate an option before committing to one kind of solution), an epic (overarching piece of work on software) or a pull request for UX research, and then integrate it into a development pipeline. The resources that we are creating try to expose what those practices are so it could become easier to consider a pipeline of development that includes design processes.

Kelsey: Some days, I feel like I’m not making progress because I’m not “designing” something. There’s a lot of background work that goes into getting setup so that I’m ready to do design work, such as researching, solidifying guiding principles, or figuring out what to prioritize. To an outsider, it might not look like design, but it takes a lot of consideration. The end user won’t see that work, but it’s still part of their experience. If I’m not moving around pixels in the final design spec, is the day’s work still valuable?

What does a perfect day off look like?

Eriol: Catching up on my pile of reading that I have (both open source books and non open source books).

Kelsey: Eating really good food (preferably Indian), and enjoying beautiful weather. cries in Berlin

Do you want to tell us something else we didn’t ask?

Eriol: I think a lot about how we as designers can best communicate and justify the value that we can offer OSS so that they can begin to include us in their project roadmaps, scoping and budgets. This doesn’t have to look like ‘traditional’ funding like applying for a grant for a designer’s salary or hiring a design contractor or agency, but how do we help OSS policy makers and projects be able to look at different kinds of funding models for design support? Does sponsoring work? Are dedicated design maintainers a role of the future and what does that include and how does that get funded? I think that good, usable and relevant design of OSS and designers present in OSS will become less rare when we start to value that labour and why it’s as important as the written code. Soon, I’d like to have a conversation about how we fund designers in open source.