Defending your design decisions

Back when I was in ad school, every Friday our class would critique the work we did for the week. It was more so of a slaughter fest by the professor, really. We’d pin our work up on the wall with a spotlight on each piece. The professor would walk by everyone’s work and make comments and ask questions, “Why did you do this?”, “What does this mean?”. It was rather nerve racking, I’m not gonna lie. She eventually got to my design (in which I don’t remember exactly what it was) and scanned through the copy. “Who did this?” she called out. I answered back while straightening up off my chair (she required us to stand as our work was critiqued). She had asked why I did something the way I did and the response I gave was one I promised to myself I would never do again for as long as I was designing. I gave her the simple answer “I thought it looked cool”. That’s it. No other reasoning, I just thought “it looked cool”. I got the shellacking of a lifetime and it’s something I will never forget as long as I am in this field.

I won’t get into the details of the trouncing I received that Friday night, but I will say that I did learn something. Over the years after that, I taught myself to have a solid reasoning behind every design decision I made. Why did I use this color scheme? Why did I use a sans serif font as opposed to a serif? On that note, I feel as a designer matures, they gradually come to a realization that they are not being paid to be artists and 99 percent of the time they are building for people, not themselves. They learn the art of emotionally detaching themselves from their work, knowing that the first concept they design will change 15 more times and will look nothing like the first concept they started off with. They know that it will be critiqued and constantly prodded at by PM’s, developers, their boss and their users.

So now it brings me to this very important tip – learn how to defend your design decisions. How do you do this? You’re the designer, you should have more experience than anyone (hopefully) with common patterns, guidelines, and past experiences of what works and what doesn’t. When I design applications, I keep in the back of my head the reasons for each design decision I make because later on down the road someone will question it. I found that an important skill to pick up as a designer is to be able to back your decisions with either solid metrics/statistics, results from testing, or past experiences and be able to clearly communicate this across to others. You never want to be in a situation when you’re questioned about something you did and not have a solid reason as to why you did it or not have any answer at all. It’s not fun being that unprepared, trust me.