A letter never sent urging the UX community to elevate our practice

To embrace our diversity, enable learning, and reinforce our values.

A while ago, when #designtwitter tempers were flaring and when organizations were hurting in developing their design craft, I wrote this letter as a way to crystallize my own philosophy on design, the user’s experience, and the interwoven complexities and politics that prevented the community I belonged to from getting better — and never sent it.

Now that many of us have moved on and we have more important things like global pandemics and civil rights on our minds, I can share this with you. Maybe you’re newer in our design field, and this might jump-start your thinking about how to develop yourself professionally. Maybe you’re more experienced, and my perspective may reveal to you one thing that we saw then, down in the trenches, that might help you lead even better from now on.

We’ve won some amazing successes for the people who use what we build. The people making decisions that rely on the products we built are more effective and efficient.

I feel like we’ve been sitting for a few years now at a plateau on our mastery curve, and we need something, a breakthrough, to get us to the next level in our practice. You’ve seen a mastery curve, or heard of plateaus in learning? The basic ideas is that people don’t get gradually better and better forever over time, but that new levels of efficiency or effectiveness are attained when we have breakthroughs of various kinds that enable us to do or think about what we’re doing in a new way. And the new capability we get from those breakthroughs far overshadows any small, gradual gains we might make between them.

For example, I play piano, and I can look down from the music and find the keys until I have a breakthrough and can finally navigate the keyboard by touch and muscle memory and can fixate on the music sheet. Then I can read each note individually, reciting whatever mnemonic I learned as a reference for what the lines or spaces of the staffs indicate, until I have a breakthrough and recognize chords and notes by their relative intervals instead of their individual note names and can focus on the rhythm and dynamics. I’m of course oversimplifying the mastery of the piano, but the concept of plateaus and breakthroughs is important for the rest of this document, so I hope the illustration helps. Now that we’re on the same page — .

Clearing an obstacle in our way to mastery

Back to our community, I’m not certain what the exact breakthrough will be for us, or what the next category of performance will be. But I believe I’ve identified an obstacle in our way to the breakthrough. I don’t think what I’m proposing is itself the breakthrough, but just like in my piano example you have to know about intervals and how to read intervals before you can play intervals, I think what I’m proposing will give us fluency in our practice that will enable us to experience a breakthrough together. And I believe our future breakthrough will result in our being considered integral to projects we didn’t singlehandedly capture, being materially included early in business development, and of course increasing our technical abilities — things we all want!

So here it is.

I believe that our community needs to graduate from our ubiquitous use of the term UX and be intentional and explicit with ourselves and our coworkers with what we actually are doing.

Doing this will, in turn, allow us to be intentional about what we need to learn in order to get better at what we do and allow us to be specific about how we all work together with our different specialties.

We need to embrace the diversity of our practice.

Many of our companies treat us as one specialty of engineering, and we reinforce this notion by only using one term for what we do. But you and I know that our practice is diverse and that we need diverse expertise to deliver excellent experiences for our end users.

We’ve exposed a little bit of this diversity to a select few, when negotiating for positions on projects, deciding good skill fits for projects, or when coworkers show genuine interest. But we need to take this a step further and expand the diversity of our work that we expose to the organization and establish what we do as a peer of engineering, rather than a specialty, with specialties of its own.

It will be overwhelming for our audiences, and we’re all sensitive to this fact, but we need to solve this another way than by oversimplifying what we do. We need to figure out how to do this elegantly, but I sincerely believe that we need to assert this if we want to get what is important to us: involvement.

I also think we should not allow the people who do not take the time to understand our practice to constrain how elaborately we describe our practice, because this limits our skill development. Imagine an electrical engineer eighty years ago being told not to call what she wanted to learn computer engineering because computers were the people down the hall doing the math — how could she get better at computer engineering like that?

I think the first thing that I need to point out is that I’m not advocating spending time decomposing what we do into more specific skillsets, because we’ve done that already. Instead, this is a call to more broadly elaborate the work to which we can and want to contribute, using standard terminology across industries, and in a way that makes it clear that we intend to help with those things.

Let’s use our daily terms to reinforce the diverse scope that we can work on, using terms like interaction design, information architecture, visual design, navigation design, service design, product design, human–computer interaction, storytelling, conceptual art, rapid prototyping, workflow analysis, requirements validation, deriving requirements, usability testing, etc. Remember that our point should be to reinforce that what we do is a diverse practice. Our own oversimplification of it down to two letters has created and reinforced an artificial boundary around the scope of work that we ourselves can do according to how other people interpret it.

Notice that being clear about our specialty areas means that we will have overlaps with other functions. This isn’t a coincidence, because functional boundaries are always messy, and it isn’t a bad thing anyway, because it means we belong working alongside others.

There are projects on which it is crucial that someone called a systems engineer and someone else called a design researcher both do requirements verification and validation. On other projects, it’s crucial for fostering mutually beneficial relationships with software developers that we share the responsibility of the visual treatment of a user interface. But it also means that, once we are established as also capable of doing Requirements Validation, that we deserve a seat at the table for determining how good requirements validation is to be done. Without this, we are relegated to working only within the bounds of someone else’s understanding of what we do.

We are spending too much time explaining our practice; we need to enable others to learn on their own.

Most of the people in our company don’t associate UX with anything but UI, despite our years of campaigns of educating. Nothing we’ve done has established for ourselves a durable way to break out of that misunderstanding, in such a way that we aren’t constantly requiring ourselves to explain what amounts to one letter’s difference. We know that people misinterpret the term UX, but we can’t, realistically, expect to get significantly better at our craft when our free time is going to “educating” others about the basics of our work.

It’s been a sticking point on many of our projects that the project’s technical lead is obligated to task or supervise the human-centered designer, but does not have sufficient understanding of how we work and what we work on to risk losing face by giving us irrelevant tasking. So, instead of risking embarrassment, the lead will leave the designer alone or require them to come up with what they need to do, even if the designer is more junior and not capable of making those decisions.

What doesn’t help is that if the technical lead is bought-in to the value proposition of “UX,” it’s nearly impossible for them to do a Google search for our terminology and walk away with a clearer understanding of what we work on and how we work. While a handy catchall and shorthand, contrast the clarity of tasks and outcomes described in the Wikipedia articles for interaction design and user experience above the fold.

(At the time of uploading this letter to Medium, the Wikipedia article on User Experience even features the maintenance banner requiring cleaning up the article at the top, saying “This article may be confusing or unclear to readers.”)

The first defines purpose, outcome, and what can be expected from the work: “designing interactive products, . . . how a user might interact with it, . . . software development, . . . its main area of focus rests on behavior.” The latter provides only a definition of what we mean by the subjective experience of the end user before the text becomes esoteric and difficulty for someone who isn’t an expert in our field. The unfamiliar reader is left wondering, “Yes, but what do they do?”

In short, it is easier for me, if I am a technical lead, to ignore or isolate the designer than to take time out of my own business to educate myself enough to be able to involve and include the designer on the project. This should be alarming to our community, because it means that it is incredibly expensive, politically, for someone to become an advocate for our practice. Without advocates, we have to be our own champions, and our influence is capped. Instead, we need to enable people to be our advocates by equipping them with terms that they can learn about and discuss with us.

We need to be open about how we get better.

The last remaining point to make is that the human-centered specialties are diverse, not mutually exclusive, and nuanced. And some of you will be frustrated by how the relatively young age of our practice is reflected in the ongoing debate about terminology of skills, titles, and scopes of responsibility.

As we gain depth and breadth of expertise, these overlaps and nuances become unimportant to debate, because we attain a working knowledge of the differences, even if we individually prefer one term over another. And mutual exclusivity within taxonomy is a feature to assist people’s assimilation of the meanings and not inherently necessary. I encourage you that it’s more important for us to move forward in expressing the diversity of our work to our coworkers and programs and not wait for the community to figure everything out.

With that, I would like to make some suggestions to start us off.

My Recommendation

Before anything else, the use of UX for our work has created terms that, while whimsical or lighthearted, hurt our credibility: a “UXer” “does UX” or, worse, “UXifies” the product. We must refrain from using these terms that weaken the maturity of what we do.

We must use our language to constantly reinforce our values.

More importantly, the way we are currently using the term UX is undermining our core values. For example, we as the project performers do not “do UX” as if we own the user’s experience, that is, in the sense of it being under our jurisdiction or being our property. Rather, the user’s subjective, human experience is theirs and only theirs to have and own.

Neither do we “design the user’s experience” (consider the term UX Design) because we do not directly make someone else feel something. Taken to the extreme that we must explicitly avoid, we do not employ dark patterns to manipulate someone’s feelings or behavior against their will.

Third, but more subtle, we do not “deliver user experiences,” as if the user may unbox something given to them. In other words, if we can replace UX with UI in the sentence and it still makes sense, then we’ve simply reinforced the confusion between the user’s experience and the user interface.

It will take intent and specificity to identify terminology that adheres to our core values — that our job is about influencing other peoples’ behavior for their own benefit, that humans bring unique and valuable potential to their purpose that must be maximized, and that that we are not our user.

Our terminology must reflect that we work with human behavior that we cannot control and we choose not to try to control. This is the value that we bring to our organizations, and it is important that our words reflect this. The brand of UX reliably introduced and reinforced awareness of the end user, even if people confused the term with the user interface. It will be critical to have the people for whom we design front and center in our language.

We must be intentional and specific in our language.

Let’s get specific, keeping in mind the intent described above. We want terms that people can research on their own, which means for which there is at least one established definition by experts that can explain things more clearly than we can. (Note that this is not an invitation for comparisons between experts, because we need to move forward.) If we want to have authority over requirements like engineering has, then we need terminology that reflects the maturity of what we do like engineering’s terms do and we need a clear verb. We need mature terms with meaningful verbs for what we do. We need terms that reinforce our core values. We do not need to worry about overlaps, nuance, or mutual exclusivity of terms.

I strongly recommend that design be the verb that our practice uses generously. It’s the most common of the terms in the list a few paragraphs ago, it’s not engineering (that’s a discussion for another time), and our cross-industry community uses design this way. I recognize that, when we were saddled with the UX brand, design often referred to illustrating the decisions, and was a counterpart to research: UX Design and UX Research were common terms we used. So then if we exercise restraint against using the term UX for the above reasons, and forcing ourselves to be intentional and specific about the diversity of our work, we should free ourselves to use the most appropriate and researchable terms for what we do without agonizing over the nuances, overlaps, and titles. This is not a problem we will solve within any one company; the best thing we can do is use appropriate terms and references that people outside of our community can investigate themselves and arrive at an understanding.

In an effort to preserve our intent of design as the verb describing what we do, it will help if we eliminate, at least temporarily, using the term design as a noun, as in “I drew up some designs of the UI.” Maybe this can come back later, but while we’re crystallizing our terminology and challenging ourselves to be intentional and specific, design as a noun is easily substituted for a variety of terms like illustration, depiction, rendering, representation, wireframe, or simply drawing that are all more specific. This will also serve to put some distance between what we do and popular concepts like Fashion Design, from which we derive the bias that led the old term UX design to refer exclusively to drawing, as it is in fashion. Reserve the word design for when it is most important, for which there is no better word, which is in reference to the function we perform of converting needs into plans. Then we can together get over any elitism of thinking what any one person does is more important than another.

The top-level term, therefore, is Human-centered Design. The reason why it’s not user-centered design is because we can still do our work when there aren’t users, formally, but all of our work is about humanizing our organizations and our technologies. Again, this is about the diversity of the practice, so we need an all-encompassing term. The alternative that other organizations use is design thinking. However, this typically refers to the methods and mindsets of human-centered design when applied across business functions, not the function of human-centered design itself.

Jesse James Garrett’s terminology endures after almost 20 years. He gave us many definitions and wrote the book on them. Here are ten more specific terms that we can use in order to describe what we do:

  1. Site Objectives Definition
  2. User Needs Research
  3. Functional Specification
  4. Content Requirements Definition
  5. Interaction Design
  6. Information Architecture
  7. Information Design
  8. Interface Design
  9. Navigation Design
  10. Visual Design

(List from http://www.jjg.net/elements/pdf/elements.pdf.)

Certainly there are others possible, like Functional Analysis (not coincidentally this means the same that INCOSE intends engineers to do) or Content Requirements Analysis. Again, we should be specific whenever possible about our activities — that is, to differentiate between when we’re doing requirements definition and requirements analysis — because our practice is broad, with numerous specialties.

This is just an example of specificity. There is also discussion about what do we do with the term UX in the context of design research or job titles for design. With the above principles and examples, I hope to start this conversation and equip us with a fresh perspective from which to begin talking about these important issues to our craft.

Thanks for reading this letter never sent. Its admonition is, for the most part, overcome by the progress our practice has seen in the years since I wrote it and our collective attention elsewhere. I hope the perspective is helpful to you. Never forget that everything is connected, and always think about other people. ❤

Written by

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store