Twenty Years in the Valley
One of the biggest mistakes I’ve made in my career
Should designers in high-tech learn how to code?
It’s a question that has cropped up consistently over the past two decades, creating scores of heated debate at design conferences, as well as on every design website or blog you can find. I’ve also met many a young designer, just getting started in this business, stressing over whether they need to invest time learning HTML+CSS or Java or Objective C or Javascript.
Before I dive into my answer on the question, I’d like to relay a story about what I consider to be one of the biggest mistakes I’ve made in my design career. If I were able to wind back the clock twenty years, this is certainly one of the things I would change. No question. It’s a story I’ve told to numerous designers, and one that I tell young designers with the hope they don’t make the same mistake.
It was Fall of 1995, about a month or so into my new job as the interface designer at Adobe Systems. I was spending a lot of time drawing up feature ideas as a way to get comfortable in my new gig. I started down a path of mocking up what it would look like if Photoshop, Illustrator, and PageMaker (later to become InDesign) shared interface conventions. If you don’t know what those products looked like back then, you can read this article from Design Graphics Magazine out of Australia, featuring yours truly, for a refresher.
Since I was new to the Bay Area and knew only a handful of people, I spent most of my nights and weekends at Adobe HQ in Mountain View, cranking Nine Inch Nails and KMFDM at 11 while drawing and iterating incessantly. One particular weekend, I got to a good spot with my sketches and mockups. I opened up Macromedia Director and did what I had done many times before I joined Adobe. I started putting together a scripted demo of the screenshots come to life using Director and Lingo. I loved making things come alive in Director, and really got into what I could accomplish with simple scripting.
#FunFact: The original version of MYST was scripted and built using HyperCard. #Humblebrag: I was an alpha tester on the original MYST, and was one of the first people to experience the game. And yes, no one spells my name correctly. Story of my life.
I wrote scripts in my Director project so “menus” would open, showing proposed changes to terminology and keyboard shortcuts. I toggled “buttons” on and off and put cursors on the screen to mimic tool selections or palette behaviors. I made it possible to drag a “palette” around on the screen. (These things were often nothing more than rectangles filled with simple text or pixel perfect palette mockups inside them.) I had gotten enough basics and flow working with simple effects that I was about to embark on the process of scripting the tab palettes to mimic the collapse behavior, which only Photoshop had at the time. Basically, I started to make a lightweight prototype, one that did just enough to render my ideas with interaction instead of just static mockups — the equivalent of what some designers do today with Invision or Framer.
To back up even further for a moment, I should note that my design training actually started out in theater. At an early age, I had always intended to get involved with making movies, either as a director or as a production designer. I interned at professional theaters in the late 1980's, and cut my teeth on building and painting sets, hanging lights, and making scale models.
Building models, drawing things to scale, rendering an idea before construction; these were all things that were simply part of the job in production design for putting on a show. I had been trained that before you ever attempt to build anything for production, you first need to draw out your idea, iterate through it, make a scale model of it, iterate some more, then build it and put it through a dry-run before you ever put it in front of a paying audience.
In other words, as far as I’m concerned, iteration and prototyping were never in question as a part of the design process. It still boggles me to this day how some people in tech find this to be some sort of revelation.
Back to that weekend in 1995. I spent a solid 48 hours putting a lot of effort into Lingo scripts so that my mockups could come to life. So for example, rather than present an Excel spreadsheet of proposed menu changes, I could show co-workers interactive menus reorganized with shared product terminology to communicate the design. In fact, it only took me a few hours to put that part of the prototype together, and it forced me to work within the space constraints of screens from that time. If I had made a mistake somewhere or got feedback from the team, I could edit the script easily and rebuild the player in a matter of minutes. Drawing up all the menus for all the products — a task I wound up doing later — took at least three to fours times as long to do. Reworking those screenshots per revision took almost as long as well.
I was quite happy with the beginning of that early prototype. I had pixel perfect mockups, and they were great at communicating the visceral impact of the changes I was proposing. But the prototype communicated the changes an order of magnitude better with interaction, which is exactly what prototypes are supposed to do.
During the following week, I was working in my cubicle when one of the product managers came knocking. This product manager had been with Adobe for a decent amount of time, and they were well liked by most as near as I could tell. I was pretty excited about the prototype work I had immersed myself in, and was more than happy to show them what I was cooking up.
When I clicked on the “menus” and they popped up in the prototype, or when I dragged a “palette” that had proposed content in it — say, the new Character Palette design—their eyes kind of lit up, thinking that I had done a lot of complex coding to get a prototype that looked so real up and running. Being at the company for a very short period at that point, I took their reaction as a sign I was doing the right thing, and I was certainly more than a little proud of myself for that.
But then it happened.
This product manager, while very excited that I was building up this prototype, paused a moment. “Andrei, this is certainly very cool. We’ve never had anyone go to this length to propose any new designs or changes. But I have to wonder… How long did it take you to make it?”
I shrugged. “Not long. Just the weekend and a few days since.”
“Well,” they continued, “while I certainly applaud your effort, I must say that you really don’t need to go to this length. You’ll have to do this all the time for all the products going forward. These screenshots you have here are plenty. It’s all we’ve ever done before, so there’s really no need to spend this kind of time on a prototype.”
Next came the mistake. Like I said, one of the biggest ones I’ve made in my career. It’s burned into my brain as if it happened five minutes ago.
I simply said, “Um… Ok. I guess. If you think so.”
I never built another prototype while working at Adobe again.
I’m not pointing fingers, and certainly don’t blame anyone but myself for this. I could have easily ignored the product manager’s advice and stayed the course with my trained design process and built out my prototype. No one at Adobe ever forced me to work in one particular way, and no one would have stopped me. One of my favorite aspects of the culture there was how everyone was given a lot of room to work in the way that was most effective for them.
However, I did not follow through on making prototypes as part of my job, and it took me quite a bit of time to get back into scripting and coding after that day. I worked for Adobe for five years after that, in the trenches, designing what would become the Creative Suite. I left in the early aughts to take a crack at the web thing, but had let my scripting and coding skills lag heavily. They had been dulled and took another five or so years to get back into even mediocre shape with basic scripting tech. In short, it took about ten years to recover from that day, and I still suffer today from having too many gaps in my coding knowledge base that I have to refill. I can only imagine how much farther along I’d be if I had stayed the course and kept learning and practicing my coding skills while technology evolved over the past twenty years.
Compounding the mistake is knowing now that I had the good fortune to be the first interface designer at Adobe; I could have instilled a culture early on of designers building and prototyping in collaboration with engineering, learning how to code, and how to work with one of the critical materials in our chosen profession. I missed that opportunity, only fully realizing how big of a mistake it was years later.
So, back to the question at hand: Should designers in high-tech learn how to code?
Answer: Absolutely. Especially if you want a career in this profession.
Bonus Answer: HTML+CSS is not coding. It’s basic scripting. Just learn how to do it. It’s easier than learning how to use Sketch or Photoshop quite frankly, especially a full decade or so after web standards have settled in.
Double Bonus: Spend your time learning Javascript. Ignore everything else until further notice or until you have mastered Javascript. (All the top engineers I know in this business have given me this advice recently, so I’m passing it along.)
You’ll absolutely need to learn how to code if you want to make designing technology products your career. Without learning how to code, all you can hope to have is a really good job. A very rewarding and high paying job, mind you, but in the end, a job.
A job is something that is often at the whim of market forces, quarterly company earnings, and short term product trends. A job is something where someone else will ultimately control some aspect of what you do, and you should set your expectations about the job accordingly. A job is that thing that winds up being how you spend ~40 hours a week to earn a living, but more often than not you can’t wait until the weekend to do the thing you really want to do.
A career is something you pursue for decades, hopefully over an entire lifetime. A career fulfills and rewards you in a way that money or your position in the company org chart cannot. A career is one of the things that will make your heart ache knowing just how much you’ll miss it when you eventually kick this mortal coil.
If you want a career in design making digital products, then you should do whatever you can to train up in the art of code. Further you’ll enjoy it in ways you cannot possibly imagine until you have some of that knowledge under your belt. Knowledge that gives you the power to make things with your own two hands. And isn’t that one of the reasons why you became a designer? To bring into creation that which was not there before?
If there’s any kind of addiction you’ll experience as a designer, I guarantee it’s the rush you’ll get after making something with your own two hands that didn’t exist in the universe until you made it. Getting someone else to make it for you is certainly rewarding, but it’s not nearly the same experience.
It’s the difference between the experience of sitting in a racing car as the passenger versus being behind the wheel.
It’s the difference between enjoying fifteen minutes or so indoor skydiving versus actually parachuting out of a plane.
It’s the difference between feeling really good, even great, about your work versus kicking ass and taking names.
Making something with your own two hands is a super power. Why on earth would you willingly rob yourself of it?
Code is a critical component in creating digital products. Not understanding how it works means at best that you’re flying blind on the job. Being able to do a minimal amount — like knowing how to write HTML+CSS — certainly gives you an appreciation for what some of your engineering counterparts have to do to make even the simplest of designs real. But in the end, even that won’t cut it over the long haul.
Knowing how to code? As in, taking a deep dive into Javascript or Objective C or Java? That’s where it’s at. And as long as people have to code to make digital products, that’s where one of your coolest super powers as a designer in tech will come from. All you have to do is embrace it.
Once you do that, here’s the really good news:
You have an entire career, decades even, to learn how to code!
Sure, everyone wants to be a master coder in two weeks, or lose twenty pounds in seven days, or play the guitar without ever having to practice. Taking time to learn something that is possibly out of your comfort zone — weeks, months, or years — can be a scary proposition.
But this isn’t a pipe dream.
This is your career we’re talking about.
You’ll need to nurture it and grow it and love it over the next few decades. There’s no time to be worried if you’ll ever get it, or if you’ll ever be any good at it, or if you have too much work to do already in your day to day affairs.
Just let go and dive in. Right now.
Looking back on it, I promise you that you’ll be amazed at how much more accomplished you’ll feel. You’ll realize how much more you were able to do — not less — by having that skill in your arsenal. You’ll probably reflect back on it and tell yourself, “Yeah... I kicked ass and took names!”
And like all people with super powers, you’ll feel the same way: Really damn good.
Don’t let anyone ever talk you out of it.
