Do you need to learn how to code to be a UI/UX Designer?
So maybe you’ve looked at a few job postings for designers and found coding popping up in the list of required skills.
What’s even more confusing is a quick Google search shows dozens of articles that say designers absolutely should learn how to code and an equal number that say it’s a waste of time and you’ll never code as a designer.
The startup CV Compiler recently analyzed 500 job postings for junior designers and 500 job postings for senior level designers to see what technical skills are mentioned the most.
When they compiled the results, they found HTML and CSS were the 5th and 6th most mentioned skills for junior designers and the 4th and 5th most mentioned skills for senior designers.
But, if you ask other designers if they code in their jobs (or even know how) you’ll find most never code in their job.
So what’s the deal? Do you need to learn how to code or not?
Let’s get straight to the point:
In the large majority of design jobs out there, you won’t have to code at all. However, a growing number of companies want you to understand coding principles.
In my experience…
I know how to code. I’ve been a UX Designer for over 10 years but before that, I was a full time frontend and backend developer. I’m one of those “unicorns” (whatever that word means in tech anymore) who can go from research, to designing mockups, to spinning up a database, and coding the backend logic. I still code occasionally, including the site you’re reading this on right now.
In my UX career, I can count 4 times when I’ve been asked to code on the project. And two of those times were because I offered first.
There’s been a handful of times where I’m tossed together a little code snippet to send to developers. But if I didn’t know how to code, I could have easily found other ways to communicate with my team.
I also asked other designers I knew if they know how to code and if they use it for their job. Roughly half (9 designers) said they didn’t know how to code at all. Another half (8 designers) said they know how to code, but rarely use it. Only one designer said she used to code for a UX Design job, but that was her only job like that and she hasn’t had to code in the 6 years since.
So then why are there so many design jobs asking for coding skills?
The main reason why there’s so many companies asking for designers with coding skills is because some companies realized there’s a communication gap between designers and developers and when designers know the basics of coding, they help to close that gap.
Let’s think about it like art. Just follow me for a bit. I promise it will make sense in a second:
When artists use pencils, acrylic paints, or watercolors, what they choose to create with is their medium.
Each medium has natural strengths and weaknesses. Watercolors blend together and make soft, dreamy paintings. Pencils make sharp, precise lines and can create detailed, sometimes photorealistic drawings.
The app you design with is a medium. Figma, Sketch, Invision, and Framer are all mediums with strengths and weaknesses.
The platform you’re designing for is also a medium. Web browsers, mobile apps, virtual reality, voice UI, and TVs are all mediums with strengths and weaknesses.
The problem is that the medium we design with as designers often doesn’t behave like the medium we’re designing for.
Draw a box in Sketch and you can drag and drop it anywhere on the page and it will stay there. But create a box on a web page and it will move as far as it can to the top left corner of the page. That’s because layouts in Sketch are fixed and layouts in the browser are fluid. Content in a web browser will always want to stack up in the top left corner of the page. Developers have to use CSS to move content where it needs to go for every browser and for every browser size.
Not only that, but web developers have to make it work at every possible browser size. You might design a mobile, tablet, and desktop version, but the developer has to plan for every size in between and figure out how the layout changes from one size to the other.
Oh and did I mention that browsers have unique bugs where something will look right in one browser and be completely broken in another?
It’s a lot of work to be a developer.
As a designer, you’re aware of how your design medium works and you know how to work with its limitations. But our designs are eventually turned into code. And here’s where communication sometimes breaks down.
We can design something in a way that’s trivial for us to design, but is difficult (or even impossible) to code. I’ve see some page designs where moving something 20px is the difference in a developer working on it for 30 seconds and a developer working on it for 4 hours. Some aren’t that drastic, but spread them across all the pages in a project and they quickly add up.
This can be a huge problem for teams who are working under a tight budget or timeline. Which, you’ll quickly realize, is nearly every project.
So when developers have a deadline and get a design that’s a pain in the ass or impossible to code, they have a few options:
- Go back to the designer and ask them to change things. It’s usually too late because it’s already been approved by stakeholders and gone through several rounds of revisions by the time they’ve seen it.
- Stick to the exact design and try make it work. Then they risk blowing the budget or missing their deadline.
- Make changes without asking the designer. And when the site goes live several weeks later, you’re confused why the final code looks different than the way you designed it.
All of these take time and can eat into the project budget. And it’s not just the developer’s responsibility. It takes different people and skillsets to launch a website/app. It’s everyone’s responsibility.
So what can you do as a designer to help?
Here’s where coding skills come in…
When designers know the basics of coding, they can:
- Design things in a way that’s easier to code.
- Know what questions they can ask developers to avoid problems.
- Share small snippets of code of what you want rather than trying to explain it. (For example: “Here’s the css for the new button style” vs “Can you change the button to a vertical gradient of #E92F48 to #E03D3C with…”).
- Intelligently choose when something should be coded exactly as designed and when there should be wiggle room to tweak it.
- Work on portfolio sites or side projects without the need for a developer.
- Share a common terminology with your developers.
And I think the last one is the most important. I find more developers are paying attention to and appreciating good design. I love working with developers who say “Hey, that loading icon is good, but check out this cool one I saw on CodePen the other day. I think it would be great for this project.” The collaboration you get good developers is another way you can work together to build exceptional products.
But, coding isn’t the only way
Now before you think I’m telling every designer to enroll in a code bootcamp, I should mention there’s another way to better understand the medium you’re designing for. And that’s regular developer check-ins.
At Google, each designer is partnered with a UX Developer. The UX Developer’s job is to be the bridge between design and development. They’re experts in understanding design and turning that design into something that can be implemented across Google’s products. The designer regularly checks in with their UX Developer to review their designs, poke holes, and develop solutions together.
Now for most of us, having a dedicated person to be the bridge between the design and development teams simply isn’t practical. However, you can get a lot of the same benefit by doing your own developer check-ins.
Here’s how you do it:
Pick a developer you can reach out to. Ideally, it will be a frontend developer. And one that will be coding the designs you’re working on. It doesn’t need to be the developer who’s on your project but it helps because sometimes there are project specific things they might need to know about.
Before you’re ready to show your work to the client or hand them off for development, email, Slack message, or walk over to your developer’s desk and say:
“Hey Sam, I have some designs I’m working on and I would like to check in and make sure there aren’t any red flags from a developer’s perspective that might make my designs difficult to code. Do you have time time to review them with me so I can make changes before they’re due?”
They might say they’re busy or are uninterested. If that’s the case, just ask another developer.
When you find someone who’s willing to sit down with you, either print out your designs or export them to PDFs so you can review them and make notes. I’ve found the easiest way is to print them out with margins on the side so you can take notes right on the paper. That way you can just carry them back to your desk and work from your notes.
If you have a remote team or want to reduce your amount of paper waste, I’ve also scheduled a meeting and shared my screen in apps like Google Hangouts, Zoom, or Slack. As we review the pages, I’ll quickly type notes directly in Sketch and next to each page so I don’t have to worry about making changes right there.
An important thing to remember is to make sure you understand why they’re suggesting a change. Don’t be afraid to ask questions. If they say “we need to make this narrower” it’s ok to ask “Why do we need to make this narrower?”
There’s going to be things you won’t understand, and that’s alright. Over time more things will make sense and you won’t have to ask as many questions.
Most developers will appreciate you taking the time to get their feedback because it will make their job easier in the future. Sometimes they might get a little frustrated because they’re working against their own deadlines or that you’re not understanding something. A helpful thing to say is:
“Sorry, I’m trying to understand how this works so I can improve my designs and make your job easier. I know I’m asking a lot of questions but it’s just so I can avoid designing it this way in the future.”
If you decide to learn how to code
Coding is more approachable than most people think. You can get a solid grasp of the fundamentals of coding for web development just a weekend or two.
For iOS apps, the language that Apple encourages developers to use is called Swift. Unfortunately, It’s a lot tougher to learn Swift compared to HTML/CSS. But Apple has created an awesome development tool called Swift Playgrounds that lets you change some code and see the results just as they would look in a live app. I recommend Design+Code’s course Design in Playground for learning how to use it.
Resources to start learning HTML/CSS
- Build Responsive Real World Websites with HTML5 and CSS3 (paid resource)
- The Web Developer Bootcamp (paid resource)
- Don’t Fear the Internet (free)
- Khan Academy - Intro to HTML/CSS: Making webpages (free)