Open source has been amazingly good at solving two sets of issues: 1) infrastructure and 2) developer tools. This is because those developers and users are basically the same people—the developer is an "insider" to the problem, understands it well, and is motivated to solve it. Hence, open source has worked extremely effectively using the "itch-to-scratch" model Eric Raymond discussed in his seminal work, The Cathedral and the Bazaar.
However, open source has not performed well in the user-facing space, meaning software where the primary users are not developers or technicians. Consider that the internet runs on free software, but most desktop applications and platforms in the web space are closed. Where we need GUIs, we have largely failed. I think that's because the user is not the same as the developer; the developer is an outsider to the problem and is developing a solution for someone else.
I believe that instead, we should be developing with the user, not for the user. We need the insider perspective to help us build open source products that kill the proprietary competition in the space. We need to bring users into the center of the solutions model when developing user-facing products.
So, what might this look like? I have developed a 1.0 version of a methodology based on my thoughts around this, but the further I progress down this path, the more I understand that there is no single answer. We need to experiment with processes to learn what does and doesn't work and iterate our models forward.
A simple framework for experimentation
We need to have a simple framework to bring in user perspectives within which we can experiment. Even though open source projects share a lot culturally, each one has its own ways of doing things, its own internal culture, and different thresholds for experimentation. So, rather than push any specific method, I'm starting a small campaign that asks you to consider this theory that user input is important to the efficacy of open source to produce world-beating user-facing products.
If you think there is something to this, consider doing some experiments with your project which move, in some small or large way, toward these two principles:
1. Design first, and
2. Design with the user
Combining these two principles draws the user (the "insider" to the problem) closer to the center of the project and our solutions culture. The "design first" emphasis is really a call to consider the insider's position before we start developing.
These principles are not a doctrine, rather they are navigation tools for solving the longstanding problem of how to build better products the "open source way." I don't think we will discover the happy path to solving this problem overnight, but I do think if we start some small experiments within the comfort zone of new or existing projects, we will start learning what does and doesn't work for solving users' problems with our software.
What does this look like?
Here are some suggestions to start trying some things out. The strategies vary from the mild to the ambitious. They are intended to help you understand how users perceive your product and to start working with them to improve it. Think about the ones that would sit best with your project and try them out.
1. Reach out
Pick one or two people in your community who are users (and not developers), and ask them for a quick chat. Call them up (voice or video chat will give you richer results than IRC or text chat for this kind of conversation) and ask them their opinion of your software. Ask them what they like and what they would change. Don't worry that this is a limited sample; the point is to start opening conversations and listening to your non-developer users. The bonus is that this is also good for building community.
2. Meet up
Consider hosting a meetup (online or in person) of non-developer users to discuss the software. Start by asking very open-ended questions like, "Does the software do what you need?" or "What do you think the software doesn't understand about what you do?" Sit back and listen. Try not to explain why the software does what it does. The aim is similar to the strategy above—listen for insights about what your users need or that don't align with your previous thinking. This strategy is also good for building community.
3. Tap the doc writers
In my experience, people who contribute to user documentation are more likely to be advanced users, not developers. These people are a great source for insights, because they are often domain experts and understand your software well. Tap into this resource to gain insights about how your software could be improved. Reach out to them for one-to-one or group chats; you will probably be amazed at the sophisticated insights they can offer.
4. Host documentation events alongside dev events
If you have a large volunteer documentation effort, invite the doc writers to any code events (e.g., sprints, hackathons, etc.) you hold. This may start casual connections between the doc writers and the developers, which is great on its own. But, if you can, try pushing this further. For example, try hosting an open discussion over lunch or in a blocked-out session, and ask the documentation teams how the software can be improved. As with the meetup, ask open-ended questions like, "What do you think the software doesn't understand about your work?" or "What could the software do differently?" You are looking not just for feature suggestions, but to start understanding the position of the expert, non-developer user.
5. Map users' typical workflows
Select a few users to help you understand how your product fits into their workflow. You'll want to interpret workflow very broadly; essentially you want to learn more about how they are using your product. By mapping out what the user does and how they use the software, you can get some very interesting insights into ways you might improve it. Treat this as a conversation; if you're doing it in person or over video chat, ask them to whiteboard their workflow. Document it and ask them a lot of clarifying questions—the more nuanced the questions, the richer your learnings.
6. Invite users to select dev calls
Invite one or two users to certain dev calls, such as when you start deciding what new or updated features to prioritize. If you want strong feedback from non-developer users, don't rely on tools like GitHub or the GitLab Issues board for these discussions. These types of tools are OK for developers, but non-technical people don't find them very easy to use. Instead, consider using online video chat, an in-person meetup, or a similar forum. You will likely need to play a stronger role in facilitating the discussion. Keep the conversation "out of the weeds" and make it fun and engaging. Make sure you invite the users into the discussion and find appropriate ways to ensure they contribute. (This may take some experimentation.) Be sure that your users are heard and their suggestions aren't instantly overridden by explanations of "why X isn't possible" or "hasn't been done before."
7. Invite users to design calls
When you are planning feature designs, reach out to select users and ask them to contribute to the discussion. Once again, it's more effective to do this as a real-time group conversation (in person or by video chat) with users and developers than via repository issues. You will need to facilitate these conversations; make them quick, fun, and engaging.
Share what you learn
I believe that if we share what we learn, as the open source community has done every step of the way for the last two-and-a-half decades, we will solve the problem of creating popular user-facing software. If you try some of these strategies, please share what you learn so we can all benefit from what you discover.
Adam recently presented these ideas at CSVConf in Portland, Oregon. Watch the video of his presentation. And many thanks to Tony Wasserman for the interesting discussion they had on this topic.
Comments are closed.