Designers and coding is a topic that regularly re-surfaces. While some argue that designers shouldn’t code, I find that as a user experience designer, being able to build and test my own interface designs is of value not only to myself but also to my team. Here are four reasons why I find coding to be beneficial to my work.

So should designers code? There are lots of arguments against it, and Alan Cooper, the legendary software designer, has written a comprehensive 4-part post about it. Here’s a brief summary of his view: “No, designers should not code.”

However, I’m not entirely convinced.

To be able to discuss the subject and present another opinion to it, we should first define what I mean by coding in this context: I mean coding user interfaces – such that a user can interact with and then react to displayed information accordingly. User interfaces are (obviously) user-centric, and therefore understanding how to code them is essential to my work.

I am often the UX designer in our team. I design user experiences and interactions, and they are seldom static. My reason for “why I code” is because it’s part of UX design. Or more specifically, defining the interactions is part of UX design. That can be done in many ways, but for me, the best way to do it is by coding it myself. I’m not coding because the developers in my team need help – it just feels most natural for me to code it, and it benefits the whole team.

I have some strong arguments for why a designer may want to code, or at least understand the restrictions and capabilities that lie within the technical implementations of an interactive design. Here are a few that I have discovered along the way:

Understanding something about the technical properties of different platforms, systems, and languages widens a designer’s perspective. It provides a new way of looking at things. When you know (something about) coding, you understand the capabilities and limitations better, and you can decide yourself whether or not it makes sense to implement certain features.

You can assess the time and cost it takes to code a feature versus the benefits of it. You’re less likely to design stuff that is difficult or expensive to implement. You design sensible and codable UIs that are not based on certain resolutions, but are rather adaptive and responsive.

Design always needs iterations, and they often happen after the design has been implemented. Being able to make my designs interactive and do these iterations myself, without distracting my developer colleagues, my work is easier and faster.

When I code my own designs, I get immediate feedback. This is crucial. It’s rewarding when I can code an idea I have for the UI, and immediately see whether it works or not. If not, I fine-tune it until I’m happy with it. The iterations are rapid.

And even better: if I don’t have a clear idea of how things should work, it’s usually fun to try out different interactions, transitions and animations, and when I see how they work, it’s easy to decide which one is the best choice. It would be almost impossible to specify certain transitions accurately to someone else.

The slow, bad way to do iterations would be to add a task to the development backlog and wait until someone implements the design in the coming days or weeks. That way the feedback loop is very long, and the designer will have to shift back to something that was designed a while ago, though their focus is already on something else.

When I code the interactive user interfaces that I’ve drawn, I can conduct my design work until the very end, instead of dropping a bunch of images and explanations of how everything should work on my developer colleague’s table. A big part of the message gets lost in each handover; when I code my own designs, there’s no handover. It’s also easier to show than to tell: I get from “please code this” to “Hey look, I just coded this!”. I’m a more integral part of the team, not just an input that feeds a machine.

I don’t need to specify for the developers how the interactions work. It’s a lot easier to code the design myself, iterating while I go, than it is to try to explain to someone else how things should work, and then see if my idea also works in practice. Not only does that take time from two people simultaneously, it also takes more time since I have to explain my idea first, and it may still not produce the result I was looking for. It’s great that I don’t have to distract other team members in this phase.

There are plenty of tools meant for designers to help them create interactive designs, test their ideas, and communicate to the developers how the interface should work. Some tools don’t require coding and can produce simple prototypes quickly. Those (like InVision) are great and I use them often for testing user flows.

The prototyping tools that do require coding, on the other hand, are more controversial. While they can produce very fine-tuned interactions and animations, and help designers present their ideas accurately, the code won’t be usable in production. Should the interfaces be implemented, they will have to be rewritten with “real code” – and the code written in the prototyping tool becomes waste. For this reason, when my team is building things for production, it’s often easier and faster to create interactions on top of the existing code and play with that. The code is immediately production-ready.

On the other hand, a project might only involve design and no implementation at all. In cases where there is no existing code to play with, so it makes a lot of sense to use a prototyping tool. You get the benefits of creating the interactions yourself, without having to worry about production code.

It’s extremely difficult to become a good developer, but it’s really easy to get started with basic coding. Even if the basics are all you’ll ever learn, they will take you to another level as a designer. You’ll find some concrete benefits very quickly: You’ll save time by making more sensible designs in the first place. You can take interactions to a new level when you get to play with the code yourself. And even if you didn’t code anything, the team will appreciate it if you’ve already considered the technical aspects, and they don’t need to turn down your nice but ultimately un-codable designs.

Start with HTML and CSS, and you can share a design language with web developers. Learn JavaScript, which is widely used to create interactive interfaces for the web as well as for mobile apps. Coding together with a more experienced developer is a really efficient way to get started. Ask your teammates for support. At the same time, tell them about the thinking behind your designs.

Who knows, maybe everyone will learn something.

The post Why I learned to code as a UX Designer appeared first on Reaktor.