A common question asked by people entering into the UX career path is what skills they need to get an edge over others in this new wave of freshly minted UX juniors. I often tell them that they’ll spend roughly half their time on the job doing UX process (technical skills like researching, prototyping, workshop facilitation, usability testing, etc.), the other half in supporting UX in some form or another (soft skills like negotiating, mediating, presenting, reporting, navigating bureaucracy, inspiring, selling, etc.). It’s a lot to take on. Not only must you learn a very broad range of UX skills; but also be adept at being in the centre of complex projects with many moving parts, and dealing closely with disparate people across an organisation in a meaningful way. What an incredible responsibility and challenge.
There’s a recent trend however, where organisations and leadership increasingly expect their UX teams to learn and take on front-end development responsibilities. This isn’t a simple matter of building their understanding and awareness of front-end technologies, but in fact to increase their scope of work and accountability to essentially code what they design. At first it seemed isolated to a few companies experimenting with the idea, but as of now it’s become more of a movement.
We’re talking HTML, CSS, JavaScript and so forth, all the usual front-end suspects. Companies send their UX teams on coding boot camps, enrol to online courses, drop them into development hack-a-thons and dole out programming ebooks; with the expectation a functional and efficient programmer miraculously emerges out the other end. That’s the best case scenario. In the less desirable and more typical scenario, they’re basically left to figure out most of it on their own and between their equally bewildered colleagues, with perhaps brief glimpses of help from actual developers.
They’re then thrust into the world of coding… accountable for their efficiency, quality, timeliness; just as someone who’s made it their life’s work and career path having spent years understanding the principles of development. Yes there’s probably leniency in the beginning, but ultimately there comes accountability. And to those that came from non-technical backgrounds into UX, it’s a rather harsh adjustment.
With any UX team put through this, there’s likely a decent portion of team members that originate from creative, marketing or psychology roots, focusing their learnings and career as such, then moving into UX and ending up responsible for highly technical tasks, frankly it’s dispiriting. I can’t help but think what’s going through their heads… “I thought I was going to produce insights and understandings about our customers and craft beautiful experiences for them, but I’m here stumbling through typing computer code?”
Another way of looking at this is asking a developer to create beautiful visual designs, by and large they’re simply not ‘wired’ to do so. And it would be impractical to expect a handful of “catch up” courses to rewire that. Or how about asking a building architect that’s finished a fresh set of floor plans to take up dry walling and steel frame construction? This doesn’t happen, because it’s a ridiculous misuse of their talents and capabilities.
Essentially, the whole arrangement is a recipe for resentment and dissatisfaction. The UX person tries their best to belt out some mediocre code in double or triple the time a thoroughbred developer would have, complete with a few bugs and inefficiencies. Management resents the UX person, as they’re seen as failing to perform, not putting their “all” into it, not “carrying their weight”, or however it’s interpreted. The UX person resents management because they’re stressed, not doing what they’re hired for or comfortable with and after all this, still likely have their actual UX work piling up to do.
And when UX people need to be hired, many can attest to recruiting great UX talent as being difficult; there’s short supply and strong demand in the marketplace. Is it worth deterring the ones that want to research, solve complicated design issues, and discover great new interactions for your products by being pig-headed about the need to code? What about the juniors entering into the UX career path? Doesn’t it send confusing signals about expectations and learning requirements for the road ahead?
Where Did This Come From?
A perfect storm of factors came together over the course of years to develop this movement, not any single given factor. Put all together, it creates an environment where organisations see others trialling this strategy and blindly do an “us too” without careful consideration.
Everyone Should Learn to Code
Prominent technology industry people have been leading a charge to get everyone involved in coding. Kids, women, your grandmother, pets, everyone has been the target of a “coding is good for you” mantra. Apple launched fun code learning tools for kids to great celebration by many. Essentially coding is touted as this skill of all skills that everyone can benefit from. This of course wouldn’t have anything to do with these very companies fueling their own insatiable need for programming talent?
People jump onto feel good initiatives, programming classes, belt out a few sample projects and say “Look, I can code!”. Then they mostly shelve it and that’s a wrap everybody. Got a bit of coding exposure and understanding, that’s great, well worth the time. Should they be needing to now code as part of their job responsibilities? Not really. It’s one thing to be able to read and have a basic understanding of code, it’s entirely another to write code that is committed to the code base of an application. Fact of the matter is, it’s easy to find front-end developers, much harder to find competent ones, there’s a reason for this.
Hat Sharing and Cross-Disciplnary Teams
A trend, particularly in the startup scene, is for individuals and teams to be cross-disciplinary and as they put it “share a lot of hats” (hats referring to the distinct skills and responsibilities needed to complete tasks). This came about for a variety of reasons, but principally in a startup perspective, hat sharing creates perceived resource efficiencies. If you can get one team to do UX, creative design, marketing and front-end coding, you’ve supposedly eliminated the need for discrete teams or specialists to handle these roles. It also attempts to have everyone better understand and appreciate a broader scope of functions within the business and reduce siloing. It’s seen that if people take on a variety of roles ‘to achieve the greater goals of the business’ they’re somehow more valuable. There’s certainly elements of truth in all of this, but there’s also dark sides and caveats.
It’s interesting that the advice given to the very entrepreneurs and founders instigating these strategies, is to focus on what they’re good at when building a business and delegate the rest. Extensive hat sharing strategies does seem to fly in the face of this sage advice, it’s been conveniently forgotten. Some even go so far as to say, everyone should be across everything, which really is a wank. Why can’t people be allowed to focus unhindered on what they’re truly good at. Where does this expectation of hat sharing really expect to take us all in the long run? Digital jack of all trades? Mediocre at a lot, great at nothing?
Personality Types Misunderstood
What screams out at me is just how little all of this takes into account people’s in born natural tendencies and personality types. There’s still a significant lack of understanding or appreciation by companies for how individual people’s minds work, their ways of expressing or contributing, their inclinations. Nope, you need to code.
It’s interesting all the research coming out recently that challenges our traditionally held ideas and handling of say introverts versus extraverts, or creative versus logic people. So many “truths” being debunked. There’s such fascinating differences, their contributions so unique to each, and it should be celebrated, not tampered and blended. It can somewhat be compared to the long held beliefs around open-concept offices, “Everyone will love this, it’s so collaborative and fun.” Yet the truth spells a starkly different take on this one size fits all approach; for some people it erodes productivity, mental focus, task performance and often provides insufficient mind space to contemplate and deep think.
Advancements in Prototyping Tools
Traditionally, prototyping tools generated HTML that enabled you to use the prototype interactively in a browser. The caveat is that the HTML is complete gibberish (yes, I’m looking at you Axure) and useless beyond it’s immediate intended use (read: zero production environment value). How UX teams have gone about prototyping has started to shift however, and so have the toolsets. It’s becoming more common for prototypes to be built up directly in Sketch or other similar tools and through a combination of plug-ins and services can be exported out to code needing some post cleanup, optimisation and integrating, it’s somewhat usable.
The misunderstanding is that a UX person can then go in and perform that cleanup and wire up whatever the prototyping tool couldn’t do; when in fact it’s these exact tasks that truly necessitate a skilled and seasoned application developer to handle. The ratio of developers to UX people is commonly off kilter by considerable amounts, often with dozens of developers for every few UX people. It’s somehow easier to justify to the business to bring on new developers than UX, so let’s not further dilute what little UX resources there already are.
Unlimited Learning Options
With the proliferation of online courses, free or nearly free events and a general abundance of learning resources readily available to everyone, there’s a new view that it’s all there, you can simply use these resources and suddenly gain the skills. Completely ignoring whether what they’re learning aligns with what they specialise in. To be honest, if the UX team has time to be attending classes, sifting through manuals and going through the inevitable learning curve and practice needed to competently code, they’re likely under utilised or being misused for what they were hired to do. It’s all part of an under appreciation of UX and its all consuming nature if someone truly is to have a prolific career. It never ceases to amaze me how much I personally need to read through, watch and partake in to keep on top of the continual evolution and developments in the practice of UX. Adding another discipline to that mix seems counter productive.
What’s Your Point?
So is this piece advocating UX should be totally hands-off the technical aspect of product design? Absolutely not. UX practitioners should be well versed in the capabilities, limitations and best practices of both the front end and back end technologies their designs depend on. If you don’t know what a technology can or can’t do, how can you design for it? Having a basic knowledge of the code base for common programming languages is incredibly valuable for appreciation of its capabilities, but this doesn’t necessitate being responsible for hands-on development.
Am I alluding to UX practitioners being incapable of taking on coding duties? Again, definitely not at all. I’ve met a number of UX people who confidently handle front-end development, but that’s often because they were motivated from early on to be end-to-end full stack designers and were likely exposed to the technology side early in their learnings because they had a desire to do so. Are they very good at both UX and front-end development? That’s debatable and largely comes down to the individual, but as in life where one side of a scale weighs down the other must tip up.
What I’m drawing attention to and questioning, is the suitability of mandating front-end development responsibilities to UX team members irrespective of their true propensities. Does it make best use of their skills, capabilities and time in contributing value to the organisation? Is the time investment needed to learn and practice front-end development better spent honing critical UX skills? And ultimately, is this what these people were hired for and is it what they’ve signed up for?
What To Do
What’s actually needed is for UX and development teams to cultivate strong relationships that are seen as mutually beneficial partnerships with the common goal of building great products together. There should be constant collaboration, communication and involvement between the two throughout the product creation process, both during design and build. UX teams should be affable and supportive, treating their developer friends well. Ultimately it’s the developers that realise their creations. Likewise developers depend on UX giving them innovative product designs, supplied in well thought out and comprehensive materials to best guide their build efforts.
Teams should be appreciated for their specialty, with each leveraging the expertise of the other. By allowing each to do their own thing and keeping clear separation of duties, we avoid the ambiguity that leads to uncertainty in job responsibilities and success measurements. This isn’t to say each shouldn’t attempt to gain a sound base understanding of the other’s field, but being responsible for doing their work is all together something else.
UX should never have a “lob it over the fence” mentality. Developers should be encouraged to partake in workshops, bringing their technical angled input of ideas into the discussion. Sketches and prototypes should be presented as they progress so that questions can be fielded, technical concerns addressed and to familiarise developers with direction of the design. Likewise developers should present UX with access to development servers to evaluate the state of the builds against the prescribed designs and behaviours.
When handing over designs to developers, they should be bundled into a collection of documents that expertly inform developers as to every detail of the design. Because where there’s uncertainty there’s likely to be misinterpretation. System architecture diagrams visually describing the system and it’s functional connections. Prototypes that are well crafted with detailed annotations, that make good use of reusable libraries. Specifications and use case documents, where applicable, clearly describing system, page and interaction level use scenarios. Well produced pattern libraries and colour palettes with specifications and informative descriptions. Along with anything else that can possibly make the developer’s lives easier.
With all of this in place, everyone can take pride in doing what they do well, and play a supportive role in gaining the best from each other. UX and it’s role in business is not only constantly changing, but constantly needing justifying as we go through its maturation. We’re still the new kids on the block in the eyes of many. UX is one of those incredible career paths, like science and health… it’s amazingly broad, constantly changing and takes a lifetime to master. Don’t unnecessarily mar it over simply wanting to jump on the bandwagon, use UX for what it’s intended.