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.