Before I begin, I'd like to show my cards. There is no correct answer to the question of if a UX Designer needs coding skills to succeed. Sure, learning a new skill could benefit you, but if you look deeper into the role of the designer - coding out prototypes and designs could slow you down and make it tougher to iterate. But the real issue at hand is it may take you away from learning the business, practicing UX skills and being in the trenches with users.
It is a great debate that has been raging since before I was in UX and will continue onward. Whether your title is Senior UX Designer or UX/UI Developer I hope that the information below offers some insight as branch out and learn new skills.
There are many paths one can take through the field of UX and each requires different skills. In addition to classic designer roles it seems each year there are new variations that add a new spin to the formula like the Designer PM or the UX Unicorn. Each addition toys with the fundamental concepts of the field and by extension adds new required skills (Design Thinking, anyone?).
This malleability requires practitioners to continue adding to their skillset by learning new methods, concepts, tools and skills. One such skill that continues to filter to the top of that list is coding. Specifically, the question of whether to take on the skill of coding for prototype creation instead of a software-based prototyping suite like InVision, Sigma, Axure, etc.
I have some thoughts to share on the subject and why I have personally chosen a more business-centric brand of UX and hopefully these could help you narrow your path as well.
Whether your background is in development or design if you are new to UX has elements of research, business and design. Organizations that host and salary UX teams are driven by needed efficiency in selling a product or service. Their overarching goal for the team is to problem solve and figure out how to make more for the company via better experiences. We do this through understanding users, internal business processes and designing solutions that balance those in order to reach customers
This means that part of being a decent UX designer is that you should understand the business supporting your designs. Getting deep into business processes and procedures takes time. Learning the products, value propositions, departments and all of the details in each is time consuming and may not leave much time to learn coding.
TAKEAWAY: While it is helpful to be able to code a prototype instead of using software - in my experience it has been much more useful to get into it a room with stakeholders and show you thoroughly understand business processes and are there to be a liaison through the design process. Further, iteration is key to any successful prototype and putting it together with code is sometimes not worth the effort until things solidify.
Let's take an analogy to communicate how UX is similar to a muscle. What happens when you stop practicing a hobby? You inevitably get worse at it. UX is the same - it is a muscle that you need to condition and work out or it atrophies. If you are continually sharpening your UX skills you will invariably become a better but if you are focusing on taking the time to program a deliverable then you are putting your time into building the skill of coding.
Something that people in our industry do not like to acknowledge - UX deliverables are mere steps along a path to completion and meant to be iterative and ultimately discarded (or, put straight to your portfolio 😃) and replaced with the real version. This becomes more difficult when putting the time and energy into coding a deliverable and is sort of antithetical to how these deliverables are used.
This is not to say coding is not useful for this purpose but in terms of requirements collection and working with stakeholders it is sometimes nice to emphasize speed over code. The coding typically is more helpful after the design is solid which is almost never at the beginning of a project.
TAKEAWAY: UX deliverables are meant to be discarded after use but they serve an incredibly important purpose - getting things right before development. The two are not exclusive but bear in mind that it is usually much faster to iterate with a tool like InVision or Figma rather than via code and with that speed comes the flexibility of being able to iterate on design.
Most developers that I have worked with seem quite content to work solo and code all day. That is not a slight against anyone and in many ways I am envious of that position and the beautiful simplicity of it. The fact is that UX lives a very different life than a developer even though both are absolutely paramount to successful projects.
UX is truly in the trenches working with users, business and executives trying to push for more user-centered practices while developers are typically happy with solid requirements that they can get in the weeds with and code. The truth is that Design is only about 1/4 of the actual workload of a UX Designer.
More importantly, being in the trenches is the lifeblood for how you create products and websites that speak to and work well for your users. Those corners should not be cut and before a pixel is even moved a true understanding should be achieved between the business, user and designer.
TAKEAWAY: Coding a prototype may take time away from being in the trenches with your users or the business which is of utmost importance to deliver something valuable. While Design and Development are two sides to the same coin they typically occur at different times. Intermingling them can be a challenge especially since a project may change a lot over time.
Each and every style or preference can work as long as there is a shared understanding between roles and the intended outcome of the project. The beauty of UX is that there is no prescriptive method for completing tasks which leaves them open to interpretation.
If a UX designer or developer prefers to code a prototype that is fine as long as they understand the business, provide sharp UX implementation and spend time with users as that is what is really important.
There should always be a balance and if a skill or new conquest is taking away from the end product it should be re-evaluated. In my case, I found that the business-centric path was the most valuable for balancing the needs of users as well as the business.
Have you been able to successfully incorporate coding into your UX skills?
