Designers: Learn To Code! Here’s How To Start

When you start experimenting with code, you find that the new tool helps you do your job better. Just think of it like getting punched in the face for the first time–once it happens, you realize it’s not that bad.

Designers: Learn To Code! Here’s How To Start

A friend, formerly a competitive fighter, once asked me: “Have you ever been punched in the face?” He and I were about to get in a bar fight. He needed to know if I could handle myself: Apparently, the fear of getting punched in the face holds you back from being effective in a fight. But once you’ve been punched in the face, you realize it’s not so bad–it’s easy to fling yourself into a fight without hesitating.


Similarly, learning how to code can be intimidating if you’ve never done it before. But whatever you don’t know is bound to hold you back from learning. I’ve been hearing for years that designers need to learn to code. At first I thought I’d just end up doing two jobs instead of one. But the better I get at coding, the more I understand how connected they are. As a designer in the digital spectrum, you realize that your very work–your material, which exists in the world–is code. How can you design something if you don’t know how it works? So, designers, step into the ring.

The first punch

I want you to download Processing. It’s a language built on Java and it focuses on images and animation. It’s good for designers because it gives you solid visual feedback about what your code is doing. After you download Processing, I want you to watch the video below. It’s a Processing sketch (a sketch is what the programs are called in Processing), and this is your first gentle punch. The video is about ten minutes long and shows a few simple examples of how to use numbers in different ways in order to make simple shapes on the canvas. Try to follow along with me and type everything out as I do, because I think it’ll help you learn.

If you want to just download the code, it’s here.

Once you get it typed out, hit the play button and see what cool stuff you just made with the code. Start playing around with variables, change the position of shapes with the mouseX or mouseY variables, throw in some simple math, and marvel at the different shapes you can make.

Playing around is fun, but how does this all relate back to your work? As you explore Processing, you’ll learn, incidentally, the foundations of programming (objects, variables, classes, and such). You’ll start by trying to do something, then you’ll find that you cannot figure it out, and eventually you’ll stumble across the capabilities of a Boolean data type that evaluates whether something is true or false. When you want to do something a thousand times, you’ll realize that you can make it a function and run that function repeatedly instead of typing out the same five lines of code a thousand times.


When you start playing with these tools and you understand how they work, you’ll start adding these things into what I call your “mental toolbox.” Design is problem solving: When you solve problems, you use tools, and the more tools you have the better. It’s like finding a cool new Photoshop tutorial, after which that technique gets added to your arsenal of design capabilities.

Once you’re dreaming up designs, you might start to think a little beyond your static tools and begin experimenting with code. I’ll venture to say that you’ll immediately see how those tools can do the job better. You’ll also be better able to understand the exact structure of the dynamic data you’re working with. You know exactly what it’s capable of, and you can use that to your advantage in your design work.

Case study: fluxAbstract

About a month ago, I decided to experiment. I started designing a next-generation header image style for Co.Design. I wanted to create something that would be a little more interesting than a static image–but not something interactive that would dilute the meaning of the article below it.

A short loop of animation would work, I thought, if it moved slowly and wasn’t disruptive for the reader. I wanted it to reflect the current Internet-cultural trends of cinemagraphs, Vine, and the resurgence of animated .gifs in general. In that same way, it would nod to the early days of the Internet, when animated gifs were the awesome workhorses of interaction design.

So I have my general concept, but how do I implement it visually? I didn’t want to break the workflow of the staff designers at Co.Design–those guys and women are pretty busy! Besides, they probably wouldn’t tolerate a massive increase in their design duties.


Here’s what I knew at the start: They need at least one big header image in their current workflow. Then I realized that I could make a pretty interesting animation loop by adding a second image and combining the two images in strips that act as windows with the “scenery” of the individual images slowly passing through. This pattern, I decided, also fit into the aesthetic of Co.Design.

Now I know exactly what I want it to be, so how do I achieve this? Well, once again, it has to be a solution that can fit in to the workflow of the current staff designers. My first thought was to make a template in AfterEffects so the designers could just toss the images on layers and hit “export,” but that wouldn’t really give them any control over the look. And with no variability in the structure of the animations, those animations would get really boring, really quickly.

I needed a way to let the designers control some of the parameters of the animation, such as the thickness of the lines, the angle of the lines, and the speed of the images passing by the windows. I couldn’t conceive of a way to do this consistently and quickly with standard tools, so it would have to be built in Processing and exported as a standalone OSX application.

When I first sat down and started coding, I had no idea if this was even possible with Processing. I started off with the polygon windows, which are basically just slanted squares on the screen. I made a single square and used variables to control the positions of each corner. There was a lot of trial and error working through the math of making the square get thicker (change the x-position of the two corners on the right side in relation to the corners on the left side) and making it slant (change the x-position of the top two corners in relation to the bottom two corners). Then I made another polygon that’s controlled by the same variables, so it moves in the exact same way–but begins where the first polygon ends. After the two polygons were in place, I changed the fill color of the polygons to be two separate images, and made the position of those images slowly change on the x-axis so they looked like they were moving across the screen. Once I got the image fill movement down, I simply had the polygons repeat themselves over and over again until they completely filled the screen.

Now that the core animation functionality was done, I had to make sure the variables could be controlled by a graphical user interface. I decided to use the Control P5 library by Andreas Schlegel. Processing libraries are little chunks of Java that extend the functionality of Processing, and it’s really easy to add them to your sketch. I then added the sDrop library, also by Andreas Schlegel (it adds drag-and-drop functionality to the program), so Fast Company’s designers could drag images from their desktop into the program. After that, I added the gifAnimation library by extrapixel so the animation could be exported as an animated gif.


Then I ran into a huge problem. I exported a gif that was about two seconds long–it totaled 20MB because the banner image size was 1280px x 720px. There was no way this would work as a solution for a website, considering a gif that lasts long enough for the entire image to slide across the screen would be about 800MB. The only plausible solution would be to export the animation as a movie file, so I’d have a little more control over the quality–and it wouldn’t be constructed of thousands of individual 1280 x 720 images.

I ended up finding Andreas Colubri’s GSVideo library, which worked really well and allowed me to export ogg video files. Those work great online–the full 80-second video loop is only about 20MB.

It’s not pretty

My lack of programming expertise and my inability to modify some of the libraries meant that I had to make some concessions in terms of the user interface. I had to make the final program in two separate windows: one for the animation and one for the controls. I also had to make the drag-and-drop targets in the animation window and create a button to hide them from the animation screen–or they’d be exported along with the animation.

One thing to know: It takes a long time for the animation to export, and there’s no feedback to let you know it’s actually working. (There’s no progress indicator.) When it’s done exporting, the program just disappears and the exported video appears in the same file as the program on the computer.

FluxAbstract is clearly not a professionally crafted program. If an actual developer saw my code, he or she would probably want to punch me in the face. But in the end, I executed an idea for a dynamic visual design that could only have been done with code, and I, designer, was the one to make it happen.


Co.Design decided to graciously open-source this project, so you can download everything and play with it yourself, dissect it, improve it, just see how it works.

[Image: Fight via Shutterstock]

About the author

Scott Sullivan is the Director of UX at LPK, and is the author of Designing for Wearables.