UX designers must own design judgment

This post captures and refines a Twitter thread from 2017.

---

Let's talk explicitly about user experience designers’ ownership of design judgment.

As a UX designer, I am happy to lose a thousand arguments over what the UX of the product should be because of other considerations. “Let’s make this compromise to the UX so we can have it ready in time for the Big Trade Show.” I may believe that any number of these decisions that compromise users’ experience in the name of technical convenience, marketing advantage, or whatever are wrong for the product, but that’s okay, balancing all of the competing priorities is not my job. (This is product management’s job, by the way.) Indeed, heaven forbid UX designers always get their way in shaping the product. That would be unbalanced and wrong.

But I hate having an argument over what serves users best. If a PM overrules me saying, “no, the users will like it better if we do X instead,” that is a deep professional insult which is bad for the development process.

That does not mean I don’t want others to bring their UX design ideas to the table. I have proudly stolen UX ideas from programmers and PMs and marketing folks and others countless times. But saying “you’re right, that is better for users” is my call as designer. If judgment about what is the best UX is not located firmly in designers’ hands, that diffusion of authority means spending organizational energy on discussion and persuasion and “spinning” about it, instead of the other hard work and hard decisions which must be done.

I am not claiming designers’ judgment is perfect. We should always implement UX in a spirit of experiment, looking to learn where that judgment was surprisingly right and wrong. But wasting energy second-guessing UX designers is a bad mistake. Even if your designers don’t have superior skill and talent to the rest of your team (which they should!), they are the only ones spending all day every day thinking about their domain. That should mean they can be trusted to be more reliably correct about it. If your designers’ judgment really is weak enough that trusting their judgment is too risky, then the remedy is that you fire them and hire someone else.

On their part, UXDs must be forthright and honest in discussing implications of UX options. UXDs must equip product management with a clear appraisal of what is most important; deciding among compromises to shape the product is PMs’ job. “If we do this to make it easier to build, that's a usability sacrifice on mobile, but users should be understanding about desktop being better for this function.” A UX designer who is a proper professional will not sandbag, saying every little compromise to UX is the end of the world. A sandbagging culture will severely compromise an engineering team — they hate lies and will feel constantly disoriented by it — and it will crush designers, who cannot deliver anything if we cannot tell the truth.

In the long run the ethos I advocate here leads to better UX results. Sure, there will be occasions when other people in the org turn out to have been right when the UXDs were wrong. But most often UXDs will be most right about UXD. Play the odds.

More importantly, when you do not simply accept UXDs’ judgment in their own domain, you have added work for everyone to do. Designers need to persuade everyone on the team that they know what they are talking about, and everyone else bears a burdern of responsibility for evaluating that. It should be UXDs’ responsibility to work to persuade stakeholders that good UX is good for the product; but if they must also work to persuade everyone that their proposals are good UX in the first place, that means time & energy absorbed by that persuasion instead of thinking about better solutions: stakeholder involvement theatre, user research theatre, slick presentations, et cetera.

I don’t want to dismiss UXD communication in this critique of UXD persuasion. Making clear how and why a UXD solution works the way it does is a demanding and important part of the work. This clarity is different from selling.

Nor do I want to blur the distinction between what UXD is right for the product versus what UXD is right for users. What is right for the product is a contentious question, informed by multiple stakeholders, owned by product management. For this to work, UXDs must confer with and serve the team, and must recognize that since the UX is the product, product managers decide what UX to build.

UXDs must own the narrower question of what is right for users. It is not just because it is insulting and demoralizing to present design work that took a few weeks of skullsweat to prepare and have someone look at it for ten minutes and say blithely, “No, we are going to do it another way because I have an idea which I am sure is better for users”; I would counsel that designers swallow their pride and roll with having their expertise disrespected if I thought it was better for users or better for product success. But it isn’t. Designers serve the organization when they demand their ownership of design judgment.

UX designers must advocate for clarity about this distinction between UXD judgment about users’ needs versus UXD decisions about what serves the product as a whole. We must own the first thing, and advocate vigorously for product managers owning the call about what UX actually gets built into the product.

Examples

After the initial thread, I added references to commentaries by others which I found topically relevant.

Wouter Walmink comments:

Amen, and that goes for all roles in a product team. I’ve experienced the best teamwork when each member's ownership and authority of their domain is respected by the others (and everyone understands that this doesn't mean always getting your way).

Yes! It astonishes me how often people read me as arrogating some kind of godlike wisdom and power to designers when I am advocating for nothing more than giving every role in the team ownership of their appropriate domain. Nor am I advocating designers isolating themselves from the rest of the team; I am advocating deep engagement with an expectation of professional respect.

Pavel Samsonov, one of my favorite design commentators, has a great comment about why I harp so often on the distinction between designers’ ownership of design judgment and PMs’ ownership of product design:

Expanding a design org always threatens incumbent power centers. People unfamiliar with how design works will defend their own authority and ways of knowing.

For this reason, it’s important to explain not only what you want the design org to do, but also what it will not do.

“Design is making decisions” is confusing to stakeholders who see it as a power grab from the picture-drawing people. Unless you have the power of a huge consultancy behind you, you probably won’t be able to convince them that they have been designers all along.

Designers are no more CEOs than PMs are. When jockeying for the “seat at the table” it’s crucial to show that you’re not taking over the entire table. Even though UX is affected by everything from backend tech to the business model, a tight initial focus will be an easier sell.

Erika Hall of Mule Design, another designer I greatly admire, observation about resistance to the role clarity I advocate:

One of the snags is that explicitly defining roles and responsibilities can be very uncomfortable to guess culture people in the relevant domain. Being able to guess is often seen as a proxy for care, concern, and expertise in that domain/membership in group.

Scott Berkun, whose book How Design Makes The World I vigorously recommend as an introduction to What Design Is, offers a good description of my point about the distinction between UXDs’ and PMs’ roles.

Product managers confuse revenue with design quality. Product designers confuse design quality with success.

Asked another way: Can the marketplace really decide what is the best design for something? We assume yes, but forget how many factors impact popularity that are unrelated to quality: marketing, hype trends, timing, biz partnerships and more.

(And I must note that revenue is not the only product success target: clearly naming what “success” you want is executives’ job!)

Berkun also has a good meditation on the pragmatics of designers needing to communicate to non-design colleagues persuasively about our work and our role, and our frustration at how much of that we must do. We must live in the world we have while we work for a better one.

Designers are hired to change things. The challenge is we want change on our terms, using our methods and beliefs. This creates a natural conflict with coworkers and executives. It makes sense that designers feel ignored, misunderstood or even lost.

Miriam Isaac observes how designers often confuse their correct frustration at having their design judgment dismissed by the organization with a need to get positioned to control product decisions:

Sorry to tell you this my dear designer, but becoming a product manager will not solve your problems.

Most designers think if only they became a PM they would finally be able to design in the way they see fit!! But in actuality, it will take them away from the craft they dearly love.

They may just need mentoring in articulating design decisions and how to lead / advocate for design in their company. Most designers think if only they became a PM they would finally be able to design in the way they see fit!! But in actuality, it will take them away from the craft they dearly love.

Shreyas Doshi has a few tweets about what UXD expertise entails.

While scrolling Twitter it’s easy to forget that a typical product team makes 100s of micro-decisions about the user experience & trade-offs. It is impossible to validate every one of these with user research, metrics & tactics. That is why Product Sense is such a vital skill.

Product Sense = Cognitive Empathy + Domain Expertise + Creativity

Domain Expertise arises from hardwork, interest, general IQ, openness, and experience. Experience is a major factor there.

Experience plays a role in Cognitive Empathy & Creativity, but it is a much smaller role.

I believe every product person can (and should) get much better at Product Sense, and every product person can get very good at Product Sense. Though to be really great (say top 5%), the innate factors are critical. Just like not everyone can be a great artist, musician, etc.

Looking at replies to it, I find it heartbreaking to see so many people not only unable to imagine having their professional expertise respected, but unable to conceive of it as a possibility.

This tweet from a good thread by Louie Bacaj offers a deeply frustrating framing of a good point:

As a software engineer, you are not there to take requirements blindly. You are there to partner with your business and product partners. That means you have to earn an equal seat at the table on product decisions.

A software development professional should not have to “earn” a seat at the product definition table; respect should come with the job. And roles at that table are not simply equal; they have different authority and responsibility.

Matt Murray makes a tragic observation about energy wasted on justifying one's professional expertise.

Yeah, one day it hit me — I’m an outside consultant. The person who got the funding to bring me in must have made a successful case for the value. So why is most of this project just decking up my reason for being here?

The inspiration

The thread which became this post was inspired by discussion emerging from another tweet, me saying:

When you say “everyone on the team is responsible for X” I hear “nobody on the team has ownership of X” and “expertise in X is not valued”

Patrick Sauerwein replied:

Misinterpreted, the world is not black and white. It’s shared ownership and responsibility and everybody should take care of this. And this doesn't mean that expertise in X is not valued.

I responded:

People say that. In my experience, it is generally not true.

Sauerwein replied:

Sad to hear. The best example I heard is with code ownership which is a shared responsibility for those who have the expertise to contribute. So why should writing code not be valued?

I responded:

The example in my mind is UX design. As a professional UX designer, it usually means that since “everyone” has “responsibility” for it I am just one vote at the big round table.

Sauerwein replied:

You’re the leading “dev” expert in the team with the best experience. Don’t interpret that hard, as mentioned it’s not black or white. Go and lead the team in UX, your role is very important to the team and it’s outcome. Educate, consult and lead UX.

I responded:

My point is that I end up spending a lot of time and energy at those big round tables persuading others that my design judgment is good. That is a waste of attention that should go to me actually solving design problems.

Henrik Johansson <@dahankzter> replied to that:

What if there are other experts as well? Often there isn't just one expert per area

Which Sauerwein underlined with:

Might be the case, in our discussion there is one expert not heard and valued. Challenge in UX: everyone has an opinion. Leading and fighting for your way is hard work.

And Johansson built on that:

I agree that fighting for your idea is hard sometimes but if no one ever challenge the status quo there will be little evolution. UX is special just because everyone knows a lot in the sense that we all use a lot of software. Maybe authority is good here.

I responded:

I am wary of the suggestion that “everyone knows a lot about UXD”. Many people think they do. But people who are not specialists typically have terrible judgment, which is why so many things have bad UX!

Johansson replied to that:

But UX is connected to visual design and thus taste. If a stakeholder doesn't like it esthetically it doesn't matter if it's sound UX. This applies to everyone on and off the team which is why communicating the general idea, architecture if you will, so that understanding exists

I said:

I could not disagree more. If you think UX design concerns “taste”, I conclude that you do not understand UX design.

Johansson replied:

Ah come on! A useable feature is often also a beautiful feature and that even before considering pure design elements. Saying that UX is completely orthogonal to taste is just plain wrong.

I commented

Saying that UXD is not a matter of taste is not saying that it should not be beautiful.

Johansson replied:

And beauty is in the proverbial eye of the beholder and thus taste.

Frustration with that exchange spawned the main thread which became this post.

---

I am proud that Marcel van Remmerden, Gitlab’s Senior Manager of Product Design says that this framing of UXDs’ ownership of design judgment is “so powerful and clear that we added a section in the GitLab UX handbook” referencing it:

As Product Designers, we are the owners of design judgment.

We start with a problem to solve and always first consider what the best experience for the user would be.

If we get additional information about constraints or context from counterparts (e.g. technical considerations or a marketing advantage), we take that as input and evaluate together if and how we need to adapt our designs. When these constraints have influenced our design proposal, we communicate proactively about the fact that these constraints exist, how they changed the design, and what impact these changes will have on the user.

If our counterparts have a different opinion on what will serve the user best, we evaluate if that's correct and how it will change our design, but we are empowered to make the final call on this question, as we are the owners of design judgment.

Identifying UX needs to aid Product Management prioritization

To support the Product Management team with their prioritization, we give them our input for UX needs. This could be both for quick wins, as well as for larger strategic initiatives.

Agile and UX design

A Twitter rant

First, a capture and refinement of a Twitter thread from September 2020:

Doug Collins asks:

Do #UX and #Agile really mix? Why or why not?

Nick Finck responds:

Agile is a way of thinking that was turned into a process. If you read the manifesto you’d think “sure this works with design” but somehow the execution (process) was misunderstood as “shipping fast” thus compromising quality & effectiveness of good research & design.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

I think there is a lot of implicit hostility to UX design in the Agile Manifesto.

“Responding to change rather than following a plan” accepts — commits to! — a world in which there is no way to out-think the tendency of “customers” to have “changing requirements”.

I see Agile as a response to software development teams getting jerked around by a failure of leadership to deliver clear, consistent product / service direction. “Fine. We will release attachment, and just get good at thinking short-term and responding to capricious direction.”

A lot of software developers have had their fingers burned by half-baked attempts at UX design. They tried it with the wrong people, incentives, or timeline, and reasonably (but incorrectly) concluded that the coherent vision UXD promises is simply impossible. The Agile Manifesto rests on this assumption that this clarity of product vision is impossible, or at least doomed. Most folks in the industry simply cannot conceive of what good UXDs can do given time and opportunity.

But a dev org still must decide what the product / service / process will be & do. Agile culture locates this in a “product owner”. The PO is expected to deliver clarity & direction ... which is the thing that is still missing from most projects and organizations.

I believe in the product owner role: it is what product management should do, properly understood. Good product management is, in my humble opinion, the most important thing you can do to get products with good UX design.

Even with all those hesitations, as a UX designer I love a lot of things about the Spirit Of Agile. I want to do UXD with a spirit of experimentation. I want to solve the countless onesey-twosey challenges in conversation with devs instead of through a formalized process with heavy documentation.

But I also know how powerful it is to step back with one or two colleagues and spend time — weeks, months — to sink deep into wrestling fundamental product design questions to the ground and pre-visualizing them well enough that everyone is clear on what we want to make.

You can make a film Mike Leigh style, workshopping with actors with a camera running until it turns into something, and get magical results that way. But most movies start with a nerd or three writing a screenplay, and maybe drawing storyboards, before the expensive production.

Agile reflects a pragmatic adaptation to dev org leadership not merely abdicating their responsibility, but in many cases being actively hostile to anyone trying to take it on. UXD seeks to deliver an instrument which enables responsible leadership giving clear direction.

To my mind, the core tragedy of Agile is that it simply accepts the abdication of responsibility by organizational leadership. There is a lot to admire about Agile methods, but there is only so much one can do for the Titanic from inside the engine room. Someone needs to stand on the bridge with a map.

Resources

Criticism of Agile

Agile As Trauma

My favorite single commentary on the subject: it says a lot of things which I had long tried to say better than I have ever managed, plus a lot more.

The Agile Manifesto is an immune response on the part of programmers to bad management. The document is an expression of trauma, and its intellectual descendants continue to carry this baggage. While the Agile era has brought about remarkable advancements in project management techniques and development tools, it remains a tactical, technical, and ultimately reactionary movement. As long as Agile remains in this position it will be liable to backfire, vulnerable to the very depredations of bad management it had initially evolved to counter.

#AgileKillsKittens (or Agile In Their Own Words: The Problem With Agile & Scrum)

An index of numerous critiques.

Agile and the Long Crisis of Software

An analysis which covers a lot of ground.

What I discovered was a long-running wrestling match between what managers want software development to be and what it really is, as practiced by the workers who write the code. Time and again, organizations have sought to contain software’s most troublesome tendencies — its habit of sprawling beyond timelines and measurable goals — by introducing new management styles. And for a time, it looked as though companies had found in Agile the solution to keeping developers happily on task while also working at a feverish pace.

Why Agile Is Losing Steam

A tidy overview of core problems which critics like me foresaw ages ago.

As UX desperately tried to counsel Agile (and failed): 1) The name of the game is achieving outcomes that create bidirectional value for users and the business; 2) outcomes are achieved by making smart design decisions; 3) impactful design decisions are typically made well above the level of product teams; and 4) real design work and having an impact are therefore inherently political in nature. Agile’s response, sadly, was to scoff at this, double down on the error of tailism, and insist that the solution is always “more software”.

Agile vs Waterfall And Other Obfuscations

A word about how agility is of course good … while Agile-in-practice tends to eschew the well-considered-plans-held-lightly which enable agility. I am honored to be quoted there, in very heavy company.

Executive Responsibility, UX Design, and Product Management

A commentary of mine which picks up on the problem identified by Agile and offers the integration of a strong UXD practice into software development organizations as an alternative solution.

From Agilists

The History Of Agile And Its Manifesto

An index of resources which I found by way of Christina Wodke, who pointedly observes that the folks indexed there are all men for some reason.

Why Agile Needs To Take Over Management Itself

An instructive comment about how orgs have resisted any of the deep cultural, role, and process changes they need. But. It contains not one word about users or designers. It complains that “Agile” has had its meaning corrupted, but offers no explanation of what the correct meaning is. Terrifying to a UX designer like me.

The larger the initiative, the more PM will reside above the level of dev teams. To raise the agility ceiling, then, UXD must be similarly raised. And yes, this higher-level UXD work will largely take the form of research. There is a bizarre irony in rejecting such upfront research as being somehow anti-Agile “BDUF” (Big Design Up Front).

Project negotiation

A Twitter thread from Alan Holub which reflects the best of Agile’s spirit, which I genuinely admire … and shows how Agile reflects an adaptation to management’s fundamental distrust of developers and disrespect for what they do and how they do it. I tend to think of Agile as primarily an adaptation to challenges in development projects by corporate IT, but this says some interesting things about the problems it addresses for consulting / contracting development teams.

A traditional “agency” contract is adversarial to its core. You argue about price, you argue about scope, and as the work begins, you argue about changes (and argue more about scope and deadlines and cost). The agency is worried about going broke. The client wants work that they don’t pay for and gripes about paying too much for work they can't see. The negotiation is constant, unpleasant, and an expensive time sink. The risk is very high. It’s a war.

Compare that to an Agile contract, which is about collaboration. We collaborate on what to do first. We build it and collaborate on the details as we build. We then collaborate on what to do next. We deliver frequently so the client knows exactly what they’re paying for. We get paid for the work we do, and the client doesn’t pay for things they don’t need. It's a fundamentally social arrangement. There is very little risk.

When Agile Manifesto is talking about collaboration over negotiation, this is what it’s talking about.

An agilist on UXD

Rob Donoghue responds to “I also know how powerful it is to step back with one or two colleagues and spend time — weeks, months — to sink deep into wrestling fundamental product design questions to the ground”. (I wish I had a link to the source! My page is now the only version I can find.)

So, turning this one over, because when I think about the list of challenges to working with UXD, there are a ton of antipatterns I have to go through first before I could even judge the interaction with agility.

Yes I remain optimistic.

So, here’s the question I’m dwelling on: Is UXD substantially different than other fields which benefit from deep expertise, time and focused work before picking up the tools? How does it compare to architecure, or other fields of design in this way?

And to be clear, I don’t really have an answer - they seem similar to me, but that's from the outside, and I’m sure there are nuances I miss.

On the design front, I am much more likely to encounter situations where design resources are stretched so thin that all the good intentions in the world wouldn’t get us the kind of deep thought it would deserve. But architecture is something we can do. Sometimes.

And agile hat on, it kills me when we don’t do that work or take the time to do it. It makes the work feel like walking on thin ice, and it’s not the push for working in sprints that keeps it from happening.

Now that gets me thinking: One of the reasons we at least carve out a space for architecture is that it’s already in the wheelhouse of the devs, at least in theory. Other areas of deep work don't get the same attention, and some of that may be an agile problem.

Not because of any intrinsic resistance, but because of the emphasis on cross functional teams. As much as we love to talk about stacks, the reality is that deep domains also tend to be specialty domains, which are hard to fit into a cross functional team.

This shows up a lot with designers. It might be great to embed a designer in the team, but it’s only cost effective in certain situations, so we build weird half measures to try to include design, but it's usually flawed.

Same is true of almost any specialist.

What you sometimes see is that in attempt to be cross functional, you get people who might know a little about a given discipline. Sometimes that works out ok, but in some fields it's arguably worse than nothing.

Now given all that?

I’m honestly not 100% sure what agile + UXD should look like, because my experience is with only half the formula. But that experience tells me that the main blockers are just knowledge and intent.

(But I’m also optimistic).

Executive responsibility, UX design, and product management

This bit from Jim Highsmith’s essay 18 Years Of Agile Manifesto For Software Development #1: History provoked this post:

This type of situation goes on every day — marketing, or management, or external customers, internal customers, and, yes, even developers — don’t want to make hard trade-off decisions, so they impose irrational demands through the imposition of corporate power structures. This isn’t merely a software development problem, it runs throughout Dilbertesque organizations.

Absence of clarity

Highsmith is not the only person to read Agile as an adaptation to software development teams getting jerked around. “If we cannot get clear direction then we have to work in a way that makes the churn less painful.”

When we talk about “hard trade-off decisions” which software development orgs avoid, we typically think of stuff like feature prioritization and allocation of time & resources. But the tendency to look away from those tactical choices flows from vagueness at a more strategic scale. An absence of clarity about product intent (what should this thing be?) and development plans (how shall we create & deliver it?) produces tactical churn. Organizations grounded in strategic clarity suffer less churn, so they do not need the radical flexibility which gives Agile development its name.

Fred Brooks put his finger on this in The Mythical Man-Month half a century ago, and what he said then remains true: software development requires thinking very clearly about what we want and need a system to do before we try to build it.

I submit that software managers & executives have generally abdicated their responsibility in failing to produce and maintain that clarity. This happens because, as Brooks describes, clarity is hard.

The industry generally operates as if clarity is not merely hard but impossible. Resulting norms reïnforce churn & confusion rather than resolve them. Agile accepts these consequences as inescapable … then in actual Agile practice, the appetite for clarity re-surfaces anyway, as we see in Scrum’s dream of a Product Owner role.

The parable of the architect

Agile reaches for clarity by building; the “waterfall” processes Agile derides often do much the same thing in practice.

Software development does not much resemble building a house, but we can get away with a loose analogy:

Imagine a world which builds houses like we build software.

A person who wants a house would go to a building contractor who would ask for a feature list. How many doors and windows? How many kitchen cabinets? How many stairs?

Then the contractor would get to work: pouring concrete, cutting wood and steel, et cetera.

At the point when the house is half-framed, the contractor would bring the future occupant in for a first look.

“Why is the bathtub in the kitchen?”

“Well it stands to reason with the plumbing. Is that a problem?”

After the resulting heated exchange, the contractor would walk away shaking their head thinking, “There you have it again. Customers always change their minds about their requirements because they just cannot name their needs until they see something mostly built. You have to expect these disruptions and roll with them as well as you can.”

Every house would end up looking like it was drawn by Dr. Seuss.

An architect from our universe would try to help, but would seem crazy to the people in this world. “You want to draw up ‘plans’ first, before we start construction? You are dangerously naïve! Who can afford that extra time and expense? Don’t you know how customers’ ideas constantly change?”

The software industry needs a practice comparable to architecture.

One may protest that we already have roles not-coïncidentally known as “software architects” or “system architects”, but these do not address the bathtub-in-the-kitchen problem. To solve that we need a visualization of the user experience of a system, analagous to a building’s blueprints, before we even start to build it.

Skepticism about UXD

Why don’t software development organizations make some kind of user experience “blueprint” first?

We do not reject doing it. Like the people in the world of Dr. Seuss houses, it does not even occur to us as a possibility to reject.

If one had never encountered someone with perfect pitch, one would never depend on having someone identify musical notes. Visualizing the user experience of a system which does not yet exist depends on a comparably surprising knack.

The few people in the industry who have seen attempts at making such a “blueprint” know that most fail. Doing deep UX design requires not just the knack but subtle skills & processes which differ greatly from other practices in the industry. Without all of that lined up, a UX design project fails before it even starts.

Plus people in key roles have their own hesitations.

Programmers

The common expression “UI/UX” reflects an assumption that “design” means wrapping an “interface” around a system which programmers define. Programmers therefore tend to read proposals to do deep UX design as intruding into the the work they do on the system. Even if they do appreciate deep UXD, hard experience teaches them to doubt that it will protect them from churn as the organization calls for changes.

Programmers feel such responsibility for building a good system in the face of the usual clumsy, shifting, ill-conceived direction that they are notoriously stubborn in resisting plans which they fear will compromise the quality of their product. They have every reason to expect designers to deliver yet more bad direction just as Marketing and executives too often do. The word “designer” often reads to them as meaning an artsy fool dangerously naïve about what is easy, hard, and impossible to implement … which proves true all too often.

In my long experience as a UX design consultant, once I deliver deep UXD it thrills programmers. At last someone offers the clarity they have always needed to plan and work effectively! But that opens another challenge. When programmers with deep UX design in hand say to marketing, management, and executives, “when you give me direction it should come in this form”, it creates political complications ….

Executives & managers

Even if one can persuade executives & managers that deep UXD is possible, its methods are sound, and it supports them in making decisions, they hesitate over the scary changes to organizational structures & processes which it requires to leverage properly.

UX design takes time to prepare before setting programmers to work coding. This feels like an expensive delay in an industry which conceives of “making software” as programming. Though UXD saves time by avoiding bathtub-in-the-kitchen problems, skipping unneeded functionality, and easing other frictions from unclear direction, these advantages are hard to imagine if one has never seen it happen. And even after a deep UX design project, one cannot see the problems which did not come up because the design preëmpted them!

Creating a clear UXD plan does not just enable many of the strategic & tactical decisions which Highsmith describes software organizations refusing to make, it also requires making those decisions. This can feel awkward to software managers & executives who have learned to thrive in existing environments. Surfacing those decisions makes responsibility for them — and the risk of getting them wrong — a new burden.

Executives who understand Vision as their job can take designers articulating product vision as a threat. That is not a fault from ego; a person with the temperament a good executive needs can have a hard time registering designers’ characteristic disinterest in glory, misreading designers as disrupting the executive’s necessary authority.

Committing to the changes necessary to properly weave deep UXD into an organization’s processes presents a risk that observers will blame any failure for any reason on those changes. As Archibald Putt teaches us, the tech industry forgives or even rewards executive or management failure if one fails for conventional reasons. Why take the career risk of an unconventional failure?

UX designers’ skill or other constituencies’ enthusiasm cannot address these challenges. To leverage design effectively, an organization needs a strong product management practice.

Product management

Product managers shape their product to meet business goals set by executives. To fulfil this responsibility, PMs must own every decision about their product and every decision about the process for making it.

Technical opportunities & constraints identified by engineering, customer drives identified by marketing, user needs identified by designers, and more all inform those decisions. When necessary tensions arise between those constituencies’ concerns, they must turn to the PM to adjudicate them.

This may sound like a PM either having to do everything or having to throw their weight around giving orders. But in practice, good product management is overwhelmingly collaborative, with the PM communicating, translating, and facilitating discussion.

“Hey, Mr. Designer, Marketing says we need an answer for customers who ask for Feature X.”

“Cool, Ms. PM, we should address that with UX Y.”

“Hey, Ms. Programmer, if UX Y proves hard to do, I don’t want you to grind on it. I will put you in a room with Ms. Designer to hash out a solution almost as good which you can deliver more easily.”

This understanding of product management underlines the mistake UXDs make if we claim we should Own The User Experience. It sounds natural, and reflects frustration at the way the industry dismisses our professional expertise, but since the UX is the product in users’ & customers’ eyes, and since concerns about marketing, business goals, and technical development therefore also inform the shape of the user experience, PMs must own it. Designers own a narrower space of design judgment about what serves users best.

This does not mean that PMs author the UX design plan. Designers propose, refine, and communicate the UXD plan because they have the relevant skills; PMs exercise their ownership of the design through editorial control of this work by designers.

This relationship plus PMs mediating the concerns of other constituencies which must inform the design creates a container supporting designers doing our best work. Mediocre designers supported with a strong product management practice will deliver better product UX than great designers subject to weak product management.

This exemplifies how product mangement is management, ideally making decisions and sharing information without making stuff. Wherever one finds PMs doing “real work”, they are filling a gap the organization should patch with whatever resource is missing — usually the attention of an expert in that domain.

Facing upward in the organization, PMs enable executives to focus where they should, on business goals. Executives need not examine the UX design or other elements of the product plan; the PM handles those, in pursuit of the goals the executives set. The PM role compels executives to sharpen goals where they are unclear. “We have talked about growth, and Marketing & UXD have discussed some different approaches. X should get us the most users, Y should get us the most sales revenue, and Z should get us the most profit. Which kind of growth do we want?”

Thus PM + UXD equips executives to make informed decisions which provide the clarity absent from most software development.

To people accustomed to the process chaos Highsmith describes, this can sound like silo’ing. But as with the example of PM mediating between Marketing and Design, good product management and clear role distinctions actually enable vigorous and graceful collaboration between different constituencies, including executives.

---

This post captures and refines a Twitter rant from December 2022; I significantly updated it with a host of edits in April 2024

Design and conceptual integrity

This post captures lively Twitter discussion from January 2022 featuring some of my favorite people from Twitter.

---

John Cutler asks:

UXR [user experience researchers]...

have you ever done skilled, moderated usability testing of a design ... exposed major problems in the design ... had the fixes shot down (maybe someone wanted to be *bold*, or “just ship it”)

...shipped it as is

...and it actually turned out fine?

Andy Budd replies:

I guess it depends what you mean by “fine”.

I’ve definitely seen teams ignore the results of usability tests. The issues they identified still happened. However the bulk of users managed to struggle through. They ended up slightly more annoyed, but task completion remained high.

Tom Kerwin says:

But it’s a fair point: you can almost always find usability issues, and you’re almost always going to have to launch with some, and it’s not always obvious which are truly critical.

On top of that, some issues are very time consuming or complex to fully solve.

Experience helps.

Every discipline has their own lens.

E.g. Folks working in fraud tend to assume every failed conversion was a fraudster who got cold feet.

It’s blind men feeling an elephant.

As Venkatesh Rao put it, all are “right” but one of the blind men is the HiPPO - their truth runs the show.

Budd replied:

True. Also “Shot down” is highly emotive language. An alternate framing is “weighed up the potential problems against the opportunity cost, and decided that even if there are inherent usability issues, it made business sense to launch anyway”

Designers seem to spend an awful lot of time framing business decision in a way that paints them as the victim and everybody else as uncaring idiots.

Kerwin replied:

So true!

It’s classic Fundamental Attribution Error

First: if you saw the facts, you’d agree with me.

Then: oh you see the facts but don’t agree? You must be too stupid to understand

Then: oh you understand fully but don’t agree? You must be evil.

Pure tribal thinking

---

And a lot of design rhetoric goes towards, “how can I persuade others to see it my way?”

Much less goes towards, “hang on, what if it’s me that needs to update my beliefs?”

Ironically, it’s when you come in truly open to you being wrong that you start to be able to influence

Venkatesh Rao replied:

Jiminy Cricket syndrome. I think designers often see themselves as the conscience of a project. Sometimes the rest of us go against what they want simply because nobody likes being constantly sermonized at. Maintain enough profanity in the process to keep designers in check 😆

I responded to Kerwin’s comment:

There are two things entangled here which too many designers have a hard time disentangling:

Is the problem that colleagues fail to prioritize UX issues as highly as we do, or that they refuse to accept our assessment that the issues are there?

When designers gripe that our colleagues refuse to prioritize UX issues as highly as we think they should, we need to update our beliefs.

When they refuse to accept our assessment that the issues exist at all, they are burdening us with persuasion we should not have to do.

Kerwin replied:

This is an interesting one to unpick.

I think it goes beyond designers. All makers, all craftspeople tend to assume that the issues we see are critical, and get frustrated that others don’t seem to care.

With engineers, it’s technical debt, code quality.

Often we forget to step outside our own technical language and explain why it might matter to others — whether that’s coherence, techical debt, infosec. The best in each craft domain tend to be able to frame the issues as business trade-offs : the choice plus its consequences. I’m not sure that’s persuasion we shouldn’t have to do

I’ve seen it worse with engineers than designers, to be frank. Exec: “oh those engineers are always complaining about technical debt. I just nod and then get them to dash off the MVP anyway. It’s been fine so far!”

This issue must be pretty timeless, as it’s baked into old stories: Chicken Licken, The Boy Who Cried Wolf ... and there’s no easy fix. Effectively translating deep, subtle craft concerns into the comparitively crude language of business takes patience, empathy, humility.

It’s always easier to throw up your hands and grumble about “the idiots over there”

I replied —

I think you are missing the distinction I was trying to make.

Yes, people in almost every profession find that the concerns of their domain are not prioritized as they think they should be. And they are often at least half right, as in the example of technical debt, but while engineers may say something like “we should do X server-side; though it will less responsive for users it will be easier to support” and have leadership choose client-side because they do not prioritize future support challenges highly enough they do not face leadership routinely saying, “we will do X client-side because we think engineering are wrong, it will actually be easier to support”, in the way that other constituencies often tell design “no, you are wrong, users will be better served by something else”. So the whole question of “persuasion” is screwy here. I am hesitant to think that designers should be doing persuasion at all internally. On the one hand, as a designer I may have opinions about strategic product/service decisions which prioritize certain UX elements more than Eng or Mktg consider important, but I should not be trying to persuade, I should be giving PM clarity in weighing the decision and on the other hand, when providing that clarity, when I say that A is much better UX than B, and C is just a bit better than D but worth doing if it is easy, I should not have to persuade my colleagues that I am right in that assessment.

Now in practice, designers have propagandize the value of good UX and the dev practices which support it, strategically. But that is different from having to persuade colleagues of our expertise in our own domain in the tactical day-to-day. Solving UXD problems and communicating UXD solutions is hard enough. If UX designers also must persuade colleagues that those solutions are good, it wastes everyone’s time & energy, and feeds our temptation to overstate the importance of specific solutions.

Kerwin replied:

In design and writing, our work is both more visible and more subjective than, say, engineering. Our work is much easier for everyone to have An Opinion about.

I replied:

Exactly! Engineers face their own distinctive challenges in being respected, but the opacity of the material protects them from the routine substitution of others’ judgment in their domain which designers often face.

Kerwin replied:

I find it’s better to put the time and energy into persuading people that most ideas and solutions are totally fungible ... and that requisite variety can be more valuable than consistency. The more you’ve had to fight for something, the harder it is to let it go.

I replied:

Oh yeah, this is a good point about the sunk-cost-ish psychology of sandbagging the importance of a UXD solution (or anything by any constituency) which one had to fight for.

Rao joined in:

Not sure why I’m tagged here but I’ve nearly always been on the opposite side of this issue and in my experience it’s usually fine to ignore designers and ship because there are usually bigger risks/uncertainties baked into the release that overwhelm design considerations.

In my experience designers tend to resist thinking in terms of probabilities and risks if they are sensitive to them at all. Design is a binary to most of you — it either has integrity or is somehow philosophically compromised.

PMs and engineers more naturally think in terms of probability that something will matter and the costs if it does. Designers and infosec people tend to be on the other side. Everything is either perfect or a showstopper.

PMs own risk so typically have their way.

The best designers I’ve met tend to act like lawyers. They lay out risk comps rather than design comps, and understand that they don’t own the risk.

Dorian Taylor chimes in:

infosec people too for that matter

Cutler responds:

IME, everyone -- PMs and eng included -- fail to consider non-linear dynamics, the oddities of time, our propensity to fool ourselves, overestimate their resolve to “fix things later”, and underestimate the oddly exponential value of a job well done

I replied:

Well said.

One thing that drives UXDs bats is that dev orgs tend not to register the importance of design coherence. Often any one of a hundred compromises to the UX is trivial by itself but if you screw up a dozen of them the whole thing falls apart.

Kerwin replied:

So much this. And once you’ve got to incoherence, it’s very hard to “fix” incrementally.

I’ve noticed that a lot of designers smell this kind of problem but reach for consistency - which doesn’t really fix the problem but does create a lot of headaches.

Lots of designers are trapped starting with “ideal” screens and then those get hacked up as scope is cut to meet deadlines. Unclear when coherence is lost.

Better to start with a coherent “skeleton” and then add flesh iteratively.

Taylor replies:

unless you can’t even make it to “coherent skeleton” before that gets hacked up as scope is cut to meet deadlines

Kerwin replies:

LOL – yes, but then it was all doomed anyway.

A coherent skeleton concept model can be a dozen sticky notes and connecting lines.

Taylor replies:

yeah but the work to create a coherent skeleton (brooks called it “conceptual integrity”) looks like “nothing” to onlookers until you have one, so even that is a risky period

I replied:

Yes. And so few people have ever seen it done that when designers talk about doing it, it sounds absurd.

Taylor replied:

the thing that seems to be perennially hard for designers to communicate is what Venkatesh Rao called “philosophical compromise”, and like absolutely yes it is philosophical compromise, with real material consequences.

like it isn’t just some aesthetic preference; it affects outcomes.

I replied:

Exactly. And few people understand how brittle that coherence is: it can absorb a few small compromises, but not many, and one big hit can shatter it.

Taylor replied:

put it like this: say you’re an engineer working on a bridge and the client says take out half the suspension cables — no engineer would put their stamp on that

now what if the client says to the architect: “we’ll build the bridge, but not all the way to the other side”

Kerwin replied:

I was an engineering student once upon a time

We had to build a cantilever

My maths was good

My measuring – not so much

My cantilever buckled under almost no load

I learned quite a lot

Taylor replied:

you would have gone to prison if you were the engineer of record

Kerwin replied:

That was one of the things I learned!

Also that you can go to prison for other people’s mistakes

I replied: two generations from now people will be baffled that software dev was not professionalized like structural engineering.

Taylor replied:

the engineer who rigged the volkswagen dyno hack went to prison but his boss didn’t

also for the record i do not support licensure for designers per se

I replied:

In the long run I would like a guild model of some kind, but hard licensure requirements like with medicine is too much. I’m not sure exactly what that looks like.

Taylor also replied:

the protestations of designers being dismissable as the whinging over the personal aesthetic preferences of an effete class of trust fund children is not helped by the fact that the design field is in fact populated by an effete class of trust fund children

i should clarify: not exclusively populated as such; perhaps not even a majority, but enough to run into them often enough to look like a majority if not a totality

To which I replied: I do notice that designers who are not craftspeople but rather would-be artists have a strong tendency to have more expensive shoes than their pay can account for.

Rao replied:

This is more of a western pattern, especially North American. In my experience, in Europe and Asia, designers seem to be more… normal. In North America, I think “design” probably got tied up in “critical design practice” French theory crap and wrapped up in esoteric political concerns yo some degree.

Taylor replied:

imo d-school (and architecture school) is where the offspring of the professional class go when they’re “creative” and don’t want to go get an mba or become a doctor or lawyer and their parents will shun them if they get a fine arts degree; they come out wearing black turtlenecks

Taylor said:

i remember seeing some article about social networks that a minority can look like a majority if they are in the right places (eg central or spanning) in the network; i probably have it in zotero but don’t feel like scouring for it

Rao replied:

They do tend to dominate social media about design

Taylor replied:

yeah because they’re charismatic and know a lot of obscure names and facts

I replied:

Lots of trust fund folks throughout the startup world, of course, which is under-discussed.

Taylor replied:

i am not a trust fund kid but at 18 i wanted to go to art center in pasadena to learn how to design cars (because i wanted to self-express) and for a brief moment my extended family was willing to pool their resources to send me; that would have been a terrible, terrible waste

i mean if for no other reason than the harsh reality of automotive design is that it is an even more extreme situation than architecture—practically nobody who enters the field ever gets to do anything cool, lol

(that and by 21 i had completely stopped giving a toss about cars)

On Big UX Design Up Front

This post captures and slightly refines a Twitter discussion from October 2021.

---

It is frustrating to be frustrated by a talk composed entirely of ideas which I agree with and think are important. (One need not watch the video to make sense of this post, but it is well worth the time of anyone in “tech” on the merits.)

IxDA Oslo Nº 130 :: Jeff Sussna :: Beyond the Designer as Auteur from IxDA Oslo on Vimeo.

Like Sussna, I do think that a lot of folks in “tech” — designers and otherwise — are dangerously naïve about their ability to address cynefin-complex systems with big design up front. But by my lights, and in the Twitter thread which spawned this commentary, the universe of UXD practice has been pretty sophisticated about that stuff for a long time.

Back in the 20^th century I was telling clients stuff like “you need to instrument this when you build it so you see how it is actually being used — if you see A, it probably means B, but if you see C that could be D or E and you should investigate, and and and ...”. I have long worked to design tools indended to reframe the way actors in a system connect to each other, so that it produces different dynamics in the way they work. We design in a spirit of experiment in which we have predictions about what will happen and we expect surprises. So while designers are prone to hubris about our ability to control what will happen when the systems we design are actually in the world, a lot of us have been wary of that same hubris for a long time.

More fundamentally, Big Design Up Front hubris is the opposite of the problem which I see facing the overwhelming majority of UXDs and the organizations which employ them. Instead what I see is an industry which does not understand the value of UXD coherence and refuses to allow designers to take the time and use the methods which produce it, for a host of reasons with a bunch of bad consequences so no, Big Design Up Front cannot compose a perfect roadmap for a perfect system which needs no refinement after it makes contact with users, but we can deliver a good map of a good system which will do a lot of what want in practice, much more than most in the industry can even conceive.

UXDs cannot do that work in an ivory tower — we need to inform our work by getting out into the world, developing an intimate understanding of our users, engaging in dialogue with stakeholders and people who are deep in the technology. But having done that immersion in the domain, there is a thing which I can only do by taking a couple of months spending most of my day in a room with a whiteboard and my computer and another designer or two working to a coherent solution and then figuring out how to communicate that solution clearly to the various stakeholders, as a plan for what should be built. (And then, having reached that point of clarity and coherence, becoming a servant to the development organization in holding and communicating that vision again and again.)

So much as I admire a lot about the Agile movement Sussna speaks for in that talk, I see it as predicated on UXD being impossible:

• you cannot have clarity of vision
• you cannot get coherence
• “customers” will always change their mind
• you cannot think ahead
• all you can do is tighten the OODA loop

I don’t want to claim that UXDs can make perfect predictions and deliver perfect solutions, but under the right conditions we can make much better predictions and deliver much better solutions than the industry imagines.

Sussna tells the tale as old as time about how a customer asks for Feature X, you give it to them, and then they say, “oh wait, what I really need is Feature Y”. But good UXD can talk to users, reading the request for X as a symptom, and know the real solution is Y … or Z!

Doing UXD well is hard, and a bunch of imperatives which shape the industry militate against it, so there are a lot of people who have good reasons to think that it is impossible. “We tried UXD, and it didn’t work,” as in the classic parable we tried baseball and it didn't work, in which a group makes a number of “improvements” to the game before playing it, and concludes:

The thing that finally condemns the entire “baseball” idea, however is this: even with all these improvements, the game is no fun at all.

Indeed, I think UXD is facing a crisis from that right now: a lot of organizations decided (correctly) that UXD was important, hired UXDs, but didn’t change anything about their development organizations or processes, and so set those folks up for failure.

UXDs are in a desperate fight to have our profession respected — to just be treated professionally, to have the industry understand what we can and cannot do, to give us the conditions in which we can deliver our best work, to structure processes so they can leverage that work. So to have Sussna say so many true, correct, important things — including about UXD! — to come to the punchline Beware Designer Hubris About Big Design Up Front is deeply frustrating. It is the opposite of what I think the industry needs to hear right now.

On the Twitter thread, Sussna commented:

Unfortunately much of what I see (at least from design Twitter) is “you’re all stupid and lack empathy and if you just got out of our way the world would be good and without unintended consequences”.

Yeah, that is real. A lot of designers have a hard time gauging where to stake their claim in the face of their frustration, and tend to overstate the case. But this is because it is bad out there for us. It emerges from relentlessly having our good judgment overruled, to build things that are obviously terrible, on the whims of people stepping into what really is our turf. So we react by saying that we want total control over UX, which is neither good nor what we want.

Sussna added:

Maybe the next challenge for design is to find a path forward that resolves (or at least addresses) the tension between coherence and complexity / uncertainty / agility / blah.

I agree that this is the interesting challenge for the next generation of design and development, where there is a lot that I know I don’t know. But we cannot get there until there is better understanding in the industry of what coherence is, what it does, and how to get it.

Sussna also says:

In this respect you are no different from developers, or product managers, or testers, or system administrators. This is why Agile and DevOps came to be (regardless of whether they’ve succeeded)

I concur that Agile is a response to developers getting jerked around. But I could not disagree more on the comparison to design. (Well, OK, PMs are also rarely permitted to do their job properly, which is why I keep saying that the best thing an org can do for product UX is to empower PMs!) While developers get overruled on technical questions all the time, often with bad results, these are generally wrong decisions for legitimate reasons which respect developers’ profession. An organization may brush aside engineers’ recommendation that, say, X should done client-side because server-side is cheaper, or faster, or compatible with a customer request, but they do not face some marketeer insisting, “no, you’re wrong, server-side will be more stable and performant” and forcing the decision by overruling their engineering judgment.

Jeff Sussna asks the clarifying question:

Does “we need to refactor this code or update this infrastructure architecture” count as engineering judgment?

This exemplifies the important distinction between owning judgment versus owning decisions. The timing of such projects is rightly a PM decision informed by the judgment of multiple stakeholders in multiple domains, just as the UX of the product or service is. But engineering must own judgment of the technical implications of such projects.

Designers have our professional judgment in our domain of expertise dismissed all the time. I remember a meeting with a smart marketing person who said that it was fine that the IA had two different elements which contained completely different things on the same screen with the same name. I said that was inherently confusing. They said that was just my opinion.

So sure, there is a lot of designer arrogance out there. But in my own experience I have made my claims for the benefits of good UX design measured, enthusiastic about what we can achieve but humble about the limits ... and reliably get told that I am hubristically claiming that UXDs have inhumanly perfect judgment.

And again, I understand why. If you have never seen a solid, coherent UXD solution communicated clearly, such a thing is not simply implausible, it is inconceivable. If, like a lot of folks in the industry, one has seen attempts at defining a coherent UXD solution implode, one is deeply skeptical that it is possible to do at all. If, like a lot of people in the industry, you have a lot invested in the presumption that users are capricious — which is threaded through endless myths about products, services, and projects past — then UXDs sound naïve when talking about what we should do.

But we can and should turn to UX design to solve the industry’s pervasive problems in system coherence.

The X in “IxD”

A funny historical footnote about how old I am:

I am probably the first person to abbreviate “interaction design” as “IxD”. But the general usage of the abbreviation does not come from me.

I coined the abbreviation at Alan Cooper’s UX design consulting studio (then “Cooper Interaction Design”) shortly after the second AIGA Advance For Design conference in 1999 which I attended with Cooper and another designer from the studio, Robert Reimann. At that conference I had proposed a mission statement focused on interaction design which did not go over well; the majority of the people at the conference came from classical design backgrounds and favored a more expansive conception of “experience design”. But that proposal of mine got Reimann scratching at a definition of “interaction design” which described our practice. At the whiteboard in those discussions, I started writing “IxD”.

I added the x because we could not use the obvious abbreviation “ID” — that was already in common use for “industrial design”. I was reminded of an old job where we kept very succinct account notes and “transfer” was abbreviated as “txfr”. Plus the letterform of the x implied interaction, just a bit. Plus, of course, the letter x is cool. So I first used the abbreviation in “print” on a post to the Cooper website in September 2004.

Reimann went on to play a significant role in founding the Interaction Design Association in 2005; they used the abbreviation “IxDA” and a definition of “interaction design” which rhymed with the conversations he had led at Cooper. So I long assumed that their usage of “IxD” inherited from ours at Cooper, making my coinage the headwaters of the usage at large.

But Dave Malouf tells the tale of a Yahoo group discussing interaction design in 2003, in which he invented the same abbreviation independently.

Who put the X in IxD?

Well, I did of course. So now about 1/2 of you hate me and the other half have no feelings at all on the topic.

So the year was 2003. A ragtag group of designers were talking about the world of interaction design. About 600 of us were talking on a single yahoo group. There was definitely a lot of navel gazing going on, but it was fun.

At some point the topic of an acronym came up. I don’t know why exactly, but my struggling memory remembers it something like this. Someone called interaction design “ID”, then I stood up and said, what do you mean? Industrial Design, Interior Design, Information Design, and — my favorite — Intelligent Design? I brought up the problem that ID doesn’t mean one thing so we probably should figure out what our clear acronym should be.

As context, some design studios were already dealing with this issue, especially those in Industrial Design. Ideo for example may still call Interaction Design “IAD”, where the A is obviously for “action”. It could have worked, but I always hated the Washington DC airport that uses the same acronym, so I was possibly being selfish and short sighted.

After a bit though I thought about this phrase “interaction by design” and because I grew up in a hardware store and lumber/fencing yard the phasing of “2 by 4” (for international folks a piece of word that is 2 inches wide by 4 inches high) is usually written as 2 x 4. So “x” translates to “by”. And voila you have IxD and the x is lower-case to call out that yes we know it is not part of the abbreviation of either of the two words.

So now IxD is clearly different from ID whether you mean Industrial, Interior, Information, or even Intelligent Design.

---

UPDATE: @miniver (Jonathan Korman) informed me via twitter that independently and unbeknownst to me, he started using the X at Cooper about 3 years before me.

Malouf went on to be among the founders of IxDA along with Reimann, so they — and the world — inherited the abbrevation from him, not me. Parallel evolution!

What about the X in “UX”?

I have seen some discussions in which people who don’t know this story make the reasonable, incorrect guess that “IxD” references “experience” as in “user experience” as in “UX”.

Might it run the other way? Is user experience abbreviated “UX” instead of “UE” in reference to “IxD”?

I cannot find an origin for that abbrevation. Crossover seems plausible; though Don Norman coined the expression “user experience” in 1996, I do not recall seeing the abbreviation until at least a few years after “IxD” caught on.

But I doubt it. There was a culture gap between “interaction designers” and “(user) experience designers” in those days. Whoever coined and spread “UX” may not have even seen the “IxD” abbreviation.

At that time, there were a lot of xes around. Stuff like the X-Games and action movies used the x to reference “extreme”, a buzzword describing a pervasive (vulgar) style of that era. I was not alluding to that with my coinage of “IxD”, but no doubt it gave me a subconscious nudge. Likely the same happened with “UX”. More parallel evolution?

Trans liberation and policy

I have had arguments with opponents of trans liberation countless times, and their policy proposals are always bullshit.

We have to keep trans women out of women’s prisons so imprisoned cis women will be safe from rape and other violence? We have to keep trans women out of women’s bathrooms so those cis women will be safe? Trans women are dangerous to cis women because they are “really” men, so we must enact with trans women … the measures which we now use to “protect” cis women from cis men?

These suggestions are so absurd that it would be laughable were they not so horrifying.

You actually want to protect women from rape and other violence in prison? Address prison conditions, the guards, the pervasive jokes about rape in prison. You actually want to protect women from rape and other violence at large? Deputizing everyone to police who looks masculine or feminine enough to be allowed in a bathroom is not going to help.

I will not claim that TERFs are Not Feminists but I will say that these misdirections are contrary to the most elementary lessons of feminist thought, which registers how the “protections” The Patriarchy offers women against violence from men not only do not work, they enable violence.

Since this blather from opponents of trans liberation about “protecting women” does not respond to real dangers, what is it about? All of it is framed to suggest that the mere presence of trans women is “violence”. For them the existence of trans people is disgusting and a threat. This is simply bigotry. We call it “transphobia” because it is a phobia: a cocktail of dread and disgust.

They will not be satisfied with any of the policies they demand, as they do not advocate those policies on the merits. They propose measures which they hope will sound reasonable to inattentive people, as an instrument to recruit others to the same bigotry which grips them. No practical “safety” measures, no spaces exclusive to cis women, no cruel insults to trans people will suffice for transphobic bigots. Only a world entirely rid of all trans people will do.

One can hear it clearly if one actually listens to what they say. This ultimately genocidal fantasy is what animates the narrow group who are literally trans-exclusive radical feminists, animates the “gender critical feminists” who inherit the arguments of TERFs, and animates their theocrat & reactionary & fascist allies … who want to also eliminate everyone queer and then go on to the countless others who disgust them until there is no one left to help Niemöller when they come for him.

This is why their anecdotes and news stories and statistics and arguments keep turning out to be bad faith misrepresentations, even fabrications. They are not honest, not doing a risk analysis, not presenting the facts which motivate them. Every bit of it is deliberately deceitful intended to recruit others to bigotry.

There is no “reasonable compromise” to be had with opponents of trans liberation.

I grant them nothing.

Annotated Bibliography of Point-by-Point Rebuttals of Anti-Transgender Disinformation

Dharma

Around 1990 I went to a talk by Ram Dass and he retold a story about the nature of dharma. I suspect that I do not have all the facts right, but I know that this story is true. It was told to him by a doctor who worked on smallpox vaccinations for the World Health Organization in the 1970s. (I do not recall him saying so, but I believe it must have been Dr. Larry Brilliant.)

The WHO sought to completely eliminate smallpox from the biosphere. (They eventually succeeded.) This was one of those things where reaching 80% of people was 20% of the work and reaching the remaining 20% of people was 80% of the work. Eventually there were just a few pockets of unvaccinated people whom the WHO had mapped.

One of these was a small, remote village in India where the people refused to accept the vaccinations. The doctors had come to the village and explained about smallpox vaccination and the people were horrified by the prospect: they regarded contracting smallpox as a blessing from the goddess शीतला माता.

Being the kind of people who join a WHO project to vaccinate people around the world against smallpox, the doctors feel deeply torn about what to do. On the one hand, they know all the horrors of history which they would be evoking by violating the deep cultural and religious commitments of an isolated, pre-industrial village “for their own good”. On the other hand, eliminating 99.9999% of smallpox and eliminating 100% of smallpox are categorically different things, and enormous human suffering was at stake.

The WHO team spent a long time trying to find a way to get this community to accept the vaccinations, but nothing worked. They were at a true impasse.

The WHO team eventually landed on the side of The Needs Of The Many and went to the village to vaccinate everyone by force. They brought soldiers with them because the plan was to literally grab people and hold them down. They brought a lot of soldiers because they were determined to do this without anyone getting hurt. The process was every bit as wrenching as one would imagine. There were people running and screaming and thrashing as they were held, desperately trying to avoid the vaccination.

In time the deed was done and everything went quiet. What now? The story goes that there was a long moment in which a village elder whom the doctor had talked with at length looked him in the eye, with an emotion he could not place. Not anger. Not sadness. Something else. The old man retreated to his hut and returned with an edible gourd and a large knife. He used the knife to split the gourd. He offered the bigger half to the doctor, and said:

“It is our dharma to know that smallpox is a blessing to be sought. It is your dharma to know that smallpox is a curse to be prevented. Today all of us lived our dharma well. And there are many more of you than there are of us.

“This is what we all knew must happen.

“So now we celebrate.”

And the village held a feast at which the doctors were honored guests.

I am blessed that it was my dharma to go to the talk where Ram Dass told me that story.

Never feeling hot

This is a re-post of a linkrotted article which I consider important.

It requires a strong caveat. The author, Hugo Schwyzer, was for a time a prolific commentator on the pop feminist internet. I read a fair bit of that body of commentary at the time when it was new. Schwyzer’s contributions struck me as mostly familiar and uninspired; discussing his high profile at the time, a friend suggested that it was largely a matter of the novelty of a fella saying these things at all. And it turned out that he is a thoroughly terrible person. He came close to killing an ex-lover in a drug-soaked murder-suicide attempt, a classic misogynistic abuse pattern. He used his teaching position to sleep with his students. He also used his fame and teaching position as instruments to meet and bed porn performers, which is less morally irresponsible but distinctly tawdry, demonstrating the disingenuousness of the way he used his soapbox. There are numerous credible accounts of his abusive personal behavior in examples large and small. It is unmistakable that he cultivated his position as That Famous Feminist Guy insincerely, to manipulate and exploit people around him.

(I have to also say — though it is not as important as all that — as a fella who endeavors to cultivate a feminist understanding and to live as feminist life as I can, I have a very personal disgust at figures like Schwyzer who sow distrust of men who are sincerely trying to step up.)

And yet. I have a hunger for men doing feminist-informed criticial reflection on the ways that The Thing Feminists Are Talking About When We Say “The Patriarchy” harms men. Out of wariness that this move can be used to dismiss the way the blade of Patriarchy harms women more, we tend to handwave when talking about the edge which does cut men. We need to do better. A feminist aphorism says that in our encounters with sexuality in our culture, we face a profound gulf of incomprehension between women who are drowning in being constantly sexualized versus men walking through an arid desert. Schwyzer has a contribution to that question which I do not entirely agree with, but consider worth one’s time to consider.

Of never feeling hot: the missing narrative of desire in the lives of straight men

I’ve been thinking this week about the experience — or lack thereof — of being the object of other’s desire. Two different posts got the wheels turning: Girls, Both Real and Otherwise by Daisy B., and Figleaf’s Unforseen Consequences of Men Believing Themselves Unseen. Both Daisy and Fig, in different ways, talk about alienation from their own bodies, at least as they appear to others (and, in a sense, to themselves). I recommend both posts.

In feminist circles, it’s common to talk about the tremendous damage that objectification does to women of all ages and adolescent girls in particular. Many young women remember a moment (painful, terrifying, or, perhaps less often, full of wonder) when they realized that they were the object of another’s sexual desire. Even more women have memories of being sent the mixed message of how both to entice desire (lessons on how to apply make-up, how to dress “sexy” taught at a young age) and how to avoid appearing either “slutty” or “ugly.” (the distinction, of course, is a shifting and elusive one.) For better or for worse, most young women grow up with a cultural awareness that their generally speaking, women’s bodies (though perhaps not their own) are intensely desirable to boys and men; strategies for managing that desire are much-discussed facets of women’s magazines, the advertising industry, and conversation.

But we don’t have a culture in which many young men grow up with the experience of being seen and wanted, in which young men grow up with the sense that their bodies are desirable and beautiful as well as functional. Our cultural discourse about young men teaches that managing their own (presumably insatiable) sexual desire is the defining task of their adolescence. A “jock discourse” that encourages young men to “score” with as many women as possible and an “abstinence discourse” which encourages young men to restrain themselves heroically have essentially the same perspective: your job as a man is to channel your libido, either into sexual conquests or radical restriction. Both discourses center male desire, just as most discourses aimed at young women teach teenage girls how to gain, manage, and direct that same titanic force. The missing element, of course, is the idea that female desire can be directed towards men in general, and towards their bodies in particular.

There’s some explicitness below the fold. Use your own judgment about proceeding.

At first glance, it seems that this argument is oversold. In my high school youth groups and gender studies classes, women — when the environment is safe — often admit to “looking.” There are spaces, more and more perhaps, in which women can acknowledge that a visually-stimulated libidinousness is not solely the province of the be-penised. Television shows like “Sex and the City” and “Gray’s Anatomy” make female desire a central feature of the dialogue — though of course, and this is critically important, the men who are obviously longed for are strikingly good-looking in some fairly obvious ways. Most young men grow up with what might be called the “Brad Pitt Discourse”: the idea that a small subset of particularly attractive men are the objects of women’s desire. But despite the abundant evidence that women’s desire is directed towards an extraordinarily diverse set of physical “types”, few men in our culture grow up with the sense that their bodies could be longed for and wanted.

Gay male desire, of course, is desire directed towards other men. Young gay men will, presumably, sense what it is to be wanted in a way that their straight peers will not. Of course, both gay men and women have been taught to be very careful about being obvious about their desire for straight men — the very real threats of homophobic violence and slut-shaming serve as effective controls, controls which (among many other things) rob young straight men of the strangely wonderful, albeit often disconcerting experience of being wanted.

I’ve written before about my sexual past with men. Most of my fleeting adolescent experiences with guys were with men considerably older than myself. And one of the things that drew me to them was, of course, my attraction to their obvious attraction to me. In high school and even in college, I felt clumsy; nerdy; awkward. Even after I had a girlfriend and a budding sexual history with women, I had never seen and felt obvious and intense desire for me from a female partner. I remember that the first time an older man made me — geeky Hugo — feel wanted, even craved, I felt a rush of elation and relief so great it made me cry. The sex I had with him was not based on my desire for him; rather, I wanted to make him feel good out of my own colossal gratitude for how he had made me feel with his words and his gaze. I was a bi-curious straight boy who had never felt someone ache for him — and the first time that happened, I was floored. Afterwards, this man (about the age I am now, a thought that discomfits me a bit) ran his fingers across every inch of my body, murmuring flattery of the kind I had never heard from a woman’s lips.

My early sexual experiences with men and women were deeply affected by these discourses about desire. I knew my first girlfriend and I were “in love” before we ever slept together; our sex, initially fumbling, became both easier and much more fulfilling over time. But when I thought about what made our sex good for her, I assumed that it was a combination of her emotional attachment to me and my own burgeoning proficiency as a lover. In other words, I assumed that my skill and our shared romance worked together to “make her have” an orgasm — because that’s what the discourse taught me. Neither of us had a vocabulary for anything else. She said encouraging things like “You make me feel so good.” When I first was with this older man, he said something that rocked me: “You’re so hot, you make me want to come.”

What a mammoth distinction between those two phrases! The idea that I could be sufficiently attractive to someone that his own desire could overwhelm him was beyond flattering — it was truly revelatory. And when I replayed what had happened between us, all that remained in my memory for years was my recollection of those words and how they made me feel. That distinction between how these two people described what was happening sexually isn’t unique, I think — it captures something real about the ways in which our cultural attitudes shape our vocabulary and experience of desire and being desired.

It took me years to unlearn these discourses, and years before I would experience being desired — in the most obvious visual sense — by someone other than a gay man.

In a men’s group a dozen years ago or more, I first read Delmore Schwartz’s famous The Heavy Bear, a devastating poem about what it is to be embodied. We read it to stimulate a discussion about male self-loathing; every lad in the room identified, at least in part, with what it meant to go through puberty feeling “in love with candy, anger, and sleep”, feeling the grossness and imperiousness of the body, a body which distorts the real self, making it into a “stupid clown of the spirit’s motive.” We teach our sons that it’s okay for boys to be dirty, to be heavy, lumbering, hungry bears. Feminists often frame that, rightly, as male privilege — it’s easier to live as a slave to impulse than to deny it altogether, as girls (who must be “everything nice”) are forced to. At the same time, many young men grow up with a keen sense of their own awkwardness, their own clumsiness, their own sense that their bodies are repulsive. The idea that someone could long for all of that shaking, raging, farting, sweating bundle of energy seems impossible; who could possibly want to touch this? Who could possibly be turned on by something so evidently unappealing?

So many straight men have no experience of being wanted. So many straight men have no experience of sensing a gaze of outright longing. Even many men who are wise in the world and in relationships, who know that their wives or girlfriends love them, do not know what it is to be admired and longed for for their bodies and their looks. They may know what it is to be relied upon, they may know what it is to bring another to ecstasy with their tongue or their touch, but they don’t know what it is to be found not only aesthetically pleasing to the eye but worthy of longing. As Fig points out:

Since (the) Rules of Desire are problematic, and since they conspire to make us (men) feel undesirable for any reason but the worthiness of our accomplishments or status (largely, I believe, as a byproduct of accommodating other of men’s preferences), it’s just one more barrier that needs to fall before gender equality is really gonna work. And not because men should be objectified equally to women (wrong direction) but because not understanding that we can appear as physically attractive leads us to go a little overboard on the worthiness front. From which much hilarity does not ensue.

Indeed. The very real hurt, the very real rage, that men often feel as a result of having no sense of their own attractiveness has very real and very destructive consequences. It’s not women’s problem to solve; it’s not as if it’s women’s job to start stroking yet another aspect of the male ego. The answer lies in creating a new vocabulary for desire, in empowering women as well as men to gaze, and in expanding our own sense of what is good and beautiful, aesthetically and erotically pleasing. That’s hard stuff, but it’s worth the effort. I know what it is to believe myself repulsive, and what it was to hear that not only was I wanted, but that I was desirable for how I appeared as well as how I acted. That was precious indeed, and far too few men have known it.

Goodbye, Farewell, and Amen

I once had a dream in which someone explained a secret theme in the final episode of M*A*S*H, “Goodbye, Farewell, and Amen”, and when I woke it was still a good observation.

(Mild spoilers for the episode, and for M*A*S*H in general.)

I grew up watching M*A*S*H, and stumbling across it again in recent years I find that it holds up better than a lot of old TV. The laugh track now seems awkward, and the sexual harassment of the nurses is gross, but the stories and jokes still mostly work if you can get into its groove.

I accidentally stumbled into seeing the final episode again a while back, for the first time since it was originally broadcast in my early teens. It dazzled me when it was new, but I expected to be disappointed.

I was not. It is amazing, one of the the very best things I have ever seen done for broadcast television.

M*A*S*H was always transparently a drama about the Vietnam War disguised as a sitcom set in the Korean War. (They eventually made that actual show.) In the final episode M*A*S*H magically, seamlessly lifts one of those veils and turns from a half-hour sitcom into a feature-length drama. That this works at all is some of the craftiest TV ever done, and it works well.

M*A*S*H was made in the era of rigorously episodic television: at the end of the episode its story is over, but the core characters and their situation remain suspended in stasis, never changing. “Goodbye, Farewell, and Amen” recruits the entire series to treats it as just Act I, following through to closure for each of the principal characters. The cleverest of these is the story it gives to Klinger, a one-gag character in most episodes, who gets a beautiful, surprising final act.

What I only realized years after seeing “Goodbye, Farewell, and Amen” was the meaning of Hawkeye’s story. We start with him in a mental hospital. (I remember my mother half-joking that it was small wonder, since he had gone through eleven years of war.) He has had some kind of breakdown, and beloved occasional recurring character Sidney The Shrink is there trying to sort him out.

Sidney employs a style of talk therapy which only exists in plays, TV shows, and movies. He has Hawkeye talk through the Key Incident That Broke His Mind again and again, seeking an elusive hidden truth which once revealed will enable therapy to restore his santiy. Each time Hawkeye tells the story, it plays out a little differently, getting him closer to him facing the truth of what happened. In the first telling, Hawkeye is on a bus with a bunch of people passing around a bottle of whiskey, everyone having a high old time. Sidney The Shrink calls bullshit. Wait, that was not a bottle of whiskey; that was a bottle of plasma for a wounded soldier. Then again. They were not happy, they were terrified.

I won’t spoil the final truth that Hawkeye eventually remembers. It is brutal, one of the gutsiest things ever put on broadcast television.

Here's the thing I realized, decades later: Hawkeye's realization that he wasn't on the party bus, he was on the horror bus? That is M*A*S*H. War is not a sitcom. War is horror. Before bringing down the curtain, the show admitted that it had been lying all along, giving us what we could handle.

Right there in plain sight.