Published on | Prototyping: From UX to Front End — Medium Jess Huang

Nearly five years ago, I wrote my first and second-to-last article on my long-defunct UX-focused blog, titled “Designers should know (some) code.”

A lot has changed in the field of user experience design since 2013. For starters, somehow our titles have migrated from “ux designer” to “product designer.” (I did not see that one coming.) User-centered design and its little sister user research have exploded, which makes my tiny grinch heart so happy. Advancements in tools and technology have made it easier than ever to get from design to code — like Sketch’s many features for exporting CSS and even SVGs. (SVGs are a thing now, too, not just a pipe dream anymore. Rejoice!)

One thing hasn’t changed, though. I still think designers should know some code.

It’s not a popular opinion, especially given some of those aforementioned technological advances (although I doubt the visceral response will be as fervent as it was back then). And I get it. Many of us are generalists, we take our projects from design soup to design nuts — from research to IA to wireframes to mockups to animation… Why in the world should we tack on yet another skill to our already-crowded list of expectations? Why can’t we just draw a line and say “ok, this is where my work is done?”

Just look at that overlay printing! (I had to look that up.)

Now, back in 2013, I wrote about how designers should know code because it’s essentially our medium. Print designers know a thing or two about paper and ink; digital designers should know a thing or two about screens, CSS quirks and browsers.

I still stand by that, and I think it’s as true today as it was back then. If you don’t know the limitations of your medium, you’re bound to run into some roadblocks in realizing your creative vision. If you don’t know the thickness of the paper, you could end up with ink bleeding through; the wrong coating could cause the ink to bleed out of its bounds. If you don’t know how background-size: cover works with background-position you might end up cropping your CEO’s head off in that cool background image you’re using when you resize the browser. And that’s not even considering the numerous CSS display quirks between various browsers — although those differences are slowly disappearing.

In the past few years, though, I’ve noticed an even more important reason for designers to know some code: to communicate and work effectively within our teams.

I am a firm believer that designers and developers (at the very least front-end developers) should work together as closely as possible. Call it agile, call it scrum, call it whatever you want: these are the people who are making your dreams into a reality, and you should be working with them as closely as you do your fellow designers (and your product manager).

I’ve seen many designers over the years who don’t think this is necessary, and many of them happen to come from more traditional design disciplines (e.g. print design, old school graphic design). They think about web projects very statically: every element on the page will be placed in a very precise spot, the width of the page will be exactly this many pixels, the image will be cropped just so. I will hand it to the developer, they’ll go do their magic, and, voilà, it will look exactly like this Illustrator file. Except it will be in a browser.

It’s always a little heartbreaking to see this happen. Not only does it exemplify one of the worst parts of waterfall process, it also creates a lot of strife on both sides. The designer is frustrated when the newly-coded page doesn’t look like the mockup they agonized over. The developer has had to make some sacrifices because code just can’t do that, or has been scratching their head for days trying to figure out how to make the code do that, without crashing the user’s browser. Or, the developer has to make a lot of assumptions about what the designer intended (since it can’t be done in code), which the designer then sees as the developer trying to either undermine the design or half-ass the project.The result isn’t pretty. Both sides feel unappreciated and disrespected, and both sides loathe the day they have to go through this process again. And neither side is happy with the page that’s been created.

Now is probably a good time for me to point out that I was a front-end developer, once upon a time. I was a CSS/HTML Specialist and had the nickname “The Amazing Haml” (after haml, and the fact that my maiden name is Hamilton). I know a lot of code. Sometimes I think I know too much for my own good.

But what this has helped me do is be able to work directly with my front-end developers, and speak their language. Can I speak all of it? No. There are so many things that have changed since I was a front-end dev (I broke away from code in around 2013 or 2014), and my knowledge breadth has shrunk immensely.

My husband and I took my mother-in-law and brother-in-law to Japan last year. Before we went, I did some homework: I learned how to say a few basic phrases in Japanese. Am I fluent? Definitely not. Can I order some ramen and hot tea? You bet your fishcakes I can. Because things are going to go a lot more smoothly if you can at least share some of a common language. And it’s the same when working in a product team.

Just this week, I saw this firsthand. My team was responsible for releasing an update to the Degreed.com homepage, featuring a new video around Skills. During production testing after the release (making sure nothing’s on fire, basically), we discovered that the background image for the video section wasn’t expanding from side to side in large browsers. It looked like this:

AHHHHH! 🙈

I immediately knew what was wrong, and how to fix it. background-size: cover was missing from the background image. So I slid into my front-end dev Mikel’s DMs.

Mikel, please don’t kill me for sharing our conversation! 🙀

Because I knew at least a little bit of CSS (background-size: cover is a pretty common property), I was able to quickly communicate with Mikel about it, in a language that was common to both of us. Instead of saying “OMG it’s not wide enough, it needs to stretch! 😱” which might result in Mikel thinking I mean we should change the image’s aspect ratio, in turn making it look super funky, I was able to say ‘hey I think it needs this!’ Even further, I was able to discover and acknowledge that, in a previous conversation, I’d led her astray and been confusing. (Sorry, Mikel. ❤️)

We were able to communicate quickly and effectively to solve the problem; the fix went out in just a few minutes, and everything looked great. And all it took was a little CSS knowledge.

In conclusion

Designers of the world, fear not the code. You may never have to write a line, but knowing it can only help make your designs — and your teams — better. Improve your efficiency, communication and camaraderie. And hey, if you never use it in your day-to-day life, at least you’ll be able to snazz up your Myspace profile. Oh wait… 😨

Not sure where to start? Here’s where I plug my company. Degreed has tons of resources to get you coding! Check them out: CSS and HTML are where to begin.

But wait, there’s more…

On the flip side, I believe that developers should know some basics of design, too. Don’t think you’re off the hook because you’re in the code!

Check out my talk from Mobile+Web Dev Conference 2017 about just that:

<a href="https://medium.com/media/36920ed3635bd7028a82f3031fa0a8c9/href">https://medium.com/media/36920ed3635bd7028a82f3031fa0a8c9/href</a><a href="https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href">https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href</a>

Designers should (still) know (some) code. was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Designers should (still) know (some) code.

Cool stuff, every week

More Articles