UX Designers love RESEARCH and EMPATHY.
Usually we're talking about the user, but of course, it also applies to stakeholders.
Usually when we say "stakeholders," we're thinking of the business stakeholders.
All that (user empathy, balanced with needs of the business) is important, but there's also the developers. They're stakeholders too in getting the product built.
Most UX Designers are probably nodding their heads at this point. They know collaboration is important. They know that important tools to be familiar with (and to use) are Invision and Sketch. These are the buzzwords.
Reading an article << like this one)) You'll be nodding your head the whole way through as the author eloquently shares the tools and workflows for handing off UX/UI deliverables to developers.
What's behind the scenes, though, what allows a designer like JIESI HUANG to draw an analogy between Git version control and Invision's 'history' tab, is learning to USE a programming language.(see her B.Eng degree in Information Engineering and Media and her experience taking on UI, UX, and coding roles while at the Centre for Digital Media.)
If you're a UX Designer reading this, you're probably hesitant to learn to code beyond a beginner's level. You're thinking, can't I get by without that? What if I just want to design?
Another hesitation when I ask UX Designers if they know how to code: They're afraid I will confuse them with a web or front-end developer. (Admittedly, some recruiters do.)
Though really the hardest part may not be the cost but the persisting. It's easy to settle for less when your job description involves wireframes, research, and collaboration. & you don't NEED to code a prototype anymore when using a tool like Invision. & you should in your day to day do what is most efficient for getting the design work done faster.
Let me be clear: Knowing how to code (through actual practice) is intended to make you a better collaborator, nothing more.
A way to re-frame it that might make the experience more delightful: Think of it (the process of learning & re-learning how to code) as RESEARCH.
It's research. It's learning to fail, learning by doing, practicing empathy - beyond simply keeping up with the buzzwords.
Challenge yourself to learn enough so you can better empathize with what you're asking your developers to do. Then when they push back or explain the ins & outs of what it'll take to build what you've designed, you'll be able to listen closer and follow what they're saying (and/or not saying) further. You'll be able to explain with better analogies what you're wanting them to do. You'll gain their respect for even trying. Give it a go!
Of course, it's also critically important to use a powerful tool like Invision because deadlines are real, and powerful tools exist for a reason.
It's also a great idea to bring developers in on the design process sooner. That way you're working toward the same goals, hand in hand - them doing the developing, you doing the designing.
AND too learn (more) how to code.
Still not convinced?
Come to our workshop Tuesday, March 6th in NYC at Lifion by ADP.
This is just one idea, one person's perspective. Listening to developers is the main idea.
I want to emphasize the importance of having good and open communication with developers. Know what you are designing and why, and discuss the rationale of design choices with them. Maybe you will all come to the conclusion that it is worth the effort to code the design as it is, or maybe you will come up with a better solution together, or an acceptable compromise. Be open to their ideas, acknowledge their point of view, and your team mates will be more forthcoming with ideas as well. Developers can have very good ideas for design too!