The pragmatic design manifesto

Two years ago I wrote, “Five Rants from a Cranky Designer,” expressing my frustration with recent trends in design: the overemphasis on pixels, the obsession with design systems, the misapplication of user research, the isolationism, the diva attitude.

I expected some controversy, but did not expect what I got instead: gratitude from other like-minded designers. Some felt alone and frustrated, working in environments that didn’t value them. Others had been living with a nagging sense that there was a better way to do it. I’d hit a nerve.

As I’ve ruminated on that, I’ve found myself returning, time and again, to the notion of pragmatism: the concept of design as a discipline rooted in practicality and trade-off. It underlies what distinguishes my perspective from others in the industry.

I’m a pragmatic designer, and perhaps you are, too.

So here it is: the Pragmatic Design Manifesto. I’ve modeled it loosely on the Agile Manifesto — in each case, providing both the desired trait and its opposite, and trying to stay concise and positive. Unlike the Agile Manifesto, I did this in isolation, so consider it a work in progress — I’d love your feedback!

The Principles of Pragmatic Design:

Communication over creation.

A design isn’t the product or website itself — it’s a way to communicate a user experience to those who will build it. And not just the experience: the rationale behind it, so the builder becomes part of the design process and can make informed decisions in the course of building. That communication requires a lot of creation, but creation work is wasted when it doesn’t aid in building the product.

This isn’t an excuse for sloppiness or incomplete work. It just focuses the notion of completeness on the end product rather than intermediate artifacts. If a wireframe will get your plan across without mockups, don’t do mockups. If a sketch will suffice, don’t bother with the wireframe. Sometimes all you need is a few bullet points in an email.

At Heap, our main design reviews happen early in the process, when the design is little more than bullet points and a sketch or two. Plenty of design work lies ahead — not to mention as-yet-unknown twists and turns. But doing it this way requires engineers, product managers, and designers to come together, agree on a path forward, and subject that path and its trade-offs to scrutiny, without the aid or distraction of pixels. It then allows engineers to start thinking about implementation even as designers are doing “real” design — and it lets designers be judicious about how much of that subsequent design is even necessary.

Realism over idealism.

Design is an endless series of trade-offs. Some are pure design trade-offs, but many trade design against other factors: engineering complexity, business goals, budgets, and so on. Those trade-offs are going to happen, and our impact as designers — our coveted “seat at the table” — depends on being participants in them rather than purely advocates for “our side.” The best products cannot simply serve user needs in a vacuum: they have to balance those with business goals and practical considerations. And, there’s more than one way to make those compromises. By participating rather than just fighting them, we can shape how they’re made.

This isn’t something designers can accomplish on our own. Great design cannot succeed in an organization that doesn’t value design. Everyone must advocate for the user, for great design, and for product quality. And, everyone must also be judicious with that advocacy.

A few days into a recent project, our engineers discovered their initial estimates were off — the design would take months rather than weeks to build. Rather than insist on the original design, I came to the next day’s meeting with a fallback proposal. The fastest version of that fallback, though, had significant UX risk. Usability testing bore that out: users couldn’t finish the flow without help. I pushed back: we needed a second milestone before the feature could launch. I compromised on the months-long effort, but stood my ground for a few weeks to get to usable.

Stewardship over choice.

Design is manipulation. That’s uncomfortable for some, but true: when we talk about opinionated design or even just simplicity, we’re shaping how users make choices. And, there’s no way around it: if we insist on giving users explicit choices across the board, that’s choosing on their behalf, too — and it’s choosing additional effort they may not want to expend.

The best experiences limit cognitive load by limiting choice — and again, that’s manipulation. If it sounds like dark patterns, it needn’t: our job is to understand our users well enough to guide them to the choices their best or future selves would want them to make. To some degree, that makes us responsible for their choices — but the notion that we could avoid that is illusory.

Pragmatic designers are familiar with the principles of behavioral science that allow us to do this well, and with terms like choice architecture, libertarian paternalism, and nudges. If these are new to you, I recommend reading Nudge as an introduction.

Users kept contacting us about our messaging app, Emu, telling us our location-sharing feature was broken. It took us a long time to realize the feature was fine: they’d simply disabled location access on their phones. Our users weren’t dumb: they’d just not invested a lot of thought in the choice when we presented it to them. They clearly wanted location access: biasing them toward giving us that access would not have been presumptuous, or nefarious, but merely supportive of their goals.

Purpose over art.

Charles Eames once said design is “an expression of purpose. It may, if it is good enough, later be judged as art.” Many pragmatic designers bemoan the “Dribbblization” of design for that reason: the endless procession of “pixel porn” on Dribbble can feel hollow, like paintings of design instead of design itself.

That’s not an excuse for ugly designs or low-quality products. We want our designs to be beautiful. We revel in that beauty when we achieve it. But it exists in service of the purpose, and indeed great design derives its beauty from its purpose. Just as we dread the judgment of “intuitive” devoid of user needs and personas, so too should we dread the judgment of “beautiful” in a vacuum.

Being a product designer is a lot: you’re responsible for a range of skills that, a decade ago, comprised two or more separate roles. But that synthesis is valuable: great design is a single endeavor across visual, motion, UX, and copy, all in service of the purpose.

Designers have to be both technologists and psychologists. Our purpose is to connect humans and technology, which means understanding the quirks and constraints inherent on both sides: the way people think, and the way in which computers work and apps are built.

When I was working on Inbox at Google, we had an ongoing debate about information density in the inbox. By reducing the height of each message in the list, some argued, we could increase the number of messages onscreen and make it easier to triage lots of email quickly. Others pointed out that doing so would make things cluttered and stressful. The trouble was, everyone was right. What was missing was the purpose: users triaging hundreds of messages a day might be better served by a dense layout, while users with just a few new messages a day would appreciate more whitespace.

Outcome over process.

Our job is to synthesize user needs, business needs, constraints, and team perspectives into an elegant solution. Our toolbox of frameworks and processes exists to serve that need, not the other way around. Great designers have a wealth of techniques at their disposal…and know when not to use them.

I’ve criticized the use of lengthy case studies in design portfolios, and this is why: they show that you know a Process rather than that you know how to design. Just as we craft our designs to serve a purpose, so too must we craft each process to serve a project and a team. Sometimes that reduces your process to an hour with a Sharpie and a piece of paper. Sometimes, you’ll need an ethnographic study and a week-long sprint just to get started. Neither is wrong, but both are wrong when applied inappropriately.

Thanks to Shanan Delp, Ray Liaw, Dan Grover, Ben Lempert, and Megan Stoehr for their feedback — and to you for reading this.