Chapter 6 – You Should Learn Some Code

By Trevor Alexander

Everybody should learn to program a computer, because it teaches you how to think.
~Steve Jobs

 

You can hear the usual pushback against this idea immediately:

“But I’m a designer . . .”  It doesn’t matter. Learn some code.

“I want to focus purely on my discipline!” It doesn’t matter. Learn some code.

“I won’t be able to make money from it.” It doesn’t matter. Learn some code.

To be clear: My insistence on learning some code is not to become the modern-day front-end “unicorn” that you often hear described—the designer who can do it all. No, the reason to learn some code is very practical for your career and your working relationships: by doing so, you’ll develop a deep empathy for the developers you’re working with.

Coding will expose you to some of the problems and frustrations that developers face daily:

 

  • Despite the discipline being so firmly rooted in math, often it seems that 1 + 1 doesn’t always equal 2.
  • Adding this component ruins all the others.
  • Changing this CSS causes a conflict with that
  • Some browsers don’t render that well.
  • This interaction breaks all the others.
  • Yep, there’s more . . . but I’ll stop here.

 

If you go through the exercise of coding and building something yourself, you’ll get to feel these frustrations firsthand. This experience can help shape your appreciation for your developer coworkers and even improve your design process.

Next time you’re working with a developer and they say that a seemingly “tiny” change will take a great effort, you’ll be able to appreciate the truth in that statement. Conversely, the more code you learn, the sharper you’ll become at detecting laziness or simple resistance and can, therefore, accurately assist with troubleshooting.

This new empathy can help fuel your desire for compromise as you come up with new solutions that cut the amount of work in half and improve the output.

There is very little value in a stunningly beautiful design that is utterly infeasible to actually build. It represents a waste of a designer’s time who spent all those hours crafting something that can’t be built. Worse, it can turn into a terrible waste of a developer’s time if it’s pushed through and they need to move mountains to implement it.

You’ll have an ability to craft designs that are immediately more feasible, reasonable, and loved not just by your users but your fellow teammates as well.

What can’t be overstated about this approach is the trust and camaraderie it builds with your teammates. To be seen as a designer who understands and appreciates the challenges of a developer puts you in a highly valuable circle of trust.

What’s more, if you conduct yourself in this way, then when it comes time to push for a difficult solution or layout, you’ll have developers on your side. As opposed to before—where you were simply a designer who made unreasonable demands—your teammates now know that you understand them. They know you appreciate the difficulties of their work and would only be pushing a particularly difficult solution because it really is important.

Learning some code will unlock a new appreciation for how the solution gets built. An appreciation for the coding work itself, for the teammates who put it together, and for how your work as a designer has an impact on both.

Learn some code.

 

What I’m Not Saying

  • Become a developer.
  • Accept bad design to make the coding easier.
  • Don’t fight for difficult implementations when it’s truly meaningful.

 

What I Am Saying:

  • Understand what goes into coding your designs.
  • Learn some basic coding to expand your understanding of implementation challenges.
  • Empathize with developers and their role in creating your design.
  • Understand how to design while thinking how it may actually get built.