I’m always uncertain about those who are so very certain.
I recently have been following a discussion thread on LinkedIn – not too closely because I find most of the forum discussions a waste of time. They are generally filled with blowholes (I occasionally fall into that category) who seek self-gratification through speaking to a group who largely agrees with what they write and then subsequently wallowing in confirmation bias. In short, they usually are not productive conversations or true dialogs to understand the meaning of a concept or possibly come to a greater understanding of an issue. Rather, they usually begin with one belly ache that, in turn, spawns a litany of similar howls at what grievous offense has been brought to light. The grievous offense in this instance is none other than the infamous job description. Specifically, this forum started with a comment concerning how UX job descriptions are often written with a coding experience requirement in them.
The comment, and I quote:
“I’m sure many of us who read the job postings here on LinkedIn (and elsewhere) are irked when we see the title UX Designer and then read the description to find that it requires coding skills. Would it be to our advantage to add a comment to these postings to let the ill-informed recruiter know the posting would be better served if it were titled as DEVELOPER?”
First, the job description doesn’t come from the recruiter. It comes from the organization. But, I’m not sure this is a legitimate question the person who started this thread sought an answer for anyway. The best response for this forum would have been a simple “Yes” or “No, it wouldn’t be to our advantage.” But as anyone who has ever followed or participated in one of these forums probably knows, it’s never a simple yes or no answer. The single question quoted above spawned a litany of complaints about outlandish job listings usually followed by some “expert analysis” of what the profession is. Ironically, it seems many members of the forum had their own flavor of what UX is – no doubt influenced by their own experience in the industry.
To be fair, many members of the forum are professionals in the industry and had valid comments / complaints. And, the primary complaint which involved adding coding / scripting to the job description is arguably a valid complaint. However, my issue with the general theme of this forum is twofold.
First, I am uncomfortable with flat out certain statements that a UX Designer should never have the responsibility of coding in his or her job description. Despite all the lamentations against UX Design position descriptions requiring coders, these people do exist. See Jared Spool’s recent article: Becoming a UX Unicorn in 5 Easy Steps.
Moreover, a lot of the UX jobs ask for HTML / CSS skills, which really isn’t a stretch or that hard to learn in terms of languages. But, I think it is important to underscore how dangerous it can be not to define UX (which I think is a noble endeavor), but to draw rigid boundaries around that definition. I find it frustrating that the profession is stifled by both organizational ignorance and the dogma of many of my colleagues. All of the positions I have worked require different skill sets and yet have essentially the same title. Forcing the profession into a “cookie cutter” definition of what we think it should be or what an organization thinks it should be – well, those are both equally change inhibiting. This is a profession that will continue to grow and flourish. What we call a UX designer today may very well be something completely different in 10 years. Ultimately, I tend to shy away from strict definitions and find they suffocate professions in many instances. Strict definitions also allow us to become comfortable, resist change and ultimately stop growing.
The second aspect of this whole thing I am uncomfortable with is the very idea of critiquing a job description. The original slant of the thread was that it wasn’t fair to include developer roles (i.e. coding abilities) in a UX position. But, the thread later spiraled into a huge bitch session of all the things that should or should not be in the job description. It seems the members of this forum are of the impression job descriptions are accurate representations of what a person will do once they accept the position. Vincent Zembruski – whose title is, ironically, Sr. Business Systems Analyst and not UX – believes the description must include user research or usability testing. But, I have worked no less than 3 jobs that did have that in the description and yet did no user testing or research. Those jobs primarily involved interface design. To posit that you cannot design an interface without first consulting the user while still employing good usability principles is preposterous.
Richard Woznicki rules out graphic design and coding in his comment. But, I have worked with a lot graphic designers who have turned interface designers. The level of their work is usually of higher fidelity which makes it much easier to communicate design. I understand what Richard is getting at in his post, but this rigid thinking ignores the multi-disciplinary nature of our field and the fact that many of these job descriptions are not created independently of that multi-disciplinary nature.
To my earlier point: The illusion that a job description accurately represents what you will do once you set foot in the organization is predicated on the assumption the hiring manager knows exactly what the position will entail or the HR representative who wrote it knows what the organization needs. This is often not the case and there is a certain amount of molding done in most positions where the new employee’s strengths are used to fill obvious gaps in organizational processes. And thus the position changes slightly here and there – morphing to fill organizational needs. This is an ideal situation, but does happen if you hire the right talent and structure the role for adjustment. Nevertheless, it is highly unlikely the job description is much more than fifty percent accurate in the first place. This is evident from the number of recruiters who tell me the requirements are “flexible.” Comically, I have worked for a number of supervisors whom I was sure after several years still did not know what my job entailed. How do I know this? After providing notice, I watched the mad scramble to figure out what I had been working on.If the boss doesn’t know what I am working on, how can they write a job description with anything more than vaguely constructed sentences full of industry buzzwords.
All of this really boils down to defining what UX is or is not. Anyone who is certain they know what it is and is not, should be viewed with utmost suspicion. As I write at the beginning of this post: People who are certain, make me uncertain. I think UX is an emerging profession and whether many in the profession like it or not, emerging professions often take some time before industries understand what they are and how they are useful. So perhaps my colleagues would better serve our profession by writing posts such as this rather than howling in closed forums. UX is currently a multidisciplinary field growing its legs. And while I will certainly devote a future post to exploring the history of the field and where it is today, at this point I can only say: Give it time.