In December 2022, Superbloom partnered with Internews and Okthanks to create resources that help open source software (OSS) teams better understand how design processes and user-centered activities improve usability, and therefore the security of open source tools. After publishing these resources and speaking about them to the wider OSS community, we found that designers and developers working in privacy and security OSS tool teams wanted to explore specific challenges through conversations with us. This led to the final component of the Adoptable project in the form of coaching.
Coaching draws on the wide, collective knowledge that Superbloom team members have gathered over 10+ years of working in the internet freedom, Human Rights technology and Privacy and Security tool spaces. We called this work Adoptable:Coaching. Below, we outline some insights and needs we discovered while coaching privacy and security OSS tool teams. We utilized our general coaching approach to this project, and you can find out more on the Coaching page of our website..
This work was highly sensitive, and publishing it could cause risk and harm to participating individuals, which is why we have abstracted and generalized our coaching learnings and have not mentioned any identifiers ie specific tools, teams, individuals or information.
You can find all of the resources we created as part of the Adoptable project in an open repository where you can access files directly and engage with the project. These are also available on the Adoptable project website.
What common needs came up in our coaching sessions?
Designers (and we suspect those in other less prominent and valued roles in OSS production) often operate in a reactive state.
Much of our early coaching conversations were around responses, strategies and methods that designers (though these can be broadly applied across job role function) can implement in order to gain an active or proactive role in their OSS projects/tool teams. There was deep discussion about how design can act as the user-voice. And about how design can then advocate for user-voice’s prominence in software development cycles. This then led to a concern around how to avoid design/designers being characterized as “strong personalities” or as a “gatekeeper” who stops technical improvements. This is often a tension with an OSS project’s ideas about how the OSS “should” be built and from whose perspective.
Practically, many of the strategies employed include ways of managing a plethora of complex conversations about product direction at the same time as maintaining the time, space and resources to adequately research and express user insight to the wider OSS team.
For suggested exercises, you can take a look at our User Experience Toolbox For Risk Mitigation And Accessibility (see Part 2: Assessing Risks & Threats) about how to think ahead and communicate user needs through your role in a Privacy and Security focussed OSS tool.
Communicating when, why, how and what kind of projects and tasks to introduce and implement for user centered design processes.
We coached on how to best communicate user centered processes in small software team development cycles. This included when to introduce these processes, for what scale of project and/or task and pacing of that process. Designers, specifically those unaccustomed to small development teams and OSS processes, tend to lean towards taught design methodologies which stress grave importance on the order in which to perform design processes. While holding oneself and a small and open source development team to a strict order, and a model that nets user centered benefits; more often than not it decouples design from development. In most cases, we advise a collaborative stakeholder approach to user research and user centered design as well as an approach to “make your own opportunities” as a designer in OSS. OSS can be described as a “show us the benefits first” operating structure, and it helps to have evidence for processes that benefit the tools and software.
This is a tricky balance as it toes a line between complete transparency - by stating your intentions with design in the OSS development process - and an “ask forgiveness not permission” approach. Often the best assessment of which approach to use is already known to the coachee, yet reasonable and rational worries remain about their credibility and the function of their role.
One method we coached on, to help folks develop a transparent and clear understanding of design needs for users, was a process of translating “issues” (typically written in a development centered way) to design challenges that focus on users. Other communication methods include consent-based decision making from Sociocracy 101.
When does user research and design lean into “too much” discussion and not enough action? Otherwise known as the variableness of user insight that different designers and/or OSS projects need or want to design well for UI/UX.
It’s a tricky topic, as are most topics that edge into design and user experience in OSS. We discussed deeply some of the inclinations that different roles in OSS have when it comes to doing enough or “too much” user research and the risks involved when assumptions are the basis of design and software choices. The most difficult part isn’t about knowing or not knowing that line, again it’s to do with the communication of that line and the consistent negotiation of that line with the wider OSS tool team and how it ultimately impacts the users.
It’s not always bad to design based on assumptions, but testing and confirming where and when assumptions are accurate, or not, are where lengthy and complex conversations can ensue. Deciding as a team where are the critical and impactful parts of a tools process, and where are the most risk and harms can focus resources on the most critical moments of a user’s use of a tool. And demonstrating the differences between assumption based design and evidence based design surfaced as a key continual resource for designs and OSS tool teams.
A great resource for how to measure, understand and carry out “just enough” research is Erika Hall’s book “Just Enough Research, A Book Apart”. Other advice we have given is to find time to do user testing that isn’t time restricted. User Testing that can be given by users incrementally and in their own time will give the team insight on what they need without that feeling of losing time to a moderated “interviewer-interviewee” user testing process.
Understanding and communicating the value of deep, foundational user research and the tension when there’s still a “backlog” of tech issues.
Similar to the above challenge around “just enough” user research is the challenge of when and how to do foundational research, especially when there’s likely to be an existing backlog of tech debt tasks as well as UI/UX debt tasks. Foundational research, whether focused on users or focused on a specific sector, domain or technology, allows designers, tool teams and, if published openly, the wider OSS community to learn from that foundational understanding. Technology and how it’s accessed and used changes over time and with social, political and economical change. This makes regular foundational research critical especially post situation changing events.
As discussed with our coachees, foundational research is often viewed as costly in time and funds. While this can be true it is also possible to do slower, incremental foundational research strategies with a user community. Though this does often require an existing and amenable user base to initiate. As in most user research work, we came to a similar conclusion in that communicating the benefits of that work and the risks of not undertaking that work is an essential “tool” in the designers toolkit to advocate for what they need. Therefore, it’s key to operationalise these communications and include as many stakeholders in that process of learning as early as possible.
You can take a look at other foundational research undertaken by similar tools and organizations as your own in order to get a head start on foundational research. We recommend looking at Personas - USABLE Tools and Okthanks “A Guide to Clean Consent UX”.
Design teams of one or few have a lot to accomplish. We discussed how common patterns can help us but allow us to not fall prey to privacy and security pitfalls.
Designers working within teams where OSS tools are built are rarely teams of more than one or two. If there are more than one or two designers in a team, it’s likely we’re looking at an organization that has multiple OSS tools or projects and yet, there’s likely to be only one or two designers per project. This often means that designers in these teams play a “full stack” role, doing design and user research, interface design, product design, graphics, marketing, community outreach and product management. To-do lists are long, even if the task is contained and simple. Having others with an understanding of user centered software design with whom to discuss aspects of an as yet to be implemented design was a huge part of our coaching. This raised a further question of how designers can use or build their own “cheat sheets” about how to design within a potentially complex OSS system and ensure that all the elements of the design works appropriately with the OSS. A subsequent need arose about how it could be done quickly, and in a privacy and security focused way. When UI/UX tasks are deemed too small for user research or usability testing, and are designed based on a team’s best assumptions, then this is where critical security and privacy aspects of the design and implementation may falter. Ensuring there are acceptance criteria as part of a quality assurance process for the UI and design aspects goes some way to helping mitigate these pitfalls.
Another tool we have used in the past is the Digital Security and Privacy Protection UX Checklist. We also encourage teams to build and iterate their own security and privacy UX/UI checklists and operationalise this as part of the design to development to implementation pipeline.
Designers are continually fulfilling product management functions in small teams when their plates are already full. Prioritizing PM processes that help design is critical.
Last, but by no means least, the least discussed topic in coaching was the challenge of product management absences in OSS tool teams. Many OSS teams have an absence of product management (PM) within a team member’s core role. If this role is present, those in these roles are often more knowledgeable about software development processes than design processes. This is steadily changing and PM is becoming a valued skill and role in OSS as well as the balance tipping into PM being present in the design phases of software development. The very real challenge for designers in OSS is that when absent, the role of product manager often falls to the designer during the phases of design, and often carries through to development/implementation in order to ensure that users’ needs are well respected in implementation. Through our coaching we found that this split role comes naturally to designers who tend to have an inclination towards seeing software holistically across all its aspects. However, while knowing everything from how an API functions, to how back-end is organized, through to front-end frameworks, is often critical to designing integrated experiences for users, it means that less time is spent on design and more time is spent on product management. This can raise a role definition tension as well as a processes stewardship tension in the teams as product management and guiding the goals of software can be a contentious issue even if governance processes exist within the OSS and the team.
We recently formalized many of our own product management processes, and have coached people on using them as templates in Miro. You can view these here.
Looking ahead
We have noticed that coaching - whether it’s part of a formal organizational relationship or on a casual peer-to-peer basis - is critical work that is difficult to maintain. The main challenge here is that “formal” coaching is relatively accessible to fund, either for teams or via a funder that supports coaching organizations in reaching out to projects and individuals who would like coaching. The less formal peer-to-peer coaching that happens largely in community spaces is harder to fund and sustain and therefore, it’s hard to document the benefits, growth and positive effects on individuals and OSS tools.
Coaching often allows for concentrated time to really dig into a handful of topics in detail but sometimes, coaching is also about solidarity and support for a function that is under pressure and resource constrained. In our experience this mostly applies to designers, but we have also paid attention to other under-represented functions in OSS such as product management, community engagement and building, marketing and documentation/content.
Designers can crave a community of peers to help problem-solve without needing to “upskill” or have to explain “how design works” to people unfamiliar with design terms and processes eg often the time and resources required to plan and run user testing sessions is deemed as “superfluous” or “trivial”. Designers are often then tasked with explaining, often repeatedly to each OSS project, the benefits of user testing and how it saves time and money in the long run. You can read more about the benefits of user testing here. This design knowledge gap is another challenge we meet when coaching OSS projects with no previous design experience because we want to make design accessible and doable by all. We aim to help cultivate space in OSS projects where cross-pollination of functions and roles allows for greater respect and active support in each other’s function and the pressures that begin to stack upon roles or individuals can be better spread among the teams.
Coaching is an evolving practice at Superbloom and you can find out more about our coaches here.
Credits
Project contributors: Superbloom, Internews, Okthanks.