Effectiveness, Not Authority

What lives in the wake of "product development as we knew it"

I’d been considering writing an “advice” post for a little while —my interest tempered mainly by the fact that I’ve always been the worst designer on any team I’ve worked on; know little of use to real practitioners; and have no business telling anyone anything— when I saw an absolutely excellent writeup by Julie Zhuo, co-founder at Sundial and former VP of Product Design at Facebook (when I was there, thanks solely to her!), from conversations she’s had with my old buddy and former colleague Henry Modisett, who runs design at Perplexity. Both Julie and Henry changed my life and career, and what they share about designing in the era of LLMs seems highly useful to me and is worth reading in full for anyone in our field:

The Death of Product Development as We Know it

As it happens, it also reminded me of a lot of what I’ve thought about working with Nick @ Substack, Kellyn Loehr, and Vivian Zhang on Substack over the past half-decade. As has been true in several domains, it feels to me that LLMs have only accelerated or clarified trends or conditions already present. In particular, and perhaps due to personal defects, I’ve always perceived the bureaucratization of design as questionable. If it wasn’t a mistake, then it was at least a development with serious trade-offs designers were often unwilling to admit. And I felt that long before LLMs arrived on-scene, this development was being reassessed, especially in smaller startups. I know that at Substack, resisting “classic design process” has been enormously helpful as we’ve grown the company and sent millions and millions of dollars into the pockets of independent creatives (even as it’s had copious costs of its own!).

That LLMs may be the final blow to this bureaucratization is, for me, a real relief, painful as some of the transitional experiences have been for me and my team. But really: in the past decades, I think the field puffed itself up to its own detriment, and particularly to the detriment of ICs.¹

Civilizing the barbarians of web design

When I first started “designing” web pages professionally, I was most commonly referred to as a “webmaster.” In the 1990s, the limitations of the medium meant that much of what I did was translate the advanced ideas of the print design universe into what was possible with primitive HTML, low-bandwidth modems, small-resolution monitors, etc. As the web matured and mobile platforms arrived, it became more sensible to talk about design in a broad sense, which was reflected in the evolving language used to describe people like me: “visual designer,” “UX designer,” “UX / UI designer,” and finally “product designer.” Much of this was rational enough, if often faddish.

Less rational to me was the attendant ballooning of “design process.” Firms and teams seemed to pride themselves on their ability to dictate to clients or colleagues increasingly demanding methodological requirements. A “design-led” company meant a company whose designers could insist on things like

1. “owning” a layer of the software or hardware product, in the sense of always having final say over what shipped, as though their training meant that no one else’s opinions could possibly matter; this was effectively a structural “appeal to authority,” which is bullshit;

2. always “running” a process that often took weeks; for many years, designers would even append to their job applications descriptions of their process, with variations on “gather inputs” (data, research, comp. analysis), “ideate,” “iterate,” etc. Incredibly, “stickies” were considered a vital part of this!

3. a sort of “tortured separatist” vibe, if not an out-and-out superiority culture, in which it was understood that designers had the virtues of imagination and care, and had to fight against other functions hell-bent on shipping trash and ruining the world.

But by 2013 or so, I was surprised at how sprawling the design scene had become. I know it’s rude to say this, but I was particularly struck by the existence of an entire function whose role was to “design” the language used in user interfaces and product conventions: that is, to devise names, strings, headers, captions, explanatory text, and so on. The people who worked on this —sometimes called Content Strategists— were often very bright and had done what they could to research the questions involved in this work, but it was inevitable that separating the user interface from the language it featured or reflected would create immense border-disputes, and it did. I recall many instances in various companies of these folks telling me: “The designer’s ideas aren’t good enough, because they need to start with the language, the story, and anyway the button should obviously be on the left side,” while the designer would lament “I can’t get them to give me the text strings I need because they think the direction is wrong.” This sort of interplay, multiplied across a large organization, was breathtakingly costly: everything took many times longer than it should have, and any gains to be had seemed dubious in light of that, especially since executives —who had every reason to think they should be allowed to opine about such basic human phenomena as visual order, color, and language, as did everyone!²— would often set aside a team’s recommendations anyway. The wounded feelings that resulted were the stuff of managerial nightmares, but the plain fact was that none of this mattered in the least. I cannot think of something important gained from it, and all of these people probably should’ve just been designers. (Their thinking was often very strong).

This function was far from alone, though. The specialization sought by the design field included parsing out everything once assumed to be a designer’s job: visuals, illustrations, copy, research, implementation, and so on into entirely different roles. Some of this regularly makes sense and some of it certainly doesn’t, but overall I never found the overall theory of it very persuasive. The joins were all contested, to say nothing of whether e.g. “engineers are allowed to say anything about interfaces” or “whether PMs can ideate”. In darker moods, I wondered if much of this specialization came from two sources in particular:

• many designers didn’t actually like software, technology, or the Internet; they really wanted to be making art, or posters for bands, or shoes, and processed their high-minded guilt at selling out for (immense) salaries by mythologizing their own role in making e.g. feeds and profiles. Thus they wanted to invent ways of “being a designer for a tech company” that gave them immense authority, alienated them from their colleagues, and cut off any aspects of the job they didn’t enjoy.

• ZIRP meant that companies swelled in size, and there simply wasn’t that much for designers to do other than invent massive methodologies that justified their pay, time-on-task, and (tenuous) sense of importance; it also helped with the perennial requirement of management to build fiefdoms. “We’re actually going to need 8 FTEs on this project to cover brand, content strategy, user research, UI design, prototyping, documentation, etc. Which means… I should probably be a Senior Director!”

I never really felt like product output benefitted from the rituals or the specialization, and I also felt that by 2015, major computing platforms had matured enough that little “holistic invention” was left for most of the field. The occasional OS or new paradigm or breakthrough app notwithstanding, most software designers didn’t need to gather, ideate, iterate, etc. They didn’t need weeks to figure out a UI pattern. They didn’t need a month in a cave to intuit “the future of” whatever. They needed to help falsify ideas quickly among users. That is: they needed to ship, which meant working more effectively individually and with others.³

Being effective instead of authoritative

When I joined Quora, I learned from David a lot about a wholly different way of thinking about design: not as a rarefied methodology-oriented and precious field but as something at which one wanted to be effective, whatever it took. Quora’s failures are many and well-known, but their causes were upstream of this approach, which itself emphasized speed to a large degree. And indeed, since I worked there, I’ve often told designers that I think the most important things they can work on are, in order:

1. Speed.

2. Interpersonal communication / psychological self-management.

3. Understanding technology.

4. Understanding business (and specifically strategy).

“Craft” or “taste” may be in the top ten —maybe— but they don’t crack these top four to me. I may in the future return to the second, third, and fourth themes, but for now and in keeping with Julie’s post, I want to mention why speed is number one.

Everyone knows that speed is important for the enterprise a designer works for: it lets them find out “what will work” and move on from what will not, and nothing beats the laboratory of the real for that. But as important, in my opinion, is that speed is vital for a designer’s personal sanity. Much of our work entails doing what others propose; we can have meltdowns about the injustice of a world that doesn’t turn solely to us for “ideas” —one of the most dubiously meaningful types of creative output— or we can get so fast at producing mocks and prototypes that making them is a trivial exercise for us. If it costs us little to “whip something up” at the request of others, we can spend less time in pitched emotional battles about “who rules product development.”

To Julie’s point: in the era of LLMs, no one rules product development, except those with actual organizational power (or capital power, as the case may be). It was absurd to pretend otherwise even back in the day, but now it’s an actual impossibility: you will not stop engineers, PMs, executives, or literally anyone else from exploring ideas, generating concepts, floating theories, etc. And you shouldn’t want to! Really: we should never have wanted to; it was precious beyond belief of us. It may be true that your work will be better, but if it is, you should be eager for it to be recognized as such by all incentivized as you are for the good of the enterprise, or by reality itself. Sometimes that takes a while; to speak positively of our function for a moment, I do in fact think that designers are often early, regularly understanding important product questions long before others do. But this is more of a curse than an advantage, except insofar as one can use this foresight to inform one’s own choices in the zones given over to one’s control. In the meantime, speed helps designers remain useful: they can be the most effective at wisely making real the often-inchoate hunches of everyone in a company. But for this to be feasible, the actual work cannot be painful or taxing, cannot involve a ten-step process, cannot exact a high emotional toll.

Of course, being fast and flexible is not only a happier path for the IC, likelier to result in continued employment, but, to return to the initial point, improves rates of learning for all. It’s true that this requires being in an organization where real learning occurs, and that’s not at all a given; many designers will work in environments where leaders have no particular interest in it, favoring control over falsification or hypothesis improvement. While this is obviously suboptimal, even there, reducing the individual practitioner’s stress, the cost of executing even the worst ideas, and the psychological pain of labor (which is non-trivial over a career, however idyllic) is worth it. In sum: improving knowledge-generation through speed is the primary goal, but reducing the time and effort required to produce is a perfectly good fallback if you’re not in an environment that’s especially rigorous.

LLMs as a final nail

Julie and Henry are obviously correct that LLMs make all this clearer than ever, and fortunately aid the quest for speed —especially in prototyping, but also by e.g. making it possible to create “satisficing” assets and logos and icons, or to explore ranges of simple options quickly, etc.—, and any designer who really wants to work on software should be exploring how to make use of them to accelerate and reduce the costs of their work.

I think designers should also feel relieved, however, at this return to the industry’s earlier structure: the “prototype and prune path,” as they describe it, is lighter and more fun than the lumbering, self-serious processes of the past, and will generate less internal anxiety about “one’s value.” That designers have been frequently defensive and insecure is no surprise given what they’ve been told to represent about themselves! If I’d ever believed that “only I can determine what should be built,” I’d have been very anxious, too. Our value has never been our authority: it is only our effectiveness at collaborating with others to create the best possible output within constraints that keeps us vital to companies. And vital we remain, I believe, because while LLMs continue to improve, I think there are strong reasons to doubt their capacities for the kinds of particularities and differentiations people turn to us for. These generalization and inference machines are outstanding at such a wide variety of purposes that it’s easy to lose sight of what they are not good at: the local, the unusual, the specific, the exceptional, the variant, the unique, the new. Ironically, this returns the designer to the area we ostensibly all wanted to protect with our “artists’ studio” bureaucracies: that of the creative whose invention from particular knowledge is illegible to systems but resonant with humans.

It may be “the death of product development as we know it,” in Julie’s framing, but it is a new life for anyone who likes to make shit and can bring themselves to let go of the accoutrements of designer status, which, in my opinion, were net more harmful than helpful, for designers and companies alike.⁴

Seed stage design team offsite circa 2016. (Johann Joseph Zoffany, Academicians of the Royal Academy, 1771-1772).

1. I am surely overstating this, and under-weighing the real reasons for specialization and growth. I don’t mean to suggest I would’ve done anything differently had I structured things at the time; this is all Monday-morning-quarterbacking.

2. It’s true that non-designers often ignore important facets of design, but the “unknowns” that this affects have been declining since the commodification of UI practices on mobile devices; while an engineer in 2008 might have proposed unusable interfaces, today they’re likely to propose merely less-attractive interfaces, or interfaces that create later complexities or problems a designer might avoid, etc. Designers should adjust our attitudes accordingly!

3. An excellent demonstration of this reality was that at Facebook, there were constant efforts to create small teams insulated from all this; four or five people would develop in short order something that would’ve been literally impossible for the organization as a whole. Once it had legs, of course, the rest of the company would begin to populate the project, grinding it to a halt and diluting its vision and momentum. This seemed to recur over and over.

4. I suppose it’s not fully “needless to say” that I lament any loss of employment or income for anyone. Many empowering tools involve this, of course; all of us work in roles that depend in ways on efficiencies gained elsewhere, and often at someone’s expense.