Neoliberalism (n.)

I finally got around to indexing a bunch of commentaries on this useful and necessary term of art.

I consider economist Brad DeLong’s Principles Of Neoliberalism an ideal introduction to the subject. It provides a sympathetic, lucid description of what neoliberalism is and why its supporters support it. (Yes, that’s me DeLong credits for cleaning up the formatting of his old archive; you can find that effort in an earlier post.) It starts with a tidy summary:

Neoliberalism is many things. It is:

• a counsel of despair with respect to the possibility of social democracy today (outside of the global economy’s industrial core).
• a counsel of hope with respect to the prospects for rapid market-generated economic development outside the global economy’s industrial core — if governments adopt market-conforming policies.
• a bet that improvements in transportation and communication — the shrinking world — “globalization” — gives us today an extraordinary opportunity to rapidly reduce global inequality by incorporating more and more people and more and more more regions into the global economy.
• the only live utopian program in the world today.

That said, I am a lefty who bitterly opposes neoliberalism. My comrades on the left are often vague in naming what we mean when we talk about it, so the point of this post is to index some good critiques, especially rescuing some of them from the potential implosion of Twitter.

A few key articles:

Neoliberalism – the ideology at the root of all our problems

Imagine if the people of the Soviet Union had never heard of communism. The ideology that dominates our lives has, for most of us, no name. Mention it in conversation and you’ll be rewarded with a shrug. Even if your listeners have heard the term before, they will struggle to define it. Neoliberalism: do you know what it is?

Its anonymity is both a symptom and cause of its power.

Neoliberalism: the idea that swallowed the world

The word has become a rhetorical weapon, but it properly names the reigning ideology of our era – one that venerates the logic of the market and strips away the things that make us human

“Neoliberalism” isn’t an empty epithet. It’s a real, powerful set of ideas.

In economic circles, however, “neoliberalism” is most identified with an elite response to the economic crises of the 1970s: stagflation, the energy crisis, the near bankruptcy of New York. The response to these crises was conservative in nature, pushing back against the economic management of the midcentury period. It is sometimes known as the “Washington Consensus,” a set of 10 policies that became the new economic common sense.

The Collapse of Neoliberalism

Although neoliberalism had little to offer, in the absence of a new ideological framework, it hung over the Obama presidency—but now in a new form. Many on the center-left adopted what we might call the “technocratic ideology,” a rebranded version of the policy minimalism of the 1990s that replaced minimalism’s tactical and pragmatic foundations with scientific ones. The term itself is somewhat oxymoronic, as technocrats seem like the opposite of ideologues. But an ideology is simply a system of ideas and beliefs, like liberalism, neoliberalism, or socialism, that shapes how people view their role in the world, society, and politics. As an ideology, technocracy holds that the problems in the world are technical problems that require technical solutions. It is worth pointing out what this implies: First, it means that the structure of the current system isn’t broken or flawed; it thus follows that most problems are relatively minor and can be fixed by making small tweaks in the system. Second, the problems are not a function of deep moral conflicts that require persuading people on a religious, emotional, or moral level. Instead, they are problems of science and fact, in which we can know “right” answers and figure out what works because there is consensus about what the end goals are. Together, the result is that the technocratic ideology largely accepts the status quo as acceptable.

When Neoliberalism Was Young: A Lookback on Clintonism before Clinton

Now, neoliberalism, of course, can mean a great many things, many of them associated with the right. But one of its meanings—arguably, in the United States, the most historically accurate—is the name that a small group of journalists, intellectuals, and politicians on the left gave to themselves in the late 1970s in order to register their distance from the traditional liberalism of the New Deal and the Great Society. The original neoliberals included, among others, Michael Kinsley, Charles Peters, James Fallows, Nicholas Lemann, Bill Bradley, Bruce Babbitt, Gary Hart, and Paul Tsongas. Sometimes called “Atari Democrats,” these were the men—and they were almost all men—who helped to remake American liberalism into neoliberalism, culminating in the election of Bill Clinton in 1992.

A Quick Follow-up on the previous article

It’s important to distinguish neoliberalism in this sense—that is, neoliberalism as a political program—from neoliberalism as a system of political economy. Scholars and activists on the left disagree, fundamentally, about the latter, with some claiming that what we call neoliberalism as a form of political economy is merely capitalism. I’m deliberately side-stepping that debate in order to focus on neoliberalism as a political and ideological program.

The Market Can't Solve a Massacre

Neoliberalism is at once a subspecies of capitalism and a model of governance, a vision of what politics can and should be. It sees political and social life almost exclusively through the lens of the free market, and asks us to consider ourselves and our fellow citizens primarily in terms of our economic activities: as consumers, as workers, as competitors, as human resources. Under neoliberalism, in other words, the individual is less a human subject with rights that entail obligations from the government, but rather a variable in a broader calculus of efficiency, a site for maximizing revenue and minimizing expenditure. Simply put, neoliberalism is about the withdrawal of government responsibility for political problems in favor of market-based “solutions” and individual “choices.”

Wendy Brown’s In the Ruins of Neoliberalism (a review)

In Brown’s account, the novel attack on democracy that we see today is largely the unanticipated consequence of neoliberal economic theory, which she primarily interprets through analysis of the writings of the Austrian economist Friedrich Hayek. Neoliberalism refers to a nebulous branch of social and economic thought associated with economists such as Hayek and Milton Friedman, and exemplified in the political arena by the anti-regulatory regimes of Ronald Reagan and Margaret Thatcher. The movement is also associated with reduced government and laissez-faire economic policies, and, to a slightly lesser degree, with globalist policies intended to reduce international barriers to trade.

[⋯]

Neoliberalism, then, is not economically liberal, in the sense of advocating for state regulation of markets, it is politically liberal in the sense of aggressively seeking to curtail the reach of the state to intervene in individual choice.

I have several resources from explicitly leftist sources, and I fundamentally concur with their critiques as right on its consequences, but first I must note two key quibbles I have:

• Leftists are right to see a devil’s alliance between fascists and capitalists who foolishly dread socialism more than fascism, but are wrong when they suggest that fascism is fundamentally an instrument of capitalism. Fascism emerges from its own driving impulses. Since fascism is an ideology about culture and governance, radically disinterested in policy questions, it is a different kind of thing from neoliberalism which is an ideology of economic policy.
• Leftists often equate the policy ideology of neoliberalism with the governance ideology of liberalism-as-in-liberal-democracy. I have some hard questions for leftists who reject liberal democracy as an ideology defined by capitalism.

Ben King <@grimeandreason> offers a cornucopia of useful commentaries:

• Neoliberalism as neocolonialism: A collection of multi-disciplinary and multi-sector resources from around the world
• Neoliberalism, climate change, and ecocide: a resource collection
• Geography of neoliberal beliefs and pathologies
• Impacts of neoliberal hegemony over time

Ellie Baker <@Lashesxx> offers an outline of the drivers and history:

The neoliberal movement is probably the least understood and the most important-to-understand movement in the last century precisely because people believe so much of its BS without even knowing what it is and was - and how they came to believe this bullshit in the first place.

Neoliberalism can be traced to the 1920s.

During WW1,cooperation between government and industry conferred a new legitimacy on state regulation, supervision and planning. Neoliberalism arose not to rehabilitate free markets but to “inoculate capitalism against the threat of democracy”.

In the view of neoliberals

• The state must enforce property and contract law and accommodate a bare minimum of working-class demands while expediting the movement of capital and commodities.
• The state must not only refrain from regulating business; it must desist from providing social welfare, since the workers of the world must be united in submission to the fluctuations of the world economy.

Though ostensibly democratic, the neoliberal state must not be an instrument of popular will; it is more like a police station charged with managing and if need be, repressing any uppity rabble: unions, especially, but any form of popular mobilisation to tame/eradicate capitalism.

In the 1940s, a rising bloc of business leaders, intellectuals, and politicians began an eventually successful crusade to re-impose unfettered accumulation. For three decades the relative prosperity and tranquility of “the golden age of capitalism” stymied their efforts.

The global economic crisis of the early 1970’s created the perfect conditions for an assault on New Deal liberals and western European social democracy. The state’s main focus had been on maintaining a high level of demand, capital now began to insist on more attention to supply. The “supply-side” entailed a dramatic lowering of personal and corporate taxes, draconian cuts in social spending, deregulation of business activity, and the weakening if not crushing of unions.

Thatcher and Reagan centre stage: their argument was that the enterprise and innovation unleashed by these policies would increase aggregate wealth that would “trickle down” from capital to increasingly unorganised workers.

The Reality:

• stagnation of real wages for four decades
• increased worker productivity
• Himalayan levels of personal debt to make up for wage stagnation
• a shift in the trajectory of capital away from production to finance
• a massive upward redistribution of wealth
• lower growth rates

The 40 year assault on unions and the welfare state issued in a resounding victory for corporate business, brought to a head in the late 1990’s with Clinton and Blair. The parties traditionally considered the vehicles of working-class interests rapidly recast themselves. “New Labour,” as Blair anointed it, redefining their objectives, not as regulating or abolishing capitalism, but as making the transition to a fully marketise world less painful and disruptive than it might be.

Thus, when Thatcher was asked what her greatest achievement had been, she said without skipping a beat, “New Labour.” Neoliberalism has been “a political project to re-establish the conditions for capital accumulation and to restore the power of economic elites.” In 1994, David Rockafeller wrote:

The world is ready for a world government. The supranational sovereignty of an intellectual elite and world bankers is certainly preferrable to the national self-determination practiced in past centuries.
[⋯]
We are on the verge of a global transformation. All we need is the “right” global crisis and the nations will accept the New World Order.

Noam Chomsky says:

One of the most interesting reactions to come out of 1968 was in the first publication of the Trilateral Commission, which believed there was a “crisis of democracy” from too much participation of the masses.

Quoting Tiberius <@foo>:

There is no neoliberal left. Neoliberalism is a right-wing ideology.

The right: fascism, conservatism, liberalism (hierarchy-based)

The left: socialism, communism, anarchism (equality-based)

“Socially left, fiscally right” is oxymoronic drivel to make liberals feel good.

Case in point: liberals vocally support race/sexuality/gender/sex equality under law, but won’t challenge the fundamental economic systems that prevent true equality due to the White heteronormative patriarchy holding all the wealth/power.

Some key articles:

Why Neoliberalism Needs Neofascists

The neofascist assault on democracy is a last-ditch effort on the part of neoliberal capitalism to rescue itself from crisis. The only solution is a decisive retreat from globalized finance.

The Death Of The British Imperial State

The answer is that neo-liberalism has succeeded in destroying societal values, to the extent that anti-social and even sociopathic behaviour no longer appears peculiar.

Finance Capitalism’s Self-Destructive Nature

So basically, finance capitalism is a predatory international economic policy aimed at draining the rest of the world all to pay the leading one percent of wealth holders in the U.S. and their satellite oligarchy in England and a few European countries

Undo is the king of interface idioms

Undo is is the king of interface idioms.

Undo is so important that they built a hard button for it into the Apple Newton. It enables strong actions with a single gesture throughout the interface. It makes users more willing to explore and experiment. It enables users to get into flow because they can act with confidence. Jonathan Baker-Bates wisely reminds us:

Remember that the worst problem that can ever affect somebody using a computer is lost work. No other usability issue comes close. Design to prevent or at least minimise that, or face the rage that will ensue when it happens.

Simon Pitt has a beautiful ode to the magic of Undo.

In many ways, I regard the undo button as the computer’s most creative feature. It is a digital do-over, an ever-present safety blanket, reducing the cost of failure. We are free to experiment and play, knowing that a single keypress can restore the current state. Our fear of losing our precious work is lessened, if not appeased entirely. There is no need to freeze or choke at a pivotal moment. Our hand doesn’t need to shake or sweat as we make a key mark. Less hampered by the luck of individual actions, we can try each step over and over until we get it right. I sometimes wonder at the years of healthy life undo may have saved by lessening our collective stress.

It is not a v2.0 feature, or even a v1.1 feature. Build it in from the beginning.

John Gruber of Daring Fireball calls Undo support the key sniff test for whether an application is good.

There’s nothing cosmetic about Undo support. It’s a red flag. You open a container of food and it smells foul, you throw it out. You try a new app and it doesn’t support Undo, you throw it out. And you empty the trash immediately in both cases. Get it out of the house.

Fake Undo is the queen of interface idioms. Too many defenses of counterproductive confirmation dialogs come down to an inability to see that even Fake Undo is worth building. If you cannot “really” undo a delete, you can cache the entity and re-create it, which achieves what your user wants ...

But you should build strong real Undo.The event model that supports Undo is going to have so many useful applications. Retrofitting it later will be brutal or impossible. Build it from Day One.

Dorian Taylor reflects on ideal version control and imagines a glorious re-framing of all software architecture and user experience lurking in the promise of Undo.

What would a future look like, in which everything had an undo button that went back arbitrarily far? In which the act of creating new digital content did not mean destroying what was there before? Something like Google Docs offers us a glimpse. Changes are transmitted over HTTP requests, as messages that only express the content of each individual change itself. On the server side, what would otherwise be encapsulated as a file — in Rich Hickey parlance, a mutable and therefore volatile place for data — could instead be represented non-destructively, as a time-stamped log of accumulating changes, which could be projected into a snapshot at any stage along the way.

To bring about that future, we would likely have to move away from files — at least as anything other than bulk payloads of instantaneous freeze-frames of the state of a system. It would, ironically, mean going back to a client-server model. But who controls the servers? Well, you could, I mean, it’s not that outlandish a proposition.

---

Capturing a Twitter thread I started in 2015

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

This captures and refines 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

Dorian Taylor’s Agile As Trauma says a lot of things about Agile which I had tried to say, only much better than I could say it, 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.

Miriam Posner’s Agile and the Long Crisis of Software is extremely insightful.

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.

I concur with Steve Denning’s Why Agile Needs To Take Over Management Itself that orgs have resisted any of the deep cultural, role, 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.

Alan Holub offers a short Twitter thread which reflects the best of Agile’s spirit, which I genuinely admire … and shows how it reflects an adaptation to management’s fundamental distrust of developers and disrespect for what they do and how they do it.

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.

I am delighted to be in the heavy company of designers and other mentioned in Agile vs Waterfall And Other Obfuscations, which argues that agility is of course good ... while Agile-in-practice tends to eschew the well-considered-plans-held-lightly which enable agility.

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).

My page Executive Responsibility, UX Design, and Product Management 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.

The History Of Agile And Its Manifesto is an index of resources which I found by way of Christina Wodke, who observes that the folks indexed there are all men.

#AgileKillsKittens (or Agile In Their Own Words: The Problem With Agile & Scrum) compiles numerous critiques of Agile.

An Agilist provocation

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”:

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 might be 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:

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.

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!