Working in the open

Learnings from designing open source technology

I have been reflecting on the past three and a half years and realized there have been many ‘firsts’: my first time working in open source, building offline first experiences, and working on a fully remote async team.

Of course, any time you try something new, it pushes you in uncomfortable ways and challenges ingrained habits. You are forced to experiment, remix techniques, and think critically about what is essential.

I have learned a lot along the way and wanted to share in case there are other designers interested in dipping their toes into open source. I will break down these learnings into three areas:

• Why working in the open made me a better designer
• From building features to product stewardship
• The benefits of the un/learning loop

Why working in the open made me a better designer

I’d worked on many digital public services before joining the open source world. I thought I knew how to design in the open. I shared research findings and iterations on community blogs and ensured everything was available on GitHub. I was wrong.

There is a difference between simply publishing work online and designing a system that allows users to learn how to configure themselves. From the first idea to long-term maintenance, every stage is open by design.

Designing tools that allow people to build their own applications is complex. You are constantly thinking about how to avoid disrupting workflows or creating unintended consequences for a vast range of users and scenarios.

ODK, the open source company I joined, is a Digital Public Good that has been building and maintaining open source tools for over 18 years. It’s one of the most widely used platforms for data collection across sectors like public health, humanitarian aid, and environmental conservation, and is used in over 190 countries.

ODK’s reach and impact continue to amaze me. In the Democratic Republic of Congo, the World Health Organization used ODK to vaccinate 17 million children for polio, and it was used in 27 EU member states for continent-wide biodiversity monitoring.

Its mobile app was also one of the first ever created on Android! So the scale and complexity of iterating and maintaining these tools is a big design challenge.

From a product design perspective, open source tooling pushes your designs to the max. They need to accommodate factors like working across sectors, regions, offline settings, 60+ languages, and access needs, which is a challenge in government services as well. I think the learning for me was also designing for endless personalization and configurations.

There isn’t a week that has gone by that I haven’t learned something new from a user in the community. Someone who completely reimagined how to use the functionality in ways we could not have predicted, like the time we saw a (very keen) user create their own version of Salesforce for managing smallholder farms using ODK.

When you design for that level of scale with the “garage doors open,” you need to be comfortable sharing every part of your process. You have to be OK with putting early ideas (the ones you’d love to spend more time on) out in the world, because sharing early and often leads to better outcomes.

I was blown away by how thousands of users spend their free time contributing, sharing ideas, testing prototypes, and helping each other troubleshoot. I hadn’t seen this kind of collaboration in the private sector.

Designing with users and building trust through every stage of the process has made me a better designer. It forced me to be clear about why we are making certain decisions and explain things in plain language because there are no fancy frameworks or corporate jargon to hide behind. It only leads to confusion and will exclude people from the conversation.

From building features to product stewardship

Two of the core design principles we created as a team were transparency and trust. Transparency to us meant things like clearly communicating states and giving users visibility into the system so they can troubleshoot. For trust, consistently design with the community, evaluate risk, and anticipate potential harms for user safety.

At the companies I worked at in the past, these goals were often not even on the radar or were something said, but not actually implemented. I was excited to push this initiative forward and try methods that felt challenging outside of the open source space.

Creating a public roadmap had been a goal of mine for years. I have always admired the few organizations that put their plans out for everyone, including competitors, to see. We created a public roadmap using Notion and organized it into now, next, and later, which was a bit confusing for some users initially. No timelines made it difficult to plan for, but it was our best guess based on what we were learning.

Prioritizing a roadmap is already a difficult task internally, but constantly adapting and sharing those changes with the community was a new experience for me. Good public-facing documentation ensures there is a solid record of when, why, and what happened. It holds you accountable and ensures there is no gatekeeping of information.

Everything on the roadmap was also shared on our community forum, but we found that some ideas or things we were testing didn’t always get the wider community feedback we hoped for. To bridge this gap, we started a monthly call with the keen beans (the big advocates and contributors in the community). This did not replace traditional user research or speaking to folks who had frustrating experiences, but I saw it as another channel to connect with users.

Each month on the call, a community member shared their story, we discussed what we are working on, and we co-designed and workshoped ideas together. Above all, it allowed us to get to know the people behind the usernames and avatars. Some of my favourite sessions were when people shared their personal journeys into data collection and tech for good, or the real talk, like when projects go wrong and how others can learn from those failures.

In addition to the calls, we also had opportunities to meet up with the community (thanks to the Gates Foundation) and problem-solve together in person. Everyone plays an active role in stewarding the product forward. The ODK team is responsible for consistently pushing things along, but without the community and constant feedback, it wouldn’t have the same impact at scale.

It’s easy to get caught up in the desire to release often. Shipping features is a great feeling, especially when you see it making a tangible impact for organizations. But open source taught me to think like a steward and focus on the long-term.

Thinking about how a feature will be maintained years from now and ensuring the foundations we build today are robust enough for others to build upon. It is a shift from shipping to sustaining.

The benefits of the un/learning loop

Before ODK, I had never worked on offline mapping tools. Designing new mapping functionality was one of the first problem areas I worked on when I joined. I was intimidated by how little I knew compared to the community members.

One specific challenge involved removing the manual process of getting MBTiles onto a device. If I had skipped the learning part of this process, the messy, confusing back and forth, asking silly questions, and mapping out every technical hurdle, we would have built something that only worked for a fraction of our users.

By embracing the discomfort of not being the expert in the room, we turned a technical bottleneck into a much better experience that made it easier for non-technical users. Learning and failing in the open feels scary at first, but it is the fastest way to grow.

There is a lot of learning and unlearning happening in tech at the moment. Many people, including myself, are constantly thinking about how to be methodical about introducing AI into our workflows, where it adds value and where it could potentially cause harm.

Now more than ever, it seems like there is an overwhelming number of AI solutions in search of a problem. When designing tools for high-stakes environments like public health, you cannot afford to jump to solutioning without a solid understanding of the wider system and potential impact. Not only for users, but also considering the knock-on impacts like social, labour and environmental harms.

Perhaps that is what drew me to open source. It is full of passionate people who care about building technology responsibly, who want to contribute to something that not only helps their work but also benefits others. Do not get me wrong, it is not perfect. There may be fewer tech bros, but there are still challenges, like financial sustainability and maintaining software that underpins a larger ecosystem.

I have shared my thoughts about the benefits of experimenting and wandering in your career, like moving between manager and IC roles. I’m still a big champion of this idea. Wandering outside your lane, whether that’s in your role or trying a new domain, reinforces this learning loop.

It may seem counterintuitive to slow down and experiment with your learning, especially when the tech industry is obsessed with hyper scale and speed. At a time when it seems like everyone apart from you has figured out how to automate and monetize a side business while they sleep, it is easy to feel behind.

But maybe all of this is okay. Maybe the goal isn’t to move faster, but to move with more intention. Whether you are working in open source or just curious about being more open with your design process, I hope you find a space that allows you to be at your learner's edge and design something you steward with others.

I started writing this as part love letter to open source, but more so to the ODK team and community. I appreciate you all 💙

Although I am moving on from ODK, I am excited to continue applying these learnings in my next chapter, which unsurprisingly will stay within the world of open source 🙂

Also, if you’re a product designer interested in learning more about ODK and open roles, please reach out to yanokwa@getodk.org!

Resources that inspired my thinking over the years 📚

• Design notes on the 2023 Wikipedia redesign
• Working in Public: The Making and Maintenance of Open Source Software by Nadia Asparouhova
• Eriol Fox and their work in open source
• Empire of AI by Karen Hao
• Lost in Work: Escaping Capitalism by Amelia Horgan
• Internet for the People: The Fight for Our Digital Future by Ben Tarnoof
• Glitch Feminism: A Manifesto by Legacy Russell
• The work we need: A 21st Century Imagining by Hilary Cottam
• Power to the Public: The Promise of Public Interest Technology by Tara Dawson McGuinness & Hannah Schank
• Ways of Being: Beyond Human Intelligence by James Bridle
• Inciting Joy: Essays by Ross Gay
• Experiments in Imagining Otherwise by Lola Olufemi
• Mismatch: How Inclusion Shapes Design by Kat Holmes
• Design Justice: Community-Led Practices to Build the Worlds We Need by Sasha Costanza-Chock

Working in the open was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.