Why UX designers should code (and when they shouldn’t)
Learning how to influence the final product through coding
For the last few years, I’ve been working with many software development teams, from small startups to big companies, building great products. At some point, I realized that if I wanted to stay relevant as well as have influence on the product’s development and the end result, I would have to learn how to code.
The developer magician
I remember the first mockup I created for a commercial product. I just graduated from design school, and it was the first time I worked closely with a developer.
“What are my limitations regarding the app’s layout?” I naively asked her.
“Do whatever you want — I’ll make it work eventually,” the poor developer answered.
“Great!” I thought. “I can toss anything I want into this magician’s top hat, she’ll do her magic, and then poof, she’ll pull our brand-new app out of the hat.”
I soon discovered the developer would be able to make the app look and behave as I design, but it would be complicated and would push the code to its limit.
“Photoshop is the most effective way to show your clients what their website will never look like.” — Stephen Hay, author of Responsive Design Workflow
That experience made me realize that if I want to design and create new, innovative, efficient, and kickass products, I must understand how those products work — inside and out.
Know your raw materials and mechanism
Maybe now it’s a good time to mention that I started out as an industrial designer — instead of apps, I designed chairs and plastic products. When planning new, physical products, picking the right materials can make the difference between a successful and failed product. The weight, strength, durability, and cost of the product’s material greatly influences the overall usage experience and quality of the product.
Let’s take an example from the software world, specifically the web development field. On the front-end (aka the client-side — whatever works for you), the basic raw materials we use are HTML (Hypertext Markup Language), CSS (Cascading Style Sheets), and JavaScript.
Let’s focus for a second on CSS, the markup language or “code,” responsible for determining the style of a web page.
The most common tools for creating mockups and other visual representations of digital products, usually used by designers, are graphic editing software such as Sketch, Adobe Photoshop, and Adobe Illustrator. The nice thing with these tools is that they let users create visual images as easy as possible. Rich effects, complex shapes, and free positioning are a single mouse click away — your creativity is the only barrier. However, styling with CSS is a different story.
Until CSS3, the latest evolution of CSS, visual effects, keyframe animations, and transformations could only be implemented using JavaScript — CSS3 has these features baked right in. Still, these are very limited compared to the ones which are provided by the graphic editing software mentioned above.
Another important aspect that CSS is responsible for is the responsive behavior of the page — for example, how the layout will be displayed on different display types and sizes or which elements will shrink, enlarge, move or just won’t be shown in a relation to the screen size and the CSS values (viewports, percentages, breakpoints, etc.). If you don’t know CSS, your control on the appearance and behavior of the product is limited.
Until now, we’ve discussed what many consider as declarative languages and not a “real code.” This is an interesting discussion for another time. Right now we need to look at why JavaScript and other programming languages are also essential for designers to know.
I hear many designers saying that knowing HTML and CSS is enough. Well, it’s better than nothing for sure, but to really be able to design and control your products behavior (aka ”experience”), you should understand how the product mechanism is built. Logic, data structure, and network communication are the building blocks of any digital product. If you don’t know how to use these elements, you’ll end up to being like a makeup artist who can make a face prettier but can’t draw out a person’s unique characteristics.
Working with developers
You’ll need to collaborate closely with your dev team to bring your designs to life.
At the foundation of your daily workflow, you’ll need to communicate your design — how the elements interact with the user’s inputs, how the layout responds to different screen sizes, etc. More than the basic description of the planned design, you’ll also need to make decisions in real time together. When things keep on changing during the developing process, you’ll need to exchange ideas, suggest solutions, and discuss the effect of each possible solution on the overall behavior of the product. In these cases, if you don’t understand what the technical solutions mean, it would be difficult for you to participate in the decision-making process — which might result in choosing a solution that doesn’t enhance user experience but rather damages it.
As mentioned, the foundation of a good collaboration is the ability to communicate, using a common language, with your developer colleagues. You wouldn’t want your conversation with a developer to contain sentences such as “just make it pretty” or “I don’t know anything about design — just tell me how you want it to look and behave”. It works the same when you communicate with your developer colleagues — they would understand you much better when you use terms such as “loop” instead of explaining them you want the program to run over and over and “variables” when describing a value that should change depending on the user’s data.
More than being clear about your wishes, using the right terminology will increase the trust between you and your dev team — they’ll know that the person who’s planning the product is familiar with the work that should be carried out to build it.
Deliver full product elements and better mockups
“For quick design experiments on existing components/screens, I find myself using dev tools way more often than Sketch.” — Stephen Hay, author of Responsive Design Workflow
Fail fast, iterate, improve — in many agile development processes, velocity has a huge impact on the product’s chance for success. In some cases, explaining what you want, waiting for it to be ready, and only then taking it for a test could take much more time than just building it to figure out how shitty your concept really is (or isn’t!).
In addition to the ability to create features by yourself, using code for prototyping can help you create elements with a more precise behaviour — clickable screenshots can reflect the main flow; however, for instance, if you wish to test the layout’s behaviour response to dynamic screen resizing, writing a quick HTML and CSS can bring you much more insight.
Here is a simple example of how you can quickly test a responsive layout using simple HTML and CSS:
Part of the team, part of the conversation
The last point I want to discuss here touches a subject that many people don’t usually consider but is a large part of daily working environment : code culture.
In the IT industry, which as a UX designer you’re a part of, not knowing code means not only not knowing the programming language, but also not knowing the “spoken” language. No, I’m not trying to say that people in IT companies actually speak to each other using “if/else” statements (though sometimes they do). Rather, what I want to say is that in environments populated mostly with developers, there are going to be many debugging jokes and a lot of jargon containing code and programming references. If you want to stay a part of the culture and participate in the social dynamics, you should get some experience in coding.
When shouldn’t designers write code?
Don’t get me wrong — designers are not software engineers. Although there are many cases, as I mentioned before, where it makes sense for designers to code, I still think that coding isn’t their main job. Code for a designer should be used as a tool for enabling better expression and communication. Yet, writing a good, secure, and stable code is still a craft which takes years to master. Designers have too many other skills to master, so when things get complexed and need to be delivered at production level — when you are talking about software architecture and building scalable performing products — developers are still the professionals.
Let’s start!
So you are convinced that you should learn a bit more coding, but where to start?
Don’t be afraid: The first step is to understand that coding, like spoken languages, is something that anyone can learn, especially if you’re already inside the industry and exposed to programming daily.
Learn: There are some awesome online courses for learning code out there. My recommendation is to start from the basics—HTML and CSS—then move to basic JavaScript. From there you can start and focus on popular frameworks such as jQuery, Bootstrap, and Angular.
Here is a list of great online resources:
- Code School — great online courses for kind.
- Codec Academy
- Stack Overflow — your new best friend, this is the main resource for Q&A regarding code and programming.
- CSS-Tricks — excellent how-to guide for CSS.
- CodePen — online, real-time, code editor. You can also find tons of nice examples and projects.
Basic tools: Here is a list of basic tools you can use for starting:
- Sublime Text — this free (trial) code editor is simple and has great plugins. My advice is to try several editors and to see which one works the best for you.
- GitHub — Git is a distributed version control system that can make your project version management much easier. Here is a link to my repository.
- Browser DevTools
Get your hands dirty: Ask your team lead for small code tasks within your team. Start with some code parts that doesn’t have high visibility — that way, it will be easy for them to give you some room for learning.
Ask your colleague developers for help: Get for tips and tricks. I find this is a huge benefit for designers who are already on a development team. The break area is a great place for some “when should I use a div?” questions.
Good luck! And remember, code is a tool, not a goal. Adding code to your professional toolbox can make your role as a UX designer more impactful to your team and your company.
