Should Designers Code?
There are countless articles and blog posts debating the skill sets required for UX Designers, UI Designers, "Full-Stack" Designers, and so on. Many of these come with strong opinions on the right amount (if any) of coding knowledge necessary for designers to possess and unfortunately, these often dogmatic views leave little room for nuance. Personally, I think it's the wrong question to ask - it's not a matter of "designers coding", but rather how much should designers know about a process and discipline that is so primary to realizing their efforts?
Expanding Considerations
While no one would argue that we shouldn't understand users' motivations, systems, and constraints, it would seem as a profession we are largely neglecting to understand those same considerations for our developer counterparts. It's quite easy and somewhat common to live in a UX world that is focused on journey maps, personas, and wireframes which are handed off to a development team for implementation. Hopefully processes are in place to facilitate a feedback loop among the development team, design team, and product owner to deal with the inevitable back-and-forth that will occur in the course of delivering a feature. The time between design delivery and development implementation is often troubled with assumptions of vague requirements or undocumented behaviors which fall to the developer to resolve. Mature teams can spot these alignment problems in story grooming, and good designers may anticipate some of the blind spots early, although these are regularly encountered mid-sprint and can easily snowball into bigger issues. It helps when designers are embedded within an agile team, and are available to collaborate, test, and provide feedback, however, the world of development is still largely considered a black box for many designers.
Good designers and researchers have a deep understanding of users - their goals, motivations, environment, and pain points. We gain this knowledge through various methods such as contextual inquiry and interviews, then we document and understand it by creating artifacts like personas, journey, and empathy maps. When we dig in to these workflows and pain points, interactions with systems (tools, software, & processes) and their underlying constraints or shortcomings is generally the focus of our work. Understanding how these systems work, how users interact with them, and how they may be improved is foundational to the work we do. Why wouldn't we apply those same considerations when thinking about the systems and people building the solution for our users?
Developer Empathy
Although users are the primary consideration in most projects, we can also turn our attention inward to view our team interactions, systems, and pain points through the same lens and using the same tools and methodologies that we utilize for our end-users. This meta-view of team interactions and dynamics is implicitly captured and loosely guided by design, development or organizational processes, but we can provide value when we explicitly and purposefully examine it outside of these frameworks. Getting to know the tools, behaviors, and dialect of your developer teammates can help facilitate better team communication and provide a more holistic view of the product life cycle.
Before we start to think about "learning to code", we should probably get a better idea of what developers are doing, how they work, and what they care about.
Get to Know Your Team
It probably sounds like a no-brainer, and since we aren't robots, this is probably already happening to some degree. This is a building block for everything else. This is not to say you have to be best friends with everyone, but you need to build some sort of rapport and establish a baseline level of trust. Find some commonalities outside of work - don't pry, but casual conversation about sports, hobbies, family life, and pop-culture can help get the ball rolling. Some people are more guarded than others - no need to interrogate them, but sometimes offering information about yourself can provide the catalyst needed for others to open up.
Listen
If you have established a rapport with developers on your team, you might strike up a conversation about the project, what it's like to be a developer on this project, and try to understand some of the pain points they encounter. If you feel awkward initiating the conversation, it may help to frame the interaction by explaining that you would like to know more about how they work so that you can better support them on the design side of things. Asking questions like, "is there anything I should be doing / or stop doing to make your job easier?" could be an opportunity to get valuable feedback.
Learn
When you create a journey map to understand the workflow and areas of friction faced by an end-user of a system you are researching, you are also forming a mental model of the system(s) and process(es) in play. We usually have little domain knowledge going in, but over time we can learn enough to understand how it works. Similarly, as designers, we don't necessarily need to know how code is written, but if we can form a mental model of how modern software is built, we can make the start to make the "black box" of development a little more transparent. We can start by listening to the conversations that we might normally tune out, such as the developer exchanges happening during story grooming or retros. Asking devs how something works or the meaning of an unfamiliar term can be a more direct way of filling in the gaps of our understanding. You can start off very broadly and build your understanding over time - much of what you learn can be applied generically across different projects.
Involve
Designers sometimes have a tendency to be protective or even territorial of their processes and work. While expertise is important, collaboration is also necessary. Inviting your developers to user interviews, contextual inquiry sessions, or design reviews is the best way to build teamwide empathy and avoid designing solutions that are not feasible to implement. Developers can be powerful sources of creativity and if they understand the problem space, can be good partners in finding practical design solutions. In an agile world of development where it can be easy to keep your head down on the current sprint, whenever there is a chance to zoom-out and get a more birds-eye perspective, you should encourage your team to take the opportunity.
Summary
Understanding and building your own mental model of development processes and basic technical architectures is often an ignored and sometimes discouraged activity for UX designers. By categorizing the technical side of design implementation as unimportant or immaterial to our roles, we are unwittingly ignoring opportunities to make more informed decisions in our designs. Instead of burying our heads in the sand, we should make an attempt to grow outside our comfort zones and apply the skills we already utilize to understanding systems and workflows to a different domain. Over time, we can improve our knowledge to more accurately recognize constraints, the impact of our design decisions, and ultimately produce better products.