Open Source & Designers
Why Don’t They join in it?
Open Source Design is a hot topic today. Since Ideo launched the OpenIdeo platform in 2010, it has been applied in many projects and situations. Though many people talk about the importance of Open Source Design, however, designers rarely opt to use it and it is even rarer to find it successfully applied.
It’s not just a learning problem.
The most compelling reason I’ve found to not join the Open Source movement is that it’s not useful. Design skills are not transferable in online collaborations.
Where a developer can easily understand how to write a piece of code in a more effective way or how to fix a bug, a designer needs to discuss (with the mates) the reasons behind a design choice. Design discipline is strictly related to art, psychology, usability, and many other “non-mathematical” disciplines that rely on interpretation and point-of-view.
With no learning promises, Open Source projects aren’t attractive to young designers, and I assume they prefer to invest their time in some solo project for their portfolio showcase or some viral content, like graphic freebies. However, this obstacle for young designers isn’t one for experienced designers who no longer need as much learning or sharpening of their skills. There is a bigger fear for experienced designers though (mentioned by @Una as the “Ownership Problem”). This obstacle is the real reason designers are distancing themselves from Open Source projects:
Designers fear that the final product will not meet the their own standards of quality.
Around the world, inside design studios and departments, this inconsistency is solved with a clear hierarchy in the team. This hierarchy defines the direction of the project and ensures coherence during all the design phases; it defines a single quality standard.
The design process follows it’s own patterns.
Since creative processes are always better when they are collaborative, it could sound odd that it is hard for designers to collaborate in a team without a clear hierarchy, but if we consider the basic design workflow, we can notice how open collaboration doesn’t happen in the same way during the whole process.
Different studios call it by different names (Design Council calls it Double Diamond, Ideo calls it the Five Step Method, some others call it Funnel, etc.), but the core processes and approach are the same and if we section the whole design workflow into 3 different points, this is what we find.
- Phase 1: the concept generation. This is the home of tools, like brainstorming and post-it boards, which help the team discuss the project at a very early stage. The output here is a great amount of sketches, notes, and ideas, which usually flow into a concept. In this phase, creative contamination occurs, and it is probably the most open and collaborative phase.
- Phase 2: the concept definition. Once the main direction is settled, further activities need to happen to figure out the specifications, the styles, and the feasibility of the project. These kinds of activities are usually better conducted in a structured and specialized team with a minor level of open collaboration.
- Phase 3: the delivery. This phase is the most operative; the concept is developed into a real product primarily through the use of technical skills. The work is divided into tasks and assigned.
My proposition for a better approach.
Given the complexity of the workflow and the different phases in a design project, there are some guidelines we should consider when we involve designers in an Open Source project.
1 - Push for structured teams.
Design isn’t just an attempt of random ideas; it’s a process, and as process it needs a structured team with a workflow. Good design teams always have a design director or a head of design to make strategic decisions and guarantee global coherence and standard quality.
We should make sure the design team takes an organizational model where strategic decisions are discussed and token and a clear design process is applied.
2 - Allow different tools for creation and discussions.
Be aware which designers use different tools than developers. It’s undeniable that Git is the center of gravity in the Open Source world, but it was born as a developer’s tool: it usually sets a barrier for the not developers, and, of course, it can’t suite all the designer’s needs in the first phase of the design process.
There are many other free collaborative tools we can place side by side with Git. Trello, Slack, and Dropbox are all examples of tools which make possible to organize the workflow, to elaborate concepts, and to discuss decisions in a more design-friendly way.
3 - Do it from the beginning.
If you try to engage Designers just for some interface components or graphic restyling after the project is already on its way, they will probably not respond to the call, because they can’t guarantee their personal quality standard, and they will not find a good reason to only work on a single component of the project. Design is only “good design” when it’s coherent and cohesive.
Engaging designers just for small parts of the project or for a final restyling is also wrong for the method: a good design project isn’t just visual; it involves research and discussion activities before starting with visual proposals. As design thinking has taught to the world during the last ten years, it’s impossible to make meaningful design without a big picture of the project. Without the big picture, it is just a style exercise.
PS: I’ll experiment very soon with an Open Source Design Project on GithHub. Follow me on Twitter if interested.