Designer vs. Developer? A FLOSS perspective.
Friday, March 18th, 2011 by Björn BalazsThe relationship of developers and designers is full of misunderstandings. Projects fail, e. g. due to the struggle among different views on the same subject. Communication can be frustrating for both sides. But there is hope. In this article I want to share and discuss factors that facilitate a ‘Designer with Developer’ rather than a ‘Designer vs. Developer’ in FLOSS projects.
Background
You need to know that I am a psychologist. I see myself rather as a designer than a developer, because I do not actually write code. But I also do not do graphic-design. My approach to design is not to create pretty pictures – it is to understand people and design solutions for their needs.
My company Apliki is intentionally called “Psychological IT Consultancy”. In our work we build the necessary foundations for projects and bridge the gap among the different worlds in a project (developer and designer are not the only relevant groups in a project – e. g. understanding the user is another central part of our work). In my non-commercial FLOSS work for OpenUsability.org I do the same. After more than ten years in the business I have worked with very different people and projects.
Recently there have been some discussions on the LibreOffice Design mailing list about the rights and duties of developers and designers. I actually do not want to contribute anything specific to this discussion. It is already valuable and fruitful but sometimes I need external impulses to do something I wanted to do for a long time: share my experiences about factors that facilitate good cooperation in projects especially from the design perspective and hence lead to successful and satisfying projects.
So here we go:
1. Respect
Successful projects are based on respect between developers and designers. They show respect by taking time to talk to one another and explain their ideas.
Often designers will say something like: “This solution has the better usability”. Developers tend to answer: “But it is too expensive to code”. This kind of conversation is the best starting point to build up an oppositional feeling in a project – and I have seen many good ideas failing this way.
My grandfather sometimes says: “You didn’t experience war so you cannot understand it”. This always upsets me. I do understand a lot of things, but my dialogue partner needs to take the time to explain them to me. Taking time shows respect and helps establishing mutual trust.
2. Reasons
In a successful project developers and designers explain why something is better or more expensive, and take the time needed to address the objections of one another.
Giving a good reason is not easy. Neither hierarchical position (or the FLOSS equivalent ‘length of contribution to the project’) nor a vote (“5 out of 8 think this is good”) are good reasons. In Non-Free projects they are more likely to be accepted, but in FLOSS projects most people invest free time. There is a psychological concept called cognitive dissonance. It helps to understand why people volunteering in FLOSS projects need not only good, but excellent reasons to continue with their involvement (Because they have to self-justify their involvement all the time).
The worst, but still often heard reason is, of course, extortion: “If you do not accept this, I will stop my contribution”. The fact that it is still heard quite often, shows how tiring it is to discuss the relevant issues. Especially in FLOSS projects, where non-native speaker discuss mainly via mail, chat or the like.
3. Foundations
In successful projects design is understood as an engineering discipline, with a common and clearly articulated set of values for all relevant parameters. This sets the frame for the optimization of interfaces.
To be able to address objections, a team needs a common understanding. In my experience, developers are much more sophisticated in this matter than designers. Programmers tend to make fundamental decisions very early. They agree on technical frameworks, architecture of the software, code repositories and so on. This allows them to provide good reasons why, for example, something is expensive to do. This usually leads to the situation that different developers will provide similar answers for a question (as long as this question is technical).
The situation in design could not be any more different from that. Discussions occur about even the smallest issues. This is partially due to everyone being an expert when it comes to using things (see Parkinson’s Law of Triviality for some interesting thoughts on that). But the main reason is that the common ground is missing.
Interface design is often misunderstood as an art. While it definitely has artistic aspects, it mainly stays an engineering discipline. Unfortunately most people working on interfaces think they are doing arts. The problem is immediately evident: Art may be interpreted, but never needs to be justified. And this is where the arts approach to interfaces almost surely fails. If various people work on the same interface, they will need to justify what they do, convince others why their ideas are so great and so on. The more people, with a variety of backgrounds, are involved into this process the more problems will occur.
The only solution is to focus on the engineering aspects of interface design. Engineering is the opposite of art. All it does is:
- Find out all the parameters that are relevant,
- try to find reasonable values for them, and
- iteratively optimize the solution within the given parameters.
This looks like a very boring approach for most people working in design, and it is hence very hard to establish. In the end it is the only way to lay the foundations on top of which problems can be solved. Additionally it is very close to the developer’s thinking and eases communication among different parties.
4. Trust
In successful projects an aura of trust allows new ideas and new people to grow to the benefit of the project.
Once the foundation for the design work is laid, the team can start to build up trust. Development teams rely on code reviews. Good development teams only check whether the code complies with the common foundations. Even though the more experienced developer will sometimes know more elegant ways of solving a problem, generally any improvement will be accepted. The team shows the trust that all members will learn and accept that they are not perfect yet. They accept that the product is always “in process”.
Again, design teams tend to miss this generosity. As a result of missing explicit foundations, details are discussed in great depth involving a large group of people. Also these discussions often try to find the ultimate, all-time-end-of-discussion solution for a problem (that has not been described in full detail). These discussions can be frustrating, especially for willing new design contributors.
Since usually some sort of interface already exists, an implicit agreement on the foundation exists as well. New contributors therefore either do marginal work or will most likely fail with anything more ambitious. Both ways do not facilitate to build up trust in the new members. The old ones feel responsible for everything. New ideas and fresh personnel has a hard way to get into the project.
5. Communication
In successful projects communication is well structured, facilitates work and does not prevent it.
A potential lack of trust inevitably leads to extended communication. In FLOSS and therefore often voluntary projects people do not find the time to work anymore, because they are stuck in administrative issues (following the different discussions). This is frustrating and will lead to people leaving the project (see concept of cognitive dissonance above).
Also developers are not willing to participate in the debate, or even look at the discussions, because they indeed have better things to do. The gap between design and development increases.
Additionally we should not forget that developers and designers speak different languages. Developers talk about technical issues sometimes with the same words, designer use for describing interactions. Add the fact that people contributing often do not use their mother tongue and the communication chaos is perfect. Astonishing for a psychologist to say, but talking about it is not always the best solution.
6. Facts
In successful FLOSS projects all contributions are welcome (they may be rejected though) and discussion always takes place on the current objective, not on what single people did.
To reduce communication it will be necessary to accept facts. FLOSS development evolves gradually and not always in the shortest linear way. Sometimes things even get worse. This is not really a problem, as such things will get corrected after a while. These faulty developments can also help to clarify the foundations or to show how conclusions can be drawn on them.
It should not be subject of any discussion when someone has done something. Remember, people are spending their spare time. If they have to justify that they have done something they are likely to leave the project (did I mention cognitive dissonance before?). And what is worse? A wrong turn in the project or the loss of a motivated contributor?
7. Structure
In successful projects structure facilitates the cooperation of different disciplines.
The acceptance of facts is a non-commercial FLOSS-only approach. In every commercial project the opposite is true, because in commercial project structures are more natural. FLOSS projects tend to refuse structure with reference to the bazaar. But even on a bazaar not everyone trades everything and there are rules and structure.
Structure prevents turning facts into the wrong direction in the first place. Design has to provide a structure in two ways:
- Contact and support for developers willing to work on a certain topic, and
- a road map of topics the design team considers urgent.
If this structure is provided, development does not need to follow the design team very closely. Points of contact are clearly defined and help getting the work done.
Closing words
Design in FLOSS projects still is in its childhood. Unlike in development, structure is often seen as an opponent to or a restriction of freedom. The opposite is true.
Structure is a necessary enabler of freedom. It enables people to decide into which project they will invest their time. It enables consistency, the prerequisite of any usable or even desirable product. So do not waste your time in discussions about problems – invest it into discussions about a suitable structure for your project.
