Let me be

your rubber duck

Three simple ideas on how designers and
developers may collaborate

Nowadays it seems everybody is aware that bringing together Designers and Developers is the key for building successful products. You can read about this on numerous platforms and even I’ve written about the importance of involve Developer’s early in the process. But while everybody agrees on the importance of this topic and the indispensability to implement such a collaborative environment, there seems to be a leak of ideas on how to exactly raise the treasure of this hidden potential.

Simply putting a designer and a developer together into a room probably ain’t gonna work. Here are some ideas on methods and strategies to make collaboration the key in creating beautiful and meaningful products.

Pair programming and designing

Working in pairs is a common technique in agile software development. While the driver is constantly writing code, the observer, who is sitting right next to him, is reviewing each line of code and giving strategic directions of the work. I noticed, that teaming up designers and developers in pairs, while a developer’s taking the role of the designers observer and vise versa, can become the magical bullet in your workflow. Sharing deep insights on work strategies, knowledge about feasibility, patterns and general thinking plus having the chance of influencing the outcome will not just lead to a great fellowship between designers and developers but can be seen as a continuous process of learning and education.

Let the other be your rubber duck

Another great strategy that was evolved in software development and can be applied to the collaborative work between designers and developers is the principle of Rubber duck debugging. In short, developers are asked to explain their problem to a rubber duck (yes you heard right) in order to force them thinking out loud. It is quite common that the solution for a problem some times just pops out of nothing, by just explaining yourself to someone else. Taking this technique into our context, will ask designers to explain the challenges they meet to a developer and will ask a developer to invite a designer the next time he is fixing a bug or facing a challenging task. This way both will share insights into the strategy of thinking and problem solving in their specific fields and gather meaningful information that can influence their own way of working.

Stay with what you know but share it

Today I see a lot of designers striving into the fields of development and becoming overwhelmed by the complexity and diversity of techniques, tools and languages. Especially in the fields of User Experience Design, tools like Framer Studio became pretty popular in the design scene. Its flexibility of creating prototypes with Coffeescript (Javascript) earned a lot of compliments but caused lot of frustration for designers who had to write code for the first time in their life. On the other hand, there are developers who struggle hard with creating meaningful transitions in user interfaces or with their responsibility on creating excellent user experience and meet the expectations of designers. The idea is simple but effective: Team up designers and developers whenever they face their own weakness which probably is the strength of the other.

That said, give developers the possibility to demonstrate their strength in coding prototypes and taking care about the code architecture while designers still take the direction of look and feel. Both sooner or later evolve to something that is located between development and design and will unveil the hidden potential.

But no matter which strategy or method you choose, there is one fundamental key to make this a story of success rather then a mess:

It’s treating each other with Respect.

Both, designers and developers put so much more into their work then just time and skills. A good portion of passion, blood, sweat and tears emotionally binds each individual to their work. What is usually a good thing, can turn out to become the deal breaker when it comes to criticism or decision making.

Although both share a lot of commonalities and commitments, there seems to be a thin line between a potentially productive collaboration and a mess of emotions, vanities and bullishness. To make all this work, it is a must that you treat the ideas of each other right. Talk about alternatives instead of labeling other’s work as a fail. Try to see the good things of somebody’s work, I’m pretty sure there is always something hidden, that can be transformed to a new vision. And try to learn as much as possible about the way others are working and let their thinking influence the way you are used to work.