Designing in the Open
Open Source is famous in the tech ecosystem as a way to freely access and collaborate on a piece of software development. It also brings its very own sets of challenges, especially when it comes to design and product management.
I wrote a similar article on Design for an Open Source ecosystem a few years ago. This time, I have decided to dig deeper into this vast topic after a few years spent crafting Strapi.
1. Decoding Open-Source Practices
GitHub: The Core Hub
Embarking on the Open Source boat requires mastering the Git system, whether your company uses GitHub or GitLab.
While it may seem secondary, it is, in fact, a priority as everything begins there: from cloning the project to testing new features through various branches in the terminal. In other words, you will need to know how to use Git and a terminal from the very moment you decide to use Open Source products.
As a designer, I don’t think you need to become a Git expert. Basics are way enough. I know the unknown can sound scary but within an hour of your time, some great tutorials on YouTube could teach the way through!
Dual Nature of Targets
Open Source products exhibit a duality in targeting both technical and non-technical users. That’s how you realize that even non-technical users require a basic understanding to launch the product. Thus, it introduces a significant shift in interaction dynamics.
While a large ‘Get started’ button on a landing page might suffice in the Software as a Service (SaaS) world as a product test incentive, Open Source often demands lines of code for project installation. If someone doesn’t know how or where to add this line of code, this person will require help at some point.
Minimizing post-launch frictions becomes crucial to facilitate user adoption. Creativity is key: a good demo video, installation info, attractive UI, … are all ideas worth trying.
There are, of course, other ways to attract users however, they might require more internal work. An easy installation process offering dummy data for quick testing, or adopting the “live demo” method with a pre-curated test website, could also become strategies.
2. Running Discovery
User research in Open Source demands a different approach. The need to be more frugal in the research and yet relevant enough is crucial. Managing analytics in Open Source is more complex than in SaaS, requiring a delicate balance between data collection and privacy considerations.
From my experience, leveraging the community with surveys, utilizing verbal research, social media, prospecting, and blueprints to identify user sources have proven to be reliable methods.
But don’t get me wrong, capitalizing only on one type of data shouldn’t be the way to go. Qualitative and Quantitative data are both a must-have.
3. Advocating Product Culture
Beyond Open Source, advocating product culture across all organization departments creates a beneficial synergy.
Sharing methods on how to hunt for the right feedback can foster a holistic understanding of user needs. As mentioned right before, information can be frugal so any small detail is worth noting down and shared with the team developing the product.
For instance, we could imagine sharing tips on how to be less biased while asking for feedback, how to ask prospects what would be their absolute ideal solution, or even noting down any features’ elements mentioned during a call.
4. The Power of Community
Informed Transparency
Transparency within the Open Source community is crucial, yet protecting certain aspects of the roadmap and workspace is equally important. While you can share what will be developed next, maybe it’s worth keeping the actual designs private until the scoping phase is not completely achieved. Again, don’t get me wrong, it’s great to be transparent about what’s coming however it wouldn’t be beneficial to anyone to create too high expectations either sometimes. One would rather see a user satisfied with a feature release than be disappointed by the lack of flexibility that was not initially planned.
Regular calls with the community, Requests for Comments (RFC), and other forms of open participation strike a balance between transparency and preserving project integrity.
Active Collaboration
The Open Source community is an absolute valuable resource, providing so much support in many various forms! Surveys, user interviews, constructive criticism, … All fuel the project’s evolution.
Be actively prepared for discussions with users: mention your context and objectives. Get also ready to manage expectations on both sides. While things seem very obvious to you, anyone outside a project will lack information and broader perspectives.
That being said, you should never take any of this for granted. We are talking about strangers on the Internet who are dedicating their personal time to you and your project. It’s not anyone’s obligation to help you. Please, make the best out of it.
In conclusion, designing for Open Source goes beyond visual aesthetics. It is an immersion into a culture where collaboration, transparency, and ethics are fundamental values. By understanding these codes (no pun intended), designers can also contribute to creating great experiences in this famous ecosystem and resonate within it.
___
Get in touch with me! 🌸
