Like many of us, I didn’t enter the design field via a traditional path. I just wanted to make things.
It wasn’t even until I was halfway through college that I realized that design and programming were 2 different disciplines.
There are skills you pick up through programming that aren’t part of a standard design education, but are very helpful for working with developers and being a better designer.
“We owe it to our users to have a deep understanding of the medium we’re designing for.”
No, this isn’t another “should designers code” article. There are enough of those already, and your mind is already made up. Instead, let’s talk about some non-coding developer skills that are useful (and potentially career-boosting) for designers to know.
Related: 6 tasty ways for designers and developers to collaborate better
There are several reasons why understanding some peripheral development skills are helpful to us as designers:
- It helps designers and developers to speak the same language
- It enables designers to jump into the workflow and make small changes on their own, without tying up engineering resources for simple things like changing the color of a button
- It helps a designer to better understand the medium they’re designing for. Just as an experienced carpenter implicitly understands the properties of wood, a good designer understands the mechanics that make our medium work.
- It’s always helpful to have a deeper understanding of the possibilities and limitations of our medium
Here are 3 of the key skills that I’ve found very helpful in growing my design career and working with developers:
1. Git/GitHub
If you spend any time at all around developers, I’m sure you’ve heard all about Git. Unfortunately, for such a useful tool, it’s often poorly explained, leading people to believe that it’s much more complicated and difficult to learn than it really is.
At its core, Git is just a system for tracking and syncing changes made in files. If you and I are both working on a project, how do we keep the files synced between our 2 computers? If we both make changes to the same file, how are those changes merged into a single version? Those are the kinds of problems that Git provides a solution for.
Even if you don’t have any collaborators, Git can still be useful. It provides an extra layer of security—if you spend a few days working on something and then decide to change direction, Git lets you roll back your changes without losing any progress, giving you the freedom to experiment without overloading your hard drive with numerous copies of every file.
GitHub is a cloud service built on top of Git, and has become the de facto standard for version control among developers. Even better, they offer a desktop app, so you can use Git with a beautiful visual interface, rather than typing commands into the terminal like it’s 1989.
Git is most commonly used to track code, and if you’re working with developers that’s probably the use case you’re most familiar with. But it’s an all-purpose tool and can track any kind of file, so you can use it for versioning design work too.
Resources:
- Try Git (Free from GitHub)
- Learn Git (Free from Codecademy)
- GitHub Desktop (a graphical interface for using Git)
2. The terminal/command line
I know I just pointed you to GitHub’s desktop app so you can avoid the terminal, but the terminal is an incredibly useful thing to understand.
(Heads up about terminology: on Mac and other UNIX-based systems, it’s called the terminal. On Windows and other DOS-based systems, it’s called the command line. I’ll be calling it “the terminal” for convenience.)
Graphical interfaces are just a proxy for what’s going on under the hood in your computer; the terminal gets us a bit closer to bare metal. By learning how to use the terminal proficiently, we can better understand how computers think and operate.
“Collaboration with developers is much easier if you know the terminal.”
Plus, I’ll admit it: there’s a Matrix-like thrill in typing green monospace letters on a black screen.
Most of what I use the terminal for is simple: moving around the file system, running build tools like Gulp or Webpack, or connecting to a remote server to mess around with my personal site. Since it’s such a generic tool, it can be used as lightly or heavily as feels comfortable.
Learning the terminal makes collaboration with developers much easier. You can run local copies of developer-specific (and terminal-only) tools on your machine, and robust though the GitHub desktop app is, Git is natively a terminal-first system.
Resources:
3. HTTP/REST
For all the visual polish we put on them, our websites and apps are—at their core—just swapping information between devices and servers. The protocol that governs how this happens is HTTP, and one of the most common paradigms for HTTP requests is called REST.
REST stands for Representational State Transfer, and it’s a simple way of describing how web services should talk to each other.
There are 4 types of request: `GET`, `POST`, `PUT`, and `DELETE`.
`GET` requests simply pull information from a remote source. When you visited this post, your browser used `GET` to retrieve the content from the address.
`POST` sends information _to_ the remote source. If you submit a form on a webpage, the data you submit is sent to a web address via `POST`.
The other 2 are less common. They’re used for updating and deleting existing information.
Different requests can be made to the same address to perform different tasks. For instance, a `GET` request to `example.com/user/1` might retrieve information about the first user of that website, but a `PUT` request to the same address might modify that user’s information.
These 4 actions are simple, but when combined they can describe any web service and application. (If you look at Twitter’s developer documentation, you’ll see that the whole thing is just a series of `GET` and `POST` requests.) In fact, most of what we build is just a visual interface that sits atop a series of REST requests.
Once you’re aware of the HTTP request/response system and how REST works, it’s hard to unsee its influence everywhere. Even the most complicated websites and apps are just combinations of the same 4 commands, constantly sending requests and reading responses from a server. Understanding how that works can provide designers with a better understanding of the technical underpinnings of our work.
Resources:
Conclusion
In his book Program or be Programmed, media theorist Douglas Rushkoff writes that understanding our devices is key to making sure we control them, rather than vice-versa. When we don’t understand how something works, we’re much more likely to be unconsciously influenced by its biases.
“What we do outside of work hours is just as important in becoming better designers.”
We may only touch the user-facing side of the software, but our work is still informed by our understanding of its technical underpinnings. As designers, we owe it to our users to have a deep, rich understanding of the medium we’re designing for.
Related: Try out Inspect—a magical new design-to-development workflow
Building that understanding may be different for different people. As for me, I’ve found that understanding the 3 skills above has been exceedingly helpful in making me a better designer and a better collaborator with the software engineers I work with.
Design is a holistic discipline, and most designers I talk to agree that what we do outside of work hours is just as important in becoming better designers.
What other skills/knowledge have you found to be useful in growing as a designer? And what are you interested in learning? We’d love to hear from you.
You’ll love these posts, too
Jordan Koschei is the lead product designer at Agrilyst, where he helps build the intelligence platform for indoor agriculture. He was previously the managing editor of The Industry, a digital publication that helped pioneer design-oriented coverage of the startup scene. When not designing, writing, or coding, Jordan can be found enjoying life in New York’s beautiful Hudson Valley.
