Designing for an open-source ecosystem

NB: This article is about being an open-source project that has full-time internal product designers working for it. Having to request the community's help for designing open-source software is another subject we could talk about in another article if you are interested in.

Let's dig a bit into that wide topic to make it clearer for our fellow non-tech people:

According to Wikipedia, the open-source model definition is: "a decentralized software development model that encourages open collaboration. A main principle of open-source software development is peer production, with products such as source code, blueprints, and documentation freely available to the public."

It's not very renown in the designers community that Open-Source projects can also have design or enhancement related issues. Contributing for designers is by so, not that common and in the public mind, related to developers only.

Unfortunately, the open-source community suffers from a recurring cliché: open-source is really dev-oriented and focusing more on getting something that actually works than having something design-oriented (even though design is not just about having a great color palette but that's another subject). The activity is based on repositories like on GitHub or GitLab platforms which are related to developer’s workflow more than designer’s one (except if you use Abstract).

Design for development

Don't be scared to give and share with other people.

Determine what you are designing for.

Are the developers you are designing for going to use your designs for a personal project? Do they want customers to use the product? Is it for daily work? These are all questions that need to be answered before starting anything. Determine why you are doing it and what the community expects. If your end-user is a non-tech person then you might think twice about the wording or the workflows you will inject into your project. For instance, at Strapi, we know that our Settings section targets tech users (such as developers) while our content management system is more dedicated to content editors.

Get ready to be a part of something greater than you.

So if you usually like to keep control of your design, or working on a product by yourself, and being the leader of it, you might be a bit challenged at first. Be ready to accept feedback and marks of interest: you're not designing only for yourself or your project but also for other people's. Your community will also use it so they will be happy to give you feedback about how it can be improved. Keep in mind that you are sharing your design work for others to modify and use it.

Don’t make it super personal or super subjective.

You do not only design for you or your very own project. It needs to be used by anyone at any time. Think of your designs as if you were an IKEA designer: the reflection behind is to make everything adaptive enough to use different materials for different furniture. Same goes for your designs: they should be adaptable and have enough flexibility to be twisted to fit your users’ needs.

Thinking the Lego's way

At Strapi, we are currently working on our own design system setup. Our objectives are not only to simplify our internal workflows but also developers' life while wanting to contribute to the Strapi project and create their plugins. In fact, this is all about thinking of a clear, intelligible interface not only easily usable by other people but also reusable and customizable by them. Be sure to combine that with great documentation and you will (almost) be fine.

Community & Product

What you give, you will receive twofold.

Design it and let it go with the flow

One of the funniest but also most terrifying aspects of designing for open-source is knowing you'll design one thing but will probably never see it ever again. You need to be absolutely sure everything you give is clear, finalized, and always assume it can be used in ways you may not have considered. Wish a long and peaceful life to your asset.

Getting insights is much easier

Open-source also means being lucky enough to have a whole supportive community behind you. We will never be grateful enough to our community at Strapi. Thanks to them we can sometimes start working on new features with more than 800 insights. That's huge.

Now, our mission is to always make sure the needs of this community - that took the time to give us their feedback and insights - are satisfied the best way possible.

Get ready for the unexpected

While having an eye on the technical difficulties, technical debt and the roadmap, issues will pop randomly. Make sure you always take the time to fix them, they are precious and will guide you to optimize the experience your users have with your product. Organisation is key to treat everything by order of priority.

Use feedback efficiently

Your community of users are expecting you to ship what they need the fastest possible, so obviously you never want to disappoint them. On another side, you always need to take the time to test your mockups, challenge your initial ideas to keep a high level of quality and consistency in your product design. To be fast doesn’t always mean that you’ll be efficient. The faster you try to do something, the more likely you are to make mistakes that make you take longer than it would, had you planned it. To get help, don't hesitate to ask for your community's advice, you would be surprised to see how people are often happy to give a hand to help.

In conclusion, open-source might be an underrated field by a lot of designers even unknown for some of them. There is a lot to dig into, no matter if you’re junior or senior. When you are giving your time to contribute to open-source you will quickly be addicted to the challenges it can bring.

If you want to get started, feel free to say hi here.