Should UX Designers Learn to Code?

As a UX Designer, should you be expected to create design interventions by coding?

It’s a question many of us have faced. Recently, I found myself in a position where I worked with code to implement design changes. It was an interesting experience, and I realised that my experience would be entirely different from someone who wasn’t exposed to some form of front-end development.

Working with code allowed me to create precise changes to the UI and general interactions on the screen. I didn’t have to leave things to chance and hope my intention was communicated and understood correctly. I was able to roll up my sleeves and work on it myself.

But at that moment, as a Code-Based Design Executor, I lacked long strategic thinking because I was stuck in the here and now. I was focused on the interactions and components at hand. The UI and simple micro-interactions progressed, but the UX remained relatively unchanged.

One lesson I learned during this experience was the importance of commenting your code. Commenting the code makes it much easier to navigate and understand. I hope that whoever picks up after my code interventions will be able to understand what my intentions were in certain sections because of the comments I left behind.

That being said, I would never want to be held responsible as a UX Designer for accidentally making the system implode. I’m a UXer at the end of the day - it’s not really expected of me nor should it be for me to make sure my code is clean and efficient. It’s like asking me to bring a duct tape and a hacksaw to a surgery - Might get the job done, it might even end up being a clean job, but it could also be a terrible mess.

Some UXers might love the opportunity to get their hands dirty with code, I know I did and that I’d love to do it again, while others will dread it.

Final Thoughts

Should your UX team be forced into the deep end of code? Never.

Should they be allowed to dip their toes in the water if they’re interested in it? If they have the time and it’s a low-risk task, why not? They might find ways to improve the way they design to make the end-product more developer-friendly, or find unique solutions that apply a design perspective to coding.

At the end of the day, specialisations exist for a reason, and you should utilise your team for the strengths they have.