Designer coders, some thoughts

No, this doesn’t refer to savvy engineers wearing hip, trendy fashions ;-) Just wanted to share some thoughts on this oft-debated issue of whether UI/interaction designers need to learn how to code.

Jared Spool recently spoke about it on his blog here. (and posted a nice short follow-up here on 3 reasons to learn to code, particularly about “knowing your medium” and “bringing your ideas to life via prototyping”) He was primarily looking at start-ups and the need to stay lean given the financial constraints and time-to-market delivery pressures. Although truly in any software development context, to maximize your ability at both designing and programming while supporting the overall product vision is an awesome ideal posture–just very difficult for many, if not impossible. But it can be done and is a great professional goal.

Some arguments raised against doing both design & code concern compromising theUCD stance when ascertaining what is best for the technology (versus the user) or struggling with two inherently contradicting masters, thus nicking the “user-centered” design vision. Or trying to be a generic “jack of all trades but master of none”, thus ruining both the code and the design. But those are frankly amateurs anyway ;-)

As for “compromising the UCD stance”…any pro designer has to contend with multiple masters (including Prod Mkting/Mgmnt, QA, Docs, the GM of the division, etc.)  and assuage the politics and nuances of needs/wants accordingly. Designers are inherently often in the crossfire of mediation, but with the advantage of seeing cross-functionally, empathizing with multiple POVs and visualizing options along the way to keep the conversation (and tough decision-making) moving forward. Any responsibly honed design must factor in tech capability, commercial viability, as well as user fit. Indeed the designer who willfully ignores the technical aspect is doing the user a grave disservice, in effect relinquishing their seat “at the table”. That designer, IMHO, has no right to complain if the shipped product doesn’t correspond to the design vision! Instead, the designer needs to figure out how to get involved in UI engineering discussions at a partnership level, if not as an actual coder herself.

So if we instead re-cast the issue around “how to insert designers into engineering collaboration”, this might make for a better cause overall. Whether the designer does the coding herself, or is deeply embedded (not just observing but participating actively, advocating critical choices) in tech discussions, it’s all for the same purpose: to achieve the intended vision of a design, made real and feasible, and adapted along the way to address and optimize for any tech hiccups so the user (and business) benefit. That’s our goal, right?!

I realize, it’s not as slick sounding as “designer coder hybrids”– which are awesome and perhaps will become more of the norm, as newer generations of designers become increasingly comfortable with toolkits, APIs, SDKs, etc (and taught them in d-schools)…

Ultimately, for their own pro credibility and enabling a product success, UI designers need to be much more aware of the capabilities of a UI technology and how this affects their design, and the user’s experience. Gotta ask yourself some key questions to start:

• Can the chosen technology be re-skinned and styled to get the desired design, with pixel accuracy? 
• Can it be made responsive / performant enough in the enviro intended to be used? (desktop/web/mobile)
• When the engineering team says it cannot be done, do you believe them? Are you able to suggest an feasible alternative with justification? 
• Is it a problem with engineer’s existing codebase than the framework of the technology? In other words, is it really bad “code design” on their part and would it mean a lot of rework for the “UI design”?

And in terms of skillset, the following are becoming invaluable for designers:

• Translate interface layouts into functional prototypes with clean, modularscripts and code snippets that can be reused for subsequent builds (as needed)
• Effectively and constructively call out an engineer when that person resists design-driven changes to a product
• Ability to argue back effectively and generate workaround design alternatives that logically address the engineer’s technical concerns

Bottom line, if you are willing and able to learn programming or at least some development tools/frameworks and gain familiarity, then by all means go for it! This will make you a better, stronger, faster, capable, influential designer achieving the user’s goals of enjoying a product that is satisfying and faithful to the vision. At very least, get involved in the geeky UI tech discussions and keep abreast of tech issues. Do tutorials and participate in forums or attend seminars at events like Microsoft MIX or Adobe MX, etc. (or Silicon Valley CodeCamp ;-) Become the UI engineer’s  buddy! As I wrote in my paper for HCI International, the ties between design and engineering are necessarily getting closer.

Design teams need to inform and guide the selection and use of proper UI tools/frameworks/tech for proper front-end presentation. At least having a close, active partnering relationship, asking good critical questions, and showing curiosity will help a long way!