If you insist on coding as a designer, here’s how to learn to do it properly, and EXACTLY when you need to hand it off to an actual developer.

Overview

For many designers, coding can be murky subject. Designers who can code are HIGHLY prized in the industry, but where do your responsibilities begin and end? What does it truly mean to be a coding designer?

If we’re gonna discuss some of it, we need to discuss all of it.

So, if you insist on coding as a designer, here’s how to learn to do it properly, and EXACTLY when you need to hand it off to an actual developer.

/*Note to devs reading this: I will die on this hill because someone has to; @me if you want, I said what I said.*/

If you insist on coding

Here’s the rub: if you’re a designer that insists on coding, I completely and totally respect that, because I do too. I’ve been coding design specs for years now, and I don’t plan on stopping anytime soon.

There are numerous advantages to being a designer that can code, but you have to know exactly when and where to stop, and that’s the main reason why I always recommend against designers coding unless they are absolutely hell-bent to do so.

To clarify what I mean, I have included a chart that shows EXACTLY where you should draw the line:

→ It can be a very delicate balance to strike, because once you cross that threshold, there will be silent, inescapable expectations that will follow you for the rest of your career.

I won’t go over all of it here, but for the sake of making sure you’re aware, people will assume that if you know how to code, you know:

• How to work with Node, npm, nvm, git/repository services, grunt, gulp, webpack, babel, etc.
• How to work with React, Vue, Angular, Meteor, Ember, Backbone, etc.
• How to manage state with libraries like Redux, MobX, Vuex, etc.
• How to properly spec components in the above libraries
• How to properly create pages and routes in the above libraries
• How to properly create route guards and possibly custom middle-ware
• How to work with login and authentication systems
• How to connect to databases and run asynchronous calls for data
• How to work with service workers and webapp manifests for progressive web applications
• How to work with API’s, promises, async/await, typescript, GraphQL, Apollo…

And a WHOLE SLEW of other things that are way beyond just HTML, CSS, and basic JavaScript. These aren’t just languages anymore, it’s a whole damn ecosystem, complete with lions, and tigers, and bears.

I say this to you now, because if I didn’t, I would doing you a huge disservice. The complexity of modern front-end development CANNOT be overstated, and in this article I’m going to attempt to help you navigate it so that if you DO insist on coding, you’re able to stay within a reasonable circle of competency.

Here’s how to do it right

If you’re still reading, I’m assuming that (like me) you’re not easily dissuaded. Good on you.

What I’m about to show you is a series of resources that, followed to the letter, will show you basically everything that you need to know in order to start coding as a designer.

Before I show this to you though, you need to promise me that you will only go as far as you are comfortable and no further.

The reason that I say this is that expansion in this direction can be exceptionally dangerous, because it is whole other discipline, and it can take your time and energy away from further honing your design skills.

Ready? Let’s get into it.

When your coding starts

Your coding journey should start off in this order and I DO MEAN this order. What I prescribe below is to your benefit, and much like learning anything complex, it must be done following a proper procedure.

1. Learn HTML

Hypertext Markup Language (HTML) is the backbone of everything you see on the web, and it’s what defines the content structure of all web pages.

HTML consists of tags that look like this:

<tag>Content goes here</tag>

These tags are then nested to create the page, the document hierarchy, and place content on a base-level.

2. Learn CSS

After you’ve learned HTML, you’ll want to move into Cascading Style Sheets (CSS) which help to define how your page, site, or web app looks.

CSS consists of selectors, properties, and values that look like this:

selector {
     property: value;
}

These selectors are applied from the general to the specific in terms of page elements until the desired presentation has been reached.

→ Pay special attention to CSS flexbox, grid, gap, and media queries. These will be instrumental in laying out your projects.

3. Learn JavaScript

This is where the danger begins to creep in, but if you’re still up for it, you’ll want to learn JS.

JavaScript, sometimes referred to as ECMAScript (it’s a specification thing), is a scripting language that allows you to add higher-level interactivity and custom functionality to your pages.

The JS language consists of variables, objects, functions, and much more that you can leverage to create custom page functionality, and is normally looks something like this:

function sayWhatsUp(){
     console.log("What's up?");
}sayWhatsUp();

There’s a ton to JS, so take your time with it and learn it as thoroughly as possible.

4. Learn Bootstrap or Tailwind

Some developers and designers alike may frown upon the use of this “opinionated” library, but I have found that it can cut your design time down by a significant margin, and gives you a common, well-documented library which your team can work with.

Bootstrap was originally created by Twitter and at the time of this article is now on version 5.2.

I have used Bootstrap now for years, and will probably never use anything else except for maybe Tailwind, but there are other reasons you might use that.

Bootstrap can help you with everything from layout management to giving you pre-defined common components that you can work with right out of the box, and customize to suit your needs.

It can also help you enforce good practices without breaking your proverbial back in the process.

5. Learn jQuery

Again, this is not a popular opinion, but I would always recommend that if you’re gonna go this far, you may as well learn jQuery.

While not as popular as it once was, and while many libraries have moved away from using jQuery as part of their dependencies, jQuery is still used in over HALF of all sites on the web.

The reason that I recommend jQuery is because newer versions are relatively lightweight (plus if you’re pulling it off of a CDN, your user’s browser probably already has the version you’re using cached, but don’t worry about that too much), but also because it can allow you to create custom functionality and leverage plugins much more effectively.

With jQuery, you’re not using build tools, and you’re not relying on pre-compilers or anything like that. Yes, it does have it’s own engine (called Sizzle), but it doesn't rely on a Virtual DOM, it’s modifying your document directly.

6. Terminology & definitions

Don’t worry if there’s any terminology that I mention that you don’t know about just yet, you can look all of it up right here:

A full HTML, CSS, and JS tutorial

If you’re looking for a video course that’s free, University of Michigan put one out right here that you can check out:

You’re also gonna want to know Git

This is the ONLY command line tool that I would ever expect a coding designer to know, and it is for the express purpose of sharing your work via repository.

Git is the tool that you will use to share your presentational prototype or coded components with your developers.

The most important commands to know are:

git pull
git push
git branch
git fetch
git checkout <branch>
git reset --hard head

For a cheat sheet of important Git commands, check out the link below:

Git can be a little tricky for designers just starting out with coding, but it you’re gonna be a coding designer, you’ve gotta know it. You’ll thank me later.

When to hand it off

Now that you understand the bare-minimum for front-end coding, you need to know when to hand it off.

Crucially, as a designer, the second that you need to do anything more than strictly presentational work, you should hand it off to a developer.

Why? Because when you start getting into scaling a solution, it’s a whole other ballgame. Developers understand how to template and reuse your specced components, pages, and layouts to create a functional product that is robust, fault-tolerant, and operates well at scale.

This is where, even as a coding designer, I STRONGLY recommend that you allow a seasoned developer to take over, especially after you’ve created a coded, presentational prototype.

What is a presentational prototype?

A presentational prototype is what I call the step between a prototype you put together in software like Figma, and the full-on, actual product.

The biggest difference with a presentational prototype is that:

• It’s made with code, not with design software.
• It represents how the product should look and respond on multiple devices.
• It has most if not all states of components included so that devs can take a look at them.
• However it does not pull data from an API, it is not being generated by back-end code from a server, and it is not being put together by build tools or task-runners.
• Because the functionality of this prototype has not been implemented, nor is it scalable, it is STRICTLY PRESENTATIONAL, AND NOT FUNCTIONAL.

What is a functional prototype?

A functional prototype is built by developers and includes some, if not all, of the functionality that your product’s MVP necessitates.

→ A real, honest to God functional prototype will look, act, and behave almost exactly like the final product, down to inputs, conditional logic, presentation, responsiveness, and reactivity.

This can include things like API calls, advanced build tool-chains, special event emission/propagation, and front-end libraries/frameworks that are used to generate the prototype as a Single-Page Application (SPA).

Functional prototypes are normally a natural step in the development process, and they’re what you’ll test on for internal alphas and usability throughout the development/implementation phase.

Does this mean that I can’t work in React/Vue/Angular?

No, it doesn’t, but I will tell you from experience that your time would be better spent maintaining and supporting design standards and engaging in continuous testing to ensure that the product is still aligned with your users’ needs.

→ Even for coding designers: real, actual front-end development is best left to the professionals, because without proper training it is dangerously easy to screw up.

So wait, what about things like LESS, Sass, SCSS, etc.?

Nope. As a coding designer that is not what you do, that is outside of your purview, and I will tell you why: because ALL of those things require build tools to compile down to CSS for performance and compatibility, so NO.

That’s front-end developer territory.

Suffice it to say:

If it requires a build tool, it’s front-end developer territory.

(And to the developer reading this going: “wait a minute, React and Vue don’t require build tools.”

Come on, yes they do. Have you ever seen an actual product made by calling Vue in off a CDN and using the Vue instance page-by-page? No, because it’s impractical for modern SPA tooling and doesn’t work for a decoupled front-end in any way that actually matters.

Ergo, front-end developer territory.)

So if you’re not a front-end dev, what are you?

Congratulations, you’re now a designer that knows enough code to generate presentational prototypes. What does that make you?

You are DEFINITELY NOT A FRONT-END DEVELOPER. DO NOT take that title if you haven’t earned it, and if you don’t have the skills to back it up (see the chart).

There’s been a large debate in the industry for years about what we should refer to these types of designers as, and what constitutes their title.

Titles of these types of designers can include:

• Hybrid designers (not my favorite term, is more confusing than anything, especially for HR).
• UX engineers (typically more advanced and front-end development oriented, see chart).
• Web designers (this is catch-all that is an anachronism from the mid-2000’s that refuses to die, because we don’t use Photoshop to layout websites anymore), and of course
• Unicorns (dead serious, this is an actual term in the industry, and it is INCREDIBLY misleading while setting up unrealistic expectations).

Once again, for emphasis, I will show the chart, and if you find yourself being asked to work with ANY of the tools on right right-hand side of this chart, you are being asked to cross directly into front-end developer territory, be exceedingly careful if you agree to do that.

However, there’s a much better term that I like to use:

Coding designer

→ You’re a designer that knows some code.

• Not a developer who knows some design,
• Not a designer who’s EQUALLY good at development,
• Not a full-stack developer, designer, marketer, PR person, a partridge in a pear-tree, and everything else that they can foist on you while paying you the exact same amount.

No, you are a coding designer.

Wear that moniker, you’ve earned it, now go make some projects and build a portfolio that will blow their expectations out of the water.