“Should designers code?” is an obsolete debate

I entered my software design career with a hybrid computer science and art background, so my creative process has always been programmatic. For nearly 20 years my medium of choice was the web, where I taught myself to to build my own stuff, first with plain HTML, then with CSS, then PHP, JavaScript, Rails, and all sorts of other tools along the way. Later on I dipped into building native apps with Swift.

I’ve long thought that this hybrid code/design approach was the ideal way to do software design, at least in the sense of deeply understanding all the core materials you’re working with, so you can make informed choices.

Designing programmatically also has a number of productivity benefits, the best of which is that it’s easy to make computers do a lot of annoying detail work for you. There’s no need to spend time toiling over hypothetical mockups of interfaces, when you can just work directly on the actual interface in the actual codebase.

This is especially useful when you’re working with large datasets and iterating on little details in bulk, like adjusting a visual element that will reappear 50x on a page. It’s easier to change a couple lines of CSS than to update 50 separate parts in a mockup. You can immediately see the effects of the change, and then continue tweaking until you’re happy, with no need to communicate all your pedantic nitpicks to a programmer. Commit the code and you’re good!

BUT.

This year I started working at Twitter, which is a larger organization than I’ve ever experienced before. At Twitter, I’m not writing any code. I’m working with other designers in Figma, using a collection of neatly developed components from the company’s design system.

I’m certainly a little less speedy, because I’m not a Figma pro yet. I also occasionally find myself yearning for a few of the advantages of programming.

But otherwise, I’m surprisingly happy with the new process…for two reasons.

1. Creative tools for designing interfaces are as sophisticated as they’ve ever been. Figma is built specifically for this purpose, so you can be fast and productive in maximum fidelity.

2. I realized that software design is not really about code at all. Code is just the material outcome of your design process, and a set of constraints that you need to consider throughout that process. Knowing programming does help you understand those constraints, but you can also achieve that by partnering closely with developers instead.

A designer’s main job is a nested puzzle: identifying the right problems to solve, figuring out the right solutions to those problems, persuading lots of people that you did it all correctly, and then finally putting a well-built product in customers’ hands.

In a larger organization where systems are complex and there are dozens of different teams working on projects, the designer’s role is more focused on communicating internally than on designing final production designs externally. You need to do the latter too, of course, but it’s a fraction of the total design work you’re churning out.

Most of your design work is in explorations, ideas, research, and presentations that help you collaborate with lots of stakeholders. Larger orgs necessarily have specialists focused on all the finer points of the work. They’re thoughtful and methodical in making changes.

In this scenario, the company is incentivized to make it fast and convenient for designers to churn out high quality, realistic mockups without having to dip into code. The speed of systemizing your UI like this is remarkable. Using the design system, we can spin up almost-production-quality comps in an afternoon, then distribute that for feedback right away.

And what’s more, the real-time features in Figma create a healthy collaborative space for lots of people to explore and review ideas simultaneously. It’s amazing and feels like a tool from the future.

At this point, the age-old “should designers code?” debate is mostly irrelevant. Designers should do whatever they need to do to make things happen, in whatever circumstances they’re in.

If you enjoy writing code, and you work at a company that wants you to write code, then yes you should. (You should also demand a raise, because you’re doing two jobs, and it’s truly difficult to be good at both things.)

If you don’t enjoy writing code, or you work at a place that doesn’t require it, then don’t do it.

Both of these situations are good and fine. You do you. Don’t listen to anyone who tells you you’re wrong for whichever choice you made. 💞