When should designers code?
For UI and UX designers looking for the push
Notice that i’m not asking whether designers should code at all (god knows we have enough divisive articles hammering on that already) but rather when. If it isn’t apparent already, I’m proudly waving the flag for designers-who-code camp. A lot of designers embark on a spiritual quest to find out if they should take the leap from Photoshop, Sketch, Illustrator (or whatever tools float their boats) to the world of text editors and IDE’s. I would rather they embark on a philosophical one, by accepting the premise that perhaps coding would serve their passions, skill sets and ultimately their careers well based on a few arguments or conditions. I am not stating that they are absolutely required to but it would be advantageous.
(However, I do want to acknowledge that there’s a glaring problem of companies on several job portals with ridiculous expectations for entry to junior level designers that one could confuse for a full stack developer’s job description. Anyway, moving on.)
You’re new to this design thing
Picture this: You spent most of your high school years doodling away during recess and coma-inducing lectures and a lot of people pay you the compliment of being “creative”. However, you never got knee deep with drawing that perfect eyeball and whenever you could be rolling up your sleeves with that stylus to your graphic tablet or pencil to paper (if you’re old school or just really broke) you have a creeping guilt on finishing up school work. Because let’s face it, nocturnal art expeditions are not going to get you a “real career”. Perhaps you’re from the luckier bunch and attended a Fine Arts or Design school for college. Every semester you haphazardly went from painting to sculpting to illustrating. Then there was an epiphany. You realized a great career lies ahead when creating for tech.
Point is you may be either inexperienced and/or really new to art. Art has astronomical number of categories (if you doubt this, visit Behance and click on categories to search portfolios) and you have yet to pick your niche. Great! you picked user interface and experience design? At this point you’re not just doing art anymore, you’re doing design. Design is art applied with a goal or a purpose (to describe loosely). When you’re designing a website, the goal is to solve problems for your users.
Now I present you the choice of taking the red pill or the blue pill. The red pill lets you try your itchy hand at 3D, computer animation, custom typography, photography, to add richer aesthetics to your design for your next big project. The blue pill allows you to take your sufficiently minimal web design and bring it to life with markup and JavaScript. At this point the blue pill is a lot easier to swallow than later.
You’re surrounded by inexperienced developers
Inexperience and novelty can just as well extend to front-end developers or full-stack developers. This is common if you’re still in college or you’re busting ass at an agency. In addition, by nature, most developers have tunnel vision when building apps and will prioritize functionality over form. Pressing project deadlines generally makes sure of this. Finally, it’s demo day and the sinking feeling of being associated with an ugly app hurts the ego and taints your title as a designer (meanwhile no one but you gives a shit).
If the strength of your portfolio largely depends on designing beautiful apps, you lack control of first impressions on startup founders you meet at professional speed dating events whose first instinct would be to download the app from the store.
I found myself in the belly of this beast plenty of times. Learning code helps with damage control when the front-end developer misses setting that Brandon Grotesque (I’m dodging using Helvetica as an example) to ‘extra-bold’ instead of ‘semi-bold’ and keeps you smug in client meetings.
Your designs are coded up, presenting unforeseen user experience problems
Alright, alright, alright, this can be attributed more to a lack of an agile design process and workflow in front-end development than designers with night sweats and visions of using the dreaded terminal. As a designer you have a lot of work cut out for you to make this go away by using great prototyping tools like Balsamiq or Invision to test app and website interactions by turning them to clickable prototypes along with custom notes that allows you to communicate the logic and flow to your fellow comrade developers. This helps screen out all the unnecessary features and steps to achieve a user’s goal in a website or mobile app.
What tools like these cannot help is to predict how your design for a website for example, will behave across different devices with varying resolutions and pixel densities. Sure, mobile-first design principle allows you to design content based on mobile screens first and then scale to large screen monitors with columns. But are you really going to tell me that you can design mockups to account for almost every iOS, Android and Windows Phone devices currently in use? Is it realistic to micromanage and tweak every little space, font-size, text-alignment, image position by the pixel with front-end developers when you, your project manager and client can change your minds on how it looks? Rudimentary to adequate experience in CSS and Twitter Bootstrap can go a long way here.
As a user experience designer, you may be interested in conducting user testing sessions. Do front end developers need to be in the room? Not necessarily. Sure you may not always have to create functional prototypes but the sessions can get interesting when you judge responses from users and decide to hide some content or tweak a few interactions with snippets of code. How did subjects respond to more or less content? Were they able to identify call to action buttons better or worse? Did they complete the tasks faster or slower? This process of quick fixes or tweaks were inspired by the movement of designing in the browser.
Other empowering knowledge of code allows you to make design decisions that are focused on speed of delivery. Is a Lightbox gallery faster to write than a Carousel? Is the extensive Snap.svg library necessary for you to animate your stroke lines better and faster than a micro library like Vivus.js? You get to leverage your technology insight plenty.
The idea of a steep learning curve freaks you out
As a rookie designer for the tech industry, you’ve either eavesdropped or participated in conversations where developers drop tech jargon on you and you’re often more or less compelled to keep up the facade of being well educated. Awkward grins and nods like you know what they’re saying. Changing the subject when convenient. This is all too familiar with developers as well. There’s no other way to handle it but being honest that you don’t know what they’re talking about, asking questions and reading up on things when you get back home. Ever seen a developer’s bookmarks on web browsers? That’s how they’re getting by.
Incomprehensible verbiage allows people to compartmentalize geniuses and the insane. It is also the primary reason that professionals that tip-toe around the tech industry will never attempt to learn a programming language (or if they were brave enough - beyond printing ‘Hello World’ to the console). Top that off with news about 14 year old whizzkids who dream in code (like seriously, why even try?). As daunting it may seem, just spend a couple of hours on Codecademy and try your hand at HTML, CSS and Javascript. Treehouse is another great platform for learning; Go beyond and learn Objective-C or Java, even if you sign up for a month’s subscription. Read books on front-end development. Surround yourself with great developers as well, lots of them.
Like with any new activity, there’s a dip and things slow down after a few weeks. Suddenly you realize every new bag of trick leads you to more questions. A pessimist would describe this experience as discouraging, an optimist would describe it as humbling. Food for thought.
For more learning resources check out this post by Kristyna Z.
You get somewhat conflicting advice from developers
Once my intentions to code were made known, I found myself dancing to the tune of developers, each providing me with conflicting word salad of technologies - languages, frameworks and platforms to pick up to get started on my next big project. As a designer, your motivations to code are fairly specific and will focus on the client side. This helps singling out what you need to learn — if you want to push your designs to websites or web-apps you’re going to need HTML, CSS and Javascript; if it’s iOS it’s Objective-C or Swift; if it’s Android it’s Java; if it’s Windows Phone it’s C#. This is what you need to know for now before jumping into your first tutorial.
There has been a surge of creating iOS and Android apps just using web technologies like HTML, CSS and Javascript using a popular development framework called PhoneGap. These are known as hybrid applications that behave for the most part like native applications for the specific platform. There are both a combination off business and technology reasons that lead to the decision of picking hybrid over native; You can forgo this debate for the time being. If you have already gotten comfortable with HTML, CSS and Javascript then absolutely go nuts.
Just remember like all programming languages, there’s no one all encompassing method to do things. Finally, best of luck. Great things lie ahead.
Hit the ❤ button if you found this post insightful and follow me to read more about design and technology.
