The Looking Glass: Higher Level Design

A long-form post: what does it mean to achieve higher and higher levels of design?

I’ve gotten asked a few times what I thought of Brian Chesky’s talk on leading through uncertainty: a design-led company. So I’m shoving aside the regularly scheduled issue for a spicy take on Should we get just get rid of all those pms?

Just kidding! This essay isn’t about that at all. Or maybe it is. You be the judge!

First things first: I loved the talk. I love Brian Chesky. I love that he makes it real for so many designers that yes, it is indeed possible to co-found and run a Fortune 500 profitable, paradigm changing company as a self-identified designer. I love how he practically yelled at a room of the biggest design audience in the world that they need to have nerve, so fierce was his passion. I laughed when he said Airbnb got rid of pms — I mean, clearly they didn’t (he later clarified it was combined with the pmm role), but it was was an ace serve, a perfect nugget in this era, for this group, to stir debate and reflection.

Let’s put aside pms for a minute.

Yes, the thing I loved most was the call to action for design. Think bigger, he was saying. Stop being afraid of those trench lines dug by your teammates or your last company or the LinkedIn subtitle below your name. Don’t look at your job as a battle for voice and relevance.

Instead, tell yourself: it’s possible to design at higher levels. It’s well within your control to level up.

What does leveling up mean?

A decade ago¹ I wrote about a framework for levels of design:

The more senior the designer, the more abstract the problem they should be solving.

To break it down more tangibly, let’s look at some examples of levels and appropriate responsibilities:

Designer Lvl 1: Design a form that lets people edit their profile. Pretty scoped—assumes there is a profile, and that the solution takes the shape of a form.

Designer Lvl 2: Design the best interface for users to edit their profile. The solution could be a form, could be a WYSIWYG inline editor, could be a modal window.

Designer Lvl 3 (broad): Design a system for editing across everything—profiles, posts, settings, etc. Now we’re not just profiles, but the editing system should be flexible enough to work across the entire app.

Designer Lvl 3 (deep): Design a way to get users to want to update their profiles. Here, the questions the designer is asking is why should users update their profile? And when? And how to best convey the value proposition?

Designer Lvl 4: Design a solution to increase the authenticity of users among your app. Maybe editing profiles isn’t even the right thing to focus on for our ultimate goal, maybe a peer-review system would be better.

Designer Lvl 5:Identify the biggest product problem with your app/company/site and design a solution. At the highest level, the best designers drive the vision for a product.

As you go up the ladder, the problems get more ambiguous. In fact, at the highest level depicted here, you must go spelunking in search of the problem yourself!

Now, with the benefit of hindsight, I find myself wishing this explanation wasn’t so shallow. It’s time to spelunk deeper and pay homage to what design truly is.

So what, exactly, is design?

Steve Jobs said it beautifully:

Design is a funny word. Some people think design means how it looks.
But of course, if you dig deeper, it’s really how it works.

I’ll say it another way:

Design is the act of intentionally trying to influence an outcome.

Design is a means of controlling our destiny. Design is a way to reject a status quo we dislike. Design is how we don’t turn into this dog²:

Design is what we humans have been doing since the dawn of our existence because we were blessed with oh-so-large brains housing that marvelous prefrontal cortex which gave us the ability to plan.

Our hunter-gatherer ancestor was designing when she decided to plant seeds to prevent future hunger. Admiral Nelson was designing when he issued a surprise flank formation to overcome a navy twice his size. Taylor Swift was designing when she brushed her hand casually across his and masterminded that last relationship.

Design is a sword against chaos. Design is the pixie dust for innovation. Design is the foundation for the pursuit of happiness.

And we’re still designing today. Engineers design better language models to improve AI. User researchers design better questions to get more insights. Data scientists design better metrics to more accurately quantify success. Managers design better processes to improve speed and quality of work.

Have I hit you enough over the head with this?

Yeah sure, we might not all call it design. Maybe we call it creating, or architecting, or founding, or directing, or communing with the muse or whatever. But if there is one thing I hope you take away, it is this: design is any creative endeavor in pursuit of an outcome.

Design vs. the Designer Role

You may be rolling your eyes at this point. A definition that includes everything is hardly useful. So what is the point if engineering and design roles today are, practically speaking, different?

Let us turn again to the great wisdom of Mr. Jobs, who said in the next breath after the line above:

To design something really well, you have to get it.
You have to really grok what it’s all about.

How do you really get—how do you grok—something?

You need to spend focused time it, of course. You need to be a student of it, deeply curious—maybe even obsessed—with it. You need to try to design for an outcome, and fail and learn and try and fail and learn and try and succeed and double down and fail and learn and keep trying.

So yes, generally speaking engineers and designers in our tech ecosystem today are not equally skilled at design a way to get the site to load in 100 milliseconds and design a way to get more users to sign up on the site. Each requires grokking different areas of knowledge and learning different skills—say, the nuances of server architecture versus the psychology of user motivation, or how to use Figma versus emacs.

But it is this depth of knowledge + skills in a domain that determines who is most likely to design a great solution within it, not the role.

Roles are a kind of explanatory shorthand because its tiring to repeatedly tell people Hey, I know how to code and I know well the nuances of servers and networking architectures — it’s easier to say I’m an infra engineer.

Unfortunately, all too often, people forget this origin story. They start believing that roles are what determine who is most qualified to come up with the best solution.

This is backwards!

While the role title is a reasonable enough proxy to make certain assumptions (PMs communicate well; designers know Figma, engineers can code) problems arise when people take it too literally. This is how you get nonsense axioms like PMs should be the mini-CEOs of the product (which I am grateful many wonderful PM leaders have been debunking!)

So let’s do this right way, then. Based on the above, here is…

A 3-step, fool-proof formula for getting a team to the best outcome:

1. Define the outcome we want

2. Identify what knowledge + skills are needed to design really well for that outcome

3. Have the person (or people) with the best qualifications for #2 design the solution

Easy peasy, right? Alas, if only theory and practice were the same.³ Unfortunately as we sprint towards nirvana we trip and fall because we meet…

3 annoying roadblocks in trying to execute the above plan:

1. Humans are often bad at knowing who has the most knowledge+skills in some domain.

   Ah, human biases. The illusory superiority that makes us think we are way better than we are, like how 93% of Americans think they are better than average at driving. Or, if you are truly an expert, it’s the opposite—you have a tendency to doubt you are as good as you are, as the Dunning Kruger Effect shows. The irony is that those who are most incompetent in some domain are the ones who are the least self-aware about it!

2. Humans are often bad at knowing what knowledge+skills are needed to design well for an outcome.
   This is a special meta case of #1. What knowledge+skills does one need to win the Superbowl? To produce hit album after album? To run a country? Unless you’ve achieved this yourself (or studied a ton of people who have), it’s pretty difficult to truly know. (Though there are many, many armchair experts out there!)

3. Humans are often bad at identifying the most important outcomes to focus on. This is also a special meta case of #2. Should we spend more time with our partner, or more time building a career? At work, should we focus on improving our manager relationship, or developing more product ideas? On developing more product ideas, should we prioritize retaining or acquiring new users?

These 3 annoying Roadblocks explain a slew of common team tensions:

1. Emma is actually extremely qualified to design the go-to-market strategy because no one else knows as much about how new customers think as she does. Alas, no one (including Emma) sees it that way because her title is User Researcher (example of roadblock #1 and #2 above).

2. Betty is the engineering lead on the core product team. She’s frustrated by the slowness of the product and has seen at her past company the correlation between performance and customer happiness. She knows that only 2 months of dedicated focus would have a big impact on performance; however, she can’t convince her product and design partners because they want to ship more features (example of roadblock #3).

3. Product designer John is upset that he isn’t invited to strategy brainstorms, and that there isn’t a single designer on the exec team or board. He feels this is a sign The company doesn’t appreciate design. At the same time, he has never taken an interest in learning the ins-and-outs of his company’s key health metrics, which is why his peers don’t see him as a strategic thinker (example of roadblock #2).

4. Stephen is the first growth hire at a buzzy start-up. After a few months, he suggests to the founder, Este, a radical experiment to make certain features of the site free to use. Este says This is definitely not going to work and tells Stephen to abandon it. Stephen secretly launches a small a/b test on the side and the results are fabulous (example of roadblock #1).

Aspire for Higher Level Design

My friends, to escape from the shackles of role definitions, we must pursue higher-level design.

High-level design means not limiting yourself to activities you do but rather outcomes you’d like to influence.

It means growing the scale of your ambitions on those outcomes. Maybe you start off designing a screen that converts, then a feature that enables, then an app that retains, then an experience that delights, then a business that sustains, then a way of life that fulfills. Maybe you design a way to change the world and it’s real and meaningful in the way you intended, not just some corporately jingo.

It means getting humble and getting feedback. Ask around: what are you better at than you thought? Worse at than you thought?

It means doing your homework. What unique skills and knowledge are needed if you want to contribute to strategy? To marketing? To revenue? To better collaboration? Which of these skills matter the most?

What you will uncover if you do this is the sheer beauty across all design.

For example, it blew my mind to discover that designing a robust UI components library is the same kind of art as designing a performant database system, just applied to different domains of knowledge. Within each domain, depth of skill determines whether a design is crude or well-crafted.

We can see outcomes like the roots of a tree; for every outcome, there are branches of knowledge+skills that are needed to design well for that outcome, some thicker and more important, others less so.

The closer you get to the base of the tree, the higher your level of design.

For example, if your goal is to be like Steve Jobs and make exceptional products that people love, then you’ll need to know…

1. What is a big problem people have?

2. What does an exceptional solution look like for that problem? Where is the bar today?

3. What makes people love something?

4. What is easy to build, what is hard but possible, what is impossible?

5. What shape will our solution take?

6. What functionality will we enable?

7. How do we want people to think about it?

8. How will people discover it?

9. How will we make money off of it?

10. Who do we need to build this?

11. What will the end product look like?

12. How will we improve the product over time?

13. Etc…

Each single question unfurls another long list of questions. For example, to dive into number 9, How will we make money off of it? you’d need to understand business models and pricing and cost and margins and all that jazz.

I hope what you can appreciate is that the sheer surface area of what it takes to make an exceptional product people love is mind-boggling. Doing any of the above badly might doom the outcome. (But of course, it is its own design problem to know which of these questions matters the most for the outcome!)

This is what higher-level design looks like. It is designing solutions instead of features, outcomes instead of products. Designing at higher levels is like throwing another dimension onto your chess game.

And there is a higher level still, beyond making an exceptional product people love. There is designing a living organism—a company—that continues to do this well and sustainably, over the long run. That dimension—a CEO’s purview—requires designing org structures and processes, cultural norms and narratives. It may require, as Brian Chesky said, designing new roles altogether.

And of course we can ascend further still into the government’s purview—designing a better society, one that is healthier and happier, more prosperous and free.

So yes, this is design. These are design problems, and the world needs better higher-level design.

2 bonus mini-essays for paid subscribers:
The Craft of Design + Lines to Use with Your Teammates

Like this essay? Support my writing with a monthly subscription (which is about the price of buying me a fancy coffee enlivened with nut juice.) Or jump ship with me from Twitter to Threads, where I’m still @joulee.

Paid subscribers get access to two companion essays, one for the craftspeople and another on specific phrases you might use to make the above actionable in your day-to-day.