The UX “Full Stack Unicorn” and How it was Born

We’re looking for a UX person that can build wireframes, create pixel-perfect design, is fluent in html, css, javascript and Jquery, do usability testing, and Java and J2EE would be nice to have. I have seen many job ads very similar to this in the past years.

 

It is strikingly apparent that too many hiring managers, especially engineering types, don’t know what UX is, even though it’s been out there for decades. But regardless, my questions are:

1. why would anyone think one person can do all this (and well, and at a lower salary than a developer),
2. what does everyone else do?

It’s apparent that the ad above from a probably small company is looking for someone that can do all “front end” work, leaving the database, server, networking and so forth to their back end developers.

But it’s revealing to examine the history and psychology behind all this. I should mention that I’ve been in UX nearly three decades, and have worked in other IT areas before that and in overlap, which included software engineering and graphic arts. The following is based on mostly my own experience but other research as well.

Where it all began…

As to the questions, having “grown up” with computers in the workplace from the very start (late 1970s), I would attribute the idea that one person can do all front end work to how things evolved from the birth of UX in the IT world.

Programmers (developers) were always considered very smart (later read “geeky”) and at one point were building entire systems and applications along with the interfaces for them.

Prior to GUI, you had to supply some way to talk to a program and that was via a text only 24-line by 80-character wide green on gray screen. You had to. The hard part was choosing the right grammar, such as a simple y/n input, selecting from a list, etc. – nothing very difficult and made even easier by having no options to speak of – essentially the bare bones of human-computer interaction. And programmers considered themselves quite up to the task, since it both seemed and was not difficult and just a minor annoyance.

When GUI came along, some developers welcomed it, simply as a fun way out of the ugly text screens. But when they found out that there was a kind of art/science behind it, acceptance was varied. Everyone involved soon saw that there was much more to building an interface than they thought and/or were used to, and some engineers spurned the idea as too “artsy”.

However, some, like myself, saw it as a more advanced way to interact, even a fun way, and eventually moved on to the psychological pursuit of graphical user interface. Little did they know what they were entering into, but that’s another story.

After some time, it was apparent that engineers wanted to retain their wizard hats in the IT realm, and I noticed their (not all) continued disrespect of the “lesser” pursuit of HCI. To this day I believe some are still unaware that you can obtain a PhD in it. Some still want to keep it locked in the tower, probably not so much as a comment on the field but rather to keep it comparatively lower in respect to their own. But I believe this has begun to pass now, just by the prevalence of UX in the SDLC (Software Development Life Cycle) throughout the IT realm.

The adolescence of UX has been a little rough. In some ways of thinking, the parents were (for all intents and purposes) art and engineering, an unlikely pair. As such the child was pulled different ways, and during its teen years realized that, although both mom and dad were right, something was missing.

After the grammar and mechanics were basically set up, there were (and still are) a number of gray areas. Enter human-computer interaction, meaning psychology, with all its myriad subordinates like usability, color theory, semiotics, white space, page design, etc.

Code

But many (again, like myself) grew up with some type of coding, especially html. With no “UI” tools available, we built web pages with it to see and show what we were doing (and maybe retain a shaky link to our past). Soon after, tools like Dreamweaver came along to lessen our attention to the brush and concentrate more on the painting. Eventually tools like Axure came about to more or less remove the instrumentation completely and allow a purer focus on the design. This also meant less toe-stubbing on cross-browser compatibility.

But it’s worth noting two areas: one is that the learned-in-the-trenches folks already know markup, and two is that others who entered UX – say in the 2000s – may have come from the same direction or more likely would have come from the design tools (Axure, Balsamiq, etc.) direction in their schooling, but couldn’t afford such tools as contractors or while job searching so defaulted to using html for their samples.

And gladly so, since it tied with their earlier pursuits and made them appear more marketable. Possibly they weren’t decided yet on which way to go (design or development). Now add this to the plethora of hiring managers who had little to no UX savvy, but because they were engineers themselves were comfortable writing up job descriptions that included their programming comfort zone and – voila – there’s the addition of “coding” in the requirements/nice-to-haves for a UX position.

But that brings up one more level of confusion – the word “coding”. Unfortunately in our business culture (and beyond I believe) we have blindly accepted various term definitions for not real good reasons. Coding, for the IT world anyway, consists of two things: markup and what used to be called programming.

This has caused confusion in a number of LinkedIn discussions even recently. It’s easy to see why since both control the computer, but there is a very distinct difference.

Markup is just that – html, css, etc. – which manipulates the visual output. It does not manipulate data, only the data display. A programming language is used to manipulate the data itself, not how it’s displayed, and requires sequence, condition (ifs) and iteration (looping). That said, it may be used to manipulate display in a sense, such as with client-side javascript.

It is important to understand that javascript can cause some confusion here, for two reasons:

1. it is a programming language that may be used to manipulate visual output completely within the front end (web page),
2. it includes back end calls through XMLHttpRequest() (Ajax).

The idea of such calls is to access the server without reloading the web page. However, the point I’m trying to make is that any access of the server is not markup, since it manipulates data on the back end, regardless of where that code resides. Likewise web page embedded languages like asp, jsp, etc., are not markup, because even though the commands reside in the markup file, they are data control things.

Still confused? Think of it this way: there is a controller and stuff being controlled. Markup stuff is visual output, programming stuff is data manipulation. So my recommendation is to never use the word “code” alone – you are referring to either markup (html/css), front end development (asp, jsp, javascript) or back end development (java, c, etc.).

Job Descriptions

So it is left to the hiring manager whether to say “design”, “code”, etc., and whether to say that “java” or even “knowledge of java” and so on are valid requirements or nice-to-haves in a UX job description. There is generally never a need to know a programming language for UX. There is also no real need to know html/css but it can help in some ways. I know both markup and back end languages, and I can’t recall any time they have helped me create wireframes. In fact, I can recall times where markup has restricted my design a little.

This is where we need to understand that those with more experience in an expertise may help us with our design ideas – we need to stop thinking we know it all and can put it all together at the start. Here is the bottom line: if the UX designer wants a certain type of UI functionality, he/she should be collaborating with the front end developer(s) to determine feasibility. And this is what hiring managers should be looking for.

So what is the UX job description? This can be tricky. While I believe UX Architects should not be making final pixel-perfect images or creating html, they should have the final say of the overall product, including the images, navigation, page layout, copy, labels, click-throughs, etc. Why? Because those comprise the entire user experience of the product (at least the product part of the user journey), and the parts cannot be approved in isolation.

However, many believe this must be accomplished by someone with experience in “everything design”. Thus we see segregation of UX expertise components. Some, in larger companies anyway, will hire for wireframing only, others for research mainly, and so on. Small companies will want the UX person to do it all. They tend think front end is everything other than back end, which means not only designing the experience but preparing it in html/css and creating graphics, copy, etc., etc. So now this unicorn has to be a UX Architect, a front end developer, and a graphic artist.

“So what?” you say? Two problems:

1. simply put, engineers and artists think differently. I am both for example, but I only excel at one, and no one at all in my experience was able to do both well. We are humanly not wired to do both well.
2. There is an awful lot to know and keep up with in either realm, and that takes time. How thin do you think you should spread your people?

So How Much?

And this leads directly into compensation. Some UX positions are multi-brained (and therefore multi-jobbed) but are compensated as though they are just one job, and at the same time lower than that of a developer. Not to mention they are much more work (graphic artist, tester, designer, psychologist, developer, interpreter, etc.). We as a culture may want to fix that.

But the segregation I mentioned earlier may provide some help. UX Research is now thought to be a single job, as well as usability tester, front end developer and some others. The realization that these different UX areas are jobs enough by themselves is slowly permeating the market. In small companies, if the thought is they can do multiple things, how about the developers (who are generally paid more) doing multiple things, like both front and back end coding? BUT, like what should have been more of a concern for UX, the first question is does this make sense?

In Summary

My recommendation to all hiring managers is

1. to realize there are varied segments of UX,
2. none of them include front end development or graphic arts, and
3. UX can be at least as and probably more difficult than development. If you find a unicorn, that is, one that does well in diverse fields, don’t expect her to stay long.

So are there really unicorns? I would say that there are, in that some people can have diverse interests and/or be fairly good at (and interested in) varied things. But I would say very few. And although I wouldn’t want to look a gift one in the mouth, I would suggest testing the horn – it may be loose.