I think designers should code, but they shouldn’t feel pressured to have to contribute production code. That said, there is a ton of value that you can add by building up the skills to push production level work.

I often get asked how I got into writing code as a product designer. The path I took to becoming a “designer who codes” isn’t unique to me, but I think it would be useful to share for those who want to get more into incorporating coding into their work.

Crawling

Like many growing up in the 90s, I started coding with simple websites. We’re talking wacky GeoCities websites and blinged out MySpace homepages. From that, I started getting into making more dynamic websites backed with CMSs.

I actually started with a system called CuteNews because it didn’t require a database, an area which I didn’t know much about at the time. it’s nice to see that it still exists to this day! I then went to learn more and more PHP and got into Drupal (which I absolutely despised) and WordPress.

At the same time, I continued to push more on my UI skills by developing a keen sense for CSS and HTML. CSS was evolving very quickly and I found that many couldn’t or didn’t want to take on the effort to produce good CSS. Around this time, I was a poor college student and took on a lot of “PSD to HTML” jobs to make some money on the side.

At the end of this stage, I was an expert at HTML and CSS and had a good enough grasp of PHP to be productive with building custom functionality in WordPress.

Walking

Fresh out of college, I started working in tech and discovered the joy of prototyping. By now, HTML5 and CSS3 were becoming big and I continued to learn and develop my skills in that area even though most of my day was spent in Photoshop. However, I felt that I had a gap in my skills. How was I supposed to add that interactive component to my work? The answer was JavaScript.

JavaScript was a bit of a mess back then. Inconsistent browser support meant that I was more often than not using libraries like MooTools or jQuery. But it got me to a place where I could add interactivity to the things I was building.

Around this time, I was also learning more about the command line. Version control like Subversion and Git. As well as tools like ssh, scp, and vim. Small things that helped me do my job or collaborate with peers.

By this point, I was building out more interactive prototypes to demonstrate my ideas and often would give instructions to the engineers I worked with on how to implement designs.

Running

As I began to work more and more with engineers, it became clear that many leaned more backend despite being labeled full-stack. This often made it difficult to fully realize the designs I was pitching. In order to help bridge this design ↔️ execution gap, I began to look towards working more closely with real product code. At the time, model view controller (MVC) frameworks like Backbone.js and Ember were at the forefront of reactive web applications so that’s what I began to weave into my prototyping.

I started to get more and more confident with building out larger scale prototypes and set out to prototype directly in the codebase. This entailed learning tooling like Grunt, Gulp, and Webpack to understand how things were stitched together.

Eventually, Angular.js came onto the scene and really acted as an unlock for me on how to interleave data into my prototypes. I started to learn more about Node.js and building APIs with Express as well as leveraging database connectivity.

Even though Angular.js touched on this, it wasn’t until I started using React that component driven applications really landed with me. At the same time, this paralleled the evolution of component driven design and the focus on design systems in the product design world which was very timely.

I also started to educate myself on software engineering practices like testing, CI/CD, and code reviews so that I could plug more seamlessly into the engineering organization’s processes.

By now, I was building prototypes directly in the codebase and was comfortable enough to ship full on features to production. My collaboration points with engineers were no longer pure hand-off or presentations, but rather code artifacts and reviews.

Small steps, big impact

The way I got started was learning how to make things look the way I had designed them. These days, it’s probably not enough to fully contribute to production because of the layers we add upon styling modern web apps. However, the language (so to speak) is the same.

Next, you can begin to layer in more interactivity with JavaScript like adding simple event handlers to accomplish things that you can’t with pure CSS. Then look into getting closer to your organization’s technology stack. What tooling is being used? What backend technologies? Learn the processes and steps to check out the codebase. Ask engineers to add you to code reviews so you can learn how things are built (and hopefully catch issues before they ship 😜).

While it is probably more sound to start with foundational knowledge like most software engineers go through, I often find that getting to something real can be so much more impactful and psychologically fulfilling and thus more compelling for learners to continue their journey. In short, do what works best for you.

Before you know it, you’ll develop a better shared language to communicate with engineering partners. You’ll gain more rapport with them. What you ship will be higher quality and get out the door faster. And best of all you’ll feel more satisfied with bringing things across the line end-to-end.

All of this takes time and effort, but it’ll be worth it. Remember, small steps.