On Design and Execution

Recently, I have realized that my responsibilities as a designer are to deliver the best product possible, while making decisions that are driven by data and feedback, rather than opinions. Who are you really if you accept “feedback” as an order? At that point are you still a “designer”?

This realization came about from working in a startup environment (Feb 2013) where my opinions were not valued and I was seen as someone that just turned wireframes into pretty pixels and code. By the end of the contract job, I was incredibly frustrated because I didn’t yet have the vocabulary and know how to get my points across in a way that the non-technical co-founders could understand. They didn’t value UX, or feedback from users. They just wanted me to accept mockups that they created for what they were and execute on them. And being so mad the whole time made me see that’s not the person I want to be. And that it wasn’t the right way to manage designers (on their part).

I’ll gladly sit and work with you to solve a problem through design, but I won’t do whatever you say for the sake of your opinion. The fact that you “hired me” means nothing against my practical experience in doing my job.

If you hire me to do a job, I expect that you’ll trust me to do it the right way. It’s not even a matter of questioning my decision making - it’s more of a “I know better than to let you tell me what to do for the sake of your product”.

“You” generally refers to a hiring party and/or one that is not a designer or developer.

“Nicole, but I know what’s best for my business!”

I’m passionate about what I do, and that means that I have the best interest of your product and company in mind. As a part of the company, you are a super-user of the product, whereas your users generally are not. We should be designing for them, not for you.

Back to all the things!