He who is closest to trunk will inevitably take matters into his own hands.
Any designer working with software engineers has run into the situation where a developer suddenly puts on a design hat. There are numerous valid reasons why this happens. It can go horribly wrong, but you can make it go brilliantly.
At Atlassian, the developers outnumber the design team 25–1. We have a strong Developer on Testing initiative and a famous Developer on Support rotation. Both programs make us stronger in the areas of QA and support.
To truly become a design led organization, we asked ourselves: why not Developer on Design?
There were two possible outcomes of introducing this as a developer rotation: a) the devs would realise that interaction design is often incredibly gnarly and leave us to it, or b) we’d discover some formidable and natural design talent from within our development team. We considered both outcomes a victory, and that is exactly what we got.
In this talk I will show you:
- The two-week program that we wrote for the Developer on Design secondment, and walk you through how to write your own program.
- How we selected our candidates, and more importantly: why we turned others down.
- A blow-by-blow of the rotation itself: How we condensed a tertiary design education into a fortnight. What did we leave in? What did we leave out?
- How it scaled: From short workshops to intensive month-long secondments on the design team where they actually had to do design work on their own product.
- The tools: Which wireframing and high-fidelity design software we taught them and which ones they found easiest to learn.
- What WE learned from our developers.
