Design is a visual and and structural (»organizing«) activity. But for those who design software and websites there is a non-visual world that needs to be navigated and taken into account – text in the form of program code and comments. In addition, text is the predominant mean of creating and collaborating on software in particular and on web projects in general.
This has historical and technical reasons: For computers, text is more efficiently processed and transmitted than images and computer programs are usually created in text-based code [1]. However, the text based tools and culture of creation and collaboration have severe drawbacks for designers who are part of the creation of software (like UX-, Interface-, Service-Designers etc.). This is particularly relevant in the open source community, where many collaborators (among them potentially designers) work jointly to create and improve software.
The case against designing in code
There is no shortage of pleas and instructions for designers to learn to code. I argue that for the sake of better design, it makes few sense to do this work in code (at least for most designers).
To use code as a tool for design and do ideation, communication and adjustments is a process that creates a lot of friction. It demands a constant switching between the definition space – the code – and the outcome – the resulting appearance and structure.
Empirical research shows that feedback loops play a crucial role in creative tasks [1]. For designers, this is evaluating how a preliminary design looks, is structured or behaves and to do changes to this and than see again if the result is satisfying [2]. Look at sketching: You can quickly draw how a product or a website may look like. You evaluate what is good or bad about the drawing, think it through and do changes again. The feedback is instant; if you slip and the crooked line messes up the design you see it right away. If the slip actually adds something good, you see it too.
Thus, there is a lot to loose if one designs in code.
So: should designer ditch the resolution to learn to code? No. They should. There are things that are best expressed in code, maybe a gesture or a new kind of menu. As well it will enable you to communicate your ideas to programmers and to estimate the technical difficulties. But while design-in-code is touted to be THE skill for (web) designers it will come with losses that concern core parts of thinking and process of many designers.
So rather than learning to code for designing, you may be better of keeping design visual and learn programming for the communication and realization of the design.
Collaboration: Text based tools are not silver bullets (but golden hammers)
There are many well established means to communicate in (Open Source) Software projects: Mailinglists, IRC, Bugtracker and Git, an immensely popular version control system. Particularly for git, you will find many pleas online that designers should use for version control and collaboration. In addition, there is few choice anyway if one wants to contribute to an open source project.
But while tools like Git and IRC are well established, they pose some problems to their use in design. These tools are mainly text based. This means that visual assets need to be somehow linked or embedded. They are not first class citizens.
Communicating about layouts, icons or workflows is possible, but tedious. Images often need to be uploaded and linked. When talking about them, images need to be referenced by some ad-hoc-system, parts of the image need to be described to refer to them. But the text-space is a weak substitute for the visual space the design happens in. A long winded, cumbersome communication is the result and ambiguities arise. This contributes to the lack of participation and acceptance of designers in open source projects and contributes to the view that designing together is hard and possible done best by the lone genius anyway.
To enable designers to contribute to open projects it is not enough that they learn about code and technology: they need tools that match their workflow and enable the to collaborate with programmers. Just telling them to adapt is not a sustainable solution.
NOTES:
This Text was originally published on opensourcedesign.net
[1] There are some alternatives like Scratch or PureData, which use an diagrammatic approach to programming; however these exist in their niches: Education and Audio/Video processing, respectively.
SOURCES: [2] Designing as reflective conversation with the materials of a design situation, Donald Schön, 1992 [3] »sketching provides a temporary, external store for tentative ideas, and supports the ‘dialogue’ that the designer has between problem and solution.« (Chapter 1, ›Design Ability‹) »…Drawing…gives the flexibility to shift levels of detail instantaneously; allows partial, different views at different levels of detail to be developed side by side« (Chapter 4, ›How Designers Think‹) in Design Thinking – Understanding how designers think and work. Nigel Cross, 2011