The Arts or the alliance
Tamapotchi note #9
When I was in high school I pictured my future self as a succesful visual Artist; to be able to create whatever I wanted to and call it Art, was a highly appealing prospect for me as a 16-year old. When I was in Art school and realised what it took to be a true Artist, I changed my plans and focussed on becoming a designer. As a designer I might not be able to do whatever I wanted in the name of Art, but to be at the wheel in developing new products was close enough. And I could actually earn a living, which trumped the faith of most that persisted in the pursuit of the finer Arts.
After graduating as a graphic designer I got my first job at an advertising agency. I worked at the multimedia department and mostly created websites for businesses that felt they needed online presence without really knowing why. This was 1998. Among the many things I learned in those first years as a design professional was the fact that the designer doesn’t control the development process. He doesn’t even get to make the important design decisions. At its best he would be presenting the options to the people that choose. I learned that clients, marketing managers, product owners, yes, even software architects and engineers, all seemed to have opinions about design. And their opinions somehow always were decisive. And they would never (ever) pick my personal favourite.
This was not what I signed up for! It seemed impossible to get a real say in the decision making and I started to doubt whether I had what it took to be a designer. What did I know about anything anyway? Disenchanted, I decided to try joining one of the opposite teams; I learned how to write my own code. So I would be able to repel the much-hated “No, that is impossible to build” I often got after presenting a design; I would just build it myself. Of course my technical opponents would (rightfully) criticise the quality of my code, but once the client or product manager had seen my design was technically feasible, they would often convince the techies it had to be built my way. HA!
I had regained some of my artistic freedom by expanding my skill set. Over time my coding improved and I gained some insight into the minds of engineers. I could understand why some design decisions, although brilliant from my designers point-of-view, were a bad idea if you considered the technical implications. And slowly but surely something beautiful started to grow: a mutual respect between me and my engineering colleagues. I was still a designer, but had a much better understanding of the context I was designing in and the opportunities and limitations that came with it. In return, engineers became more open-minded towards my work and ideas.
When some years later my work shifted from web to software design, I used a similar approach when I noticed my freedom was limited by the decisions made during product specification. Specs often left little room for design. So I started to take part in product specification myself. And like before when learning to write code, the experience was enlightening. Taking part in the conception phase of a product made me understand more about the decisions that were taken. Writing down detailed requirements brought up questions that I would have never thought of before. And having a designer participate in spec had its advantages; often I would extrapolate new ideas into a quick sketch. It allowed all involved to discuss and assess the concept more effectively. And consider important design aspects early in the process.
I often read articles about why designers should learn how to code. And I also read articles about why they should absolutely restrict from coding. There is no ‘good’ or ‘bad’ choice. I like to really understand the mind and motivation of the people I work with. Even if they are engineers. Or requirements analysts. Or software testers. It is not about making friends (although that might happen occasionally). It is about learning about product development from other perspectives than design, and considering these in your design work. It might not have made me a better designer, it sure made me a better design professional.
If you’ve read my previous articles, you might be wondering how all this relates to Tamapotchi, my personal mission to create a smart flower pot. I think Tamapotchi is another way for me to explore aspects of product development that I wasn’t able to explore until now. It defines me as a designer. Being a designer is much more a mindset than a skill.