Concrete, steel and glass
Yep, another one of those articles. I apologize in advance. But I’m pretty excited. I’ve managed to reframe ‘coding’, as a practical, and more importantly, achievable skill for me to integrate into my design process. This was not how I used to think. So, what happened?
The story so far
To start with, I work as a product designer at a tech company and I have a basic, working knowledge of how web applications are built.
I believe a designer should know the materials their solutions are built with, just like an architect must know the materials used in building a house. The better you understand the problem, the more options one has to deliver the optimal solution.
I’m involved in technical discussions every day. And in any tech business, you’re nearly always talking indirectly about code.
I’m fascinated by the subject. When Paul Ford asked ‘What is code?’, I wanted to know the answer. I literally read that whole thing.
Many op-ed pieces explain why it’s important to code, this article in particular, have been shared and discussed in design/tech circles. I’ve read a lot of them.
O’Reilly recently released a report that suggested designers who code get paid more. “Being able to code, at least a little, would help a UX designer working on web, mobile…and learning how to code a little is probably not a great cost compared to the potential reward.”
Work experience, social proof, money, built an important foundation, but weren’t enough to motivate me. I still ignored code, and didn’t think it was a necessary skill a designer must have.
The tipping point
During a meetup, a designer who had just talked about the importance of building prototypes with code, admitted that the “developers didn’t use our code.”
“The developers didn’t use our code.”
I loved this insight. I loved it so much it changed my mind about everything.
It defined the difference between designers and engineers.
If developers didn’t use their code, that meant it was different, and special. It was designer code! Code that would get laughed at by engineers, but who cares, they’re not going to use it!
The next day, when I explained my revelation with developers, they were visibly excited. Their eyes lit up. “This will make your life so much easier.”
Next Steps
I heard Medium likes insights. Here’s what I’ve learned.
1. Learning, for the sake of learning, is a weak goal. There’s no clear incentives, and you’re mainly relying on your own willpower, which is a finite resource. Instead, align your interest with the business and the needs of your colleagues. It has a much better chance of survival. Since you are focusing on how you can help others, instead of just bettering yourself, you get accountability for free. Devs are happy to help, because you are aligning to their strengths, and the way they already work.
2. Own it, and wrap it in your identity. The story you tell yourself, and the story you tell the world about yourself. When a new habit, or goal falls into that ‘identity’ category for me, it’s like rocket fuel for motivation.
3. Downgrade the white whale to a sardine. I think the mindset shift happened when I thought of code as imperfect, and achievable. Rough and practical, instead of clean and perfect. Who knew that javascript rhino has a soft underbelly.
4. Define your mission. For me, I want to use code to quickly build low fidelity prototypes. That’s it. If I can’t achieve that, what am I even doing this for?
As a designer, I will use whatever tools I have to “render ideas to better understand them”. Paper, whiteboards, sticky notes, sketch mockups stitched together with invision, or some html if need be.
But, more valuable than the deliverables that I hand over, is my way of thinking about problems. Code will not be my only ‘hammer’, and I hope it never is.
