ux, user experience, cxm

I have come full circle. Several years ago, I wrote a personal blog entitled "What's Holding Back UX" whose premise was that pretentiousness was the mortal enemy of the UX discipline. Just over a year ago, I chose a more constructive narrative and wrote an article that identified "a spirit of inclusion" and "building more designers" as "hallmarks of greatness" for UX practitioners (while creating great designs was identified as a hallmark of the very good) -- you can read that UX article here. I have now had a first hand experience seeing the flip side of the coin and have to say that I fully understand the frustration.

At the beginning of the summer, I was asked to do some design work on a new web application for a client in the public health arena. I was paired with a developer who had not worked in a multidisciplinary environment before and had never been exposed to UX principals or artifacts. Now that the design phase of the project is complete and my artifacts have been delivered, I am left with a lasting impression best summed up in 3 words; Oh the humanity!

Emily Post's Guide To Working With A UX Practitioner

In an effort to make the workplace a better place, here is a beginning of things not to do or say when working with a UX practitioner (unless you are kind of twisted and just want to mess with them):

Protect implementation at the expense of usability -- The developer on my project had started coding in advance of design. Every review meeting was consistent. Every page in the wireframe was met with a long list of questions, each with a subtle message -- don't design anything that will take time to implement because development time is the critical resource to be conserved. Implementation time centricity will not win you any UX friends. Even on a fixed time / fixed price project, UX practitioners will not cede this point because it is antithetical to their raison d'être. Delivering a design that is known to be filled with worst practices is like shipping code without error handling -- you just don't do it.

Imply that design is arbitrary and unscientific -- One of the arguments commonly proffered when questioning the design was along the lines of "I think what I have implemented is just as usable. Let me prove it to you by showing you how I use it. Usability is just an opinion anyway and my opinion is just as valid as yours." The idea that UX is not grounded in science is offensive to experienced practitioners for two reasons:

  1. It reduces their discipline to sophistry -- Saying that a design is arbitrary implies that you are randomly throwing items on a page and that you have not done anything but "articulate an arbitrary choice" which you then sell to your clients on the basis of taste. This narrative calls the entire discipline into question by implying that we are pulling the wool over everyone's eyes and are fundamentally dishonest con-artists.
  2. It's just not true -- UX, when practiced by the book, is grounded in science. Research grounded design projects bring objective fact to bear on the subjective receptivity of target users. Even in the case of heuristic design, alternatives are evaluated and selected for specific reasons grounded in fact. How would a developer react it if I argued that the choice of a programming language was arbitrary and every language was equally applicable in all problems.

Refuse to acknowledge expertise -- Each week a topic was brought up and the debate went back and forth like a game of ping pong. In order to get the developer to stop questioning me on topics like "Why isn't a select box just as good as radio buttons for yes/no choices?" or "Why isn't showing a full list of records just as good as showing a short list that is narrowed by relevance?" These questions would go on and on, and no matter how many times I would show specific reasons why people would have more clicks or more difficulty finding what they were looking for, the debate would continue until I pulled a list of articles and videos and showed him the industry research (and sometimes beyond that too).

Good Fences Make Good Neighbors (Sometimes)

After 3 weeks of the back and forth, I wrote the detailed email below:


I believe there has been a miscommunication about the roles and responsibilities on the design portion of this project. I believe:
  • My role is to advocate for the best interaction design that is reasonably possible (e.g., reasonable = radio buttons for when choices are limited to 3 options or less and unreasonable would be to implement voice and gesture recognition).
  • Your role in the design process, generally speaking, is to articulate what my recommendations will cost in terms of time (and to selectively offer alternatives, preferably without challenging my role).
  • The PM's role is to work with the client to decide what compromises to make (i.e., if they decide not to take my advice, I won't push back. If they decide to make a change and provide extra funding and time, who cares?).

I fully understand that you are trying to protect the limited hours you have on the project and I respect that. What I believe that you are overlooking is that by questioning the validity of my decisions, you are taking hours away from me by forcing me to explain and reference external articles for why my decisions have a scientific basis.

I am not asking you to blindly implement what I propose. I am not even asking that you agree with what I propose. I am asking you instead to articulate the impact to the project and let the PM and/or the client decide which hits to take.

For example, compare:

"… adding an extra radio option into the template will burn another X hours in dev and testing and increases the risk of missing our dates by a day or two. If we stick with one treatment (like select boxes) it will be less hours and less time."

"… I don't know why you are using radio buttons when select boxes are just as easy to use. Can we stick to select boxes?"

To help you in seeing my perspective, imagine I said this:

"Why are you burning time making a POC in python when they said they couldn't use that? Why don't you start in PHP right away?"

Do you see how that communicates a lack of respect for your skill and experience? Do you see how that breaks me outside of my role on the project? Do you see how that wastes your time to answer that question constructively? Now imagine, I did that 3 times a week.

Please note, that I only just invented the above question to demonstrate to you how the email questions are being received and I do not believe that this is a question worth asking or answering.

Lastly, it is important to know that I had already suggested to the PM to give any leftover hours I had at the end to you. By consistently forcing me to justify my decisions, you are, in effect, burning extra hours that would otherwise go to you and making your time constraint worse.

It took about 2 hours to make it constructive in tone, but I will admit that it made me feel better than writing an angry email would have. After I finished all the wireframes I was able to give him about 2 weeks worth of left over hours (which did get me a "thank you"), but then I saw the finished product and found the number one way to irk your UX partner; completely ignore the design artifact and just build whatever you want.