Photo credit: Plain Schwarz.
On March 13 and 14, 2023, two of our team members, Eriol Fox and ngọc triệu, and one of our collaborators, Django Skorupa, attended FOSS Backstage, a two-day conference focused on all aspects of free, libre, and open source software (FOSS). The conference covered topics ranging from Sustainability and Funding, Diversity and Inclusion, Legal and Compliance, to Governance and Community. Attendees had the chance to discuss the latest advancements and challenges in the FOSS ecosystem with funders such as the Open Technology Fund, Sovereign Tech Fund, Prototype Fund, developers, and community leaders in the FOSS ecosystem.
Design With A Capital D: Design In FOSS
Our workshop at FOSS Backstage focused on “Design with a capital D” because it’s what FOSS has trouble receiving, and for valid reasons. However, it’s an essential, critical, yet invisible part of getting to the tangible design.
Design in FOSS is not a new concept. Designers and those who work on FOSS tool design have been around since the beginning, and may have previously been referred to as usability or human-computer interaction (HCI) experts. Regardless of when designers in FOSS initially started, it is becoming increasingly clear that there has been a growing trend and interest in design within OSS over the past five years or more. Design has become an integral part of technology tools in both proprietary and commercial settings. More and more organizations and companies are adopting design processes and including designers as part of their technology projects.
The definition and description of UX Design often varies, depending on factors such as the organization, geographical location, and design team. While those collaborating with designers tend to think of design as limited to visuals, graphics, logos, UI, and tangible aspects of design, designers often provide a greater function than their deliverables may suggest. However, for many FOSS projects, those deliverables tend to align with what is valued, such as code that successfully functions.
But what are those other functions? Often referred to as “Capital D Design” it involves research, thinking, conversations, collaborations, facilitation, interpretation, intuition (from hypotheses), and applying a broad range of design knowledge. This type of work is very difficult to contribute to in a traditional FOSS “pushing code” sense, so it is largely absent from design in FOSS. Designers have only recently become comfortable with opening up their design processes to the public, and tools like Figma and Penpot’s shared teams/files are focused solely on tangible design work. Most of the time, any design work will have a lot of “Design with a capital D” beforehand, but it’s mostly invisible.
Making Design More Open: A Design Workshop For Non-Designers in FOSS
Our workshop was designed to assist non-designers in FOSS in understanding and implementing design principles and tasks that enable them to appreciate the value that design brings. Its aim was to equip them with the necessary knowledge to request appropriate design services for their projects and to feel confident participating in design for FOSS.
Photo credit: Plain Schwarz.
Photo: Eriol Fox speaking at FOSS.Backstage 2023.
We embraced a human-centered design (HCD) approach for our workshop, aiming to make it relevant and easy to relate to by leading with our personal stories and experiences of doing design in the open source world. As most of the participants were developers, we selected and arranged the design activities with respect to the design process, time allocation (60 minutes), and the audience’s level of design proficiency.
We started by presenting pre-prepared profiles of established FOSS projects that the participants may have already been familiar with. These included Scratch, Python, and Signal. Each was accompanied by a brief overview of the software, target audience, and objectives. Participants were divided into groups of 4-5 people before going into our chosen exercises.
The exercises that we chose to introduced in this workshop include:
1. Value Proposition
For this activity, each group was tasked with creating a value proposition using the profile of their assigned FOSS Project. A value proposition is a simple and clear statement that communicates the unique benefits of a product or service and sets it apart from other similar products or services.The typical components of a value proposition include: Name, Description Target Users, and Purpose.
An example of a value proposition statement.
Download The Value Proposition Generator Template
Participant Feedback
This exercise helps teams of people who may not have met or worked closely together before, come to a quick understanding and consensus about a project or tool’s intentions. However, one point of confusion for our workshop participants was whether to write the value proposition from the perspective of a) a user of the FOSS tool b) a contributor to the FOSS tool c) both combined.
2. Personas
In this activity, each group of participants received a persona for their FLOSS project profile. A persona is a fictional amalgamation of demographic information created as a design tool to ensure a project stays on track for the needs of the stakeholders. Personas are always rooted in the experiences and wants of real people. For optimal results, the stakeholders should consist of real people randomly selected from a diverse range of demographics that are directly affected by changes to your product.
An example of three personas used in the workshop.
Participants were asked to consider one of the personas assigned to them, with the specific instruction that despite their own personal interpretation, this person both values and wants to contribute to the project in question. Based on the participants’ understanding of the project, and the persona on the table, participants were asked to anticipate struggles that those personas would face when attempting to contribute to or use the project. Specifically, they were asked to consider whether or not anything needed to change about the project. Our hope was to prompt them to see their project through the eyes of another person, and understand that sometimes, the most successful research that you can conduct is research that entirely disproves your initial hypothesis.
Learn More About Using Personas In FOSS
3. User Research: Conducting An Interview
Roleplay Scripts: Getting Used To User Testing
In this activity, participants had the opportunity to learn and practice user testing. One person was assigned as the interviewer and another as the user, with the former receiving a guide and a script and the latter being given a persona who they had to pretend to be. We emphasized that there was no wrong way to do the exercise and encouraged participants to have fun, break character, discuss, make changes, and explore what the practice could do for the OSS projects they maintain or contribute to. In addition, we noted that having their hypothesis destroyed during the exercise was extremely beneficial as it saved time that would have been wasted on competitor analysis, design, development, and launching a product that the existing community had no use for.
Participant Feedback
As a designer and facilitator, you know an exercise is engaging when your audience doesn’t want to stop! Even though role play can be tough for many reasons beyond the initial embarrassment (e.g. language barriers, interview technique and improvement), finding out new information about your FOSS tools and software can quickly help participants overcome these difficult moments. After the workshop, participants left with the scripts in hand as well as a host of other examples from our ‘A Dev’s Guide to User Testing’.
Key Learnings And Takeaways
As the name of our workshop suggests, we hope we made design more open to non-designers of the FOSS ecosystem by opening our design process and offering an opportunity for hands-on experience with different design tools and methods.
Our key learnings and takeaways are:
We should keep working on improving and adapting conventional/industrial/standard design tools, methods, and practices to accommodate the specific needs of the FOSS communities.
The FOSS community is wary of industry and the ‘standards’ that are popularized by it. Understanding how and when to introduce an industry-created method is key to its usefulness in a FOSS project. It is also important to know when to adapt and change a method to better suit the principles and goals of FOSS.
Be more strategic about the resources and tools introduced and used in workshops.
For example, we could use the introduction of Value Proposition as a case study to think strategically about ways to improve the method itself by asking: “How is Value Proposition as a design method perceived and leveraged differently in OS design compared to industrial design, and how can it better serve the needs of the OS teams?”
Ensure that design has a presence at FOSS events on a large conference scale, as well as a smaller project-to-project scale. It’s challenging but always worthwhile.
When running workshops around design in FOSS conferences and spaces, we often find ourselves with a full room ready to learn. This has generally improved over the last five years as the FOSS community values non-code contributions to FOSS and understands that building sustainable, usable open source software includes design and designers.
Further Information
Speak to us about bringing design to your conference or FOSS project by emailing us at [email protected].
Session slides here.
Watch recordings of all the sessions here.
Credits
Contributors: Eriol Fox, Django Skorupa, ngọc triệu.
With support from Open Technology Fund.
