Scott Berkun: 5 Dangerous Ideas for Designers

I don’t know if I’d seen this article (and talk) from Scott Berkun a decade ago and just missed it, or maybe I read it and it went over my head, but man oh man I wish someone had stapled these ideas to my front door back then. This reads like a graduate course that not enough design students are taking. I was nodding along so vigorously I closed my activity ring.

I say that because I’ve come to discover each one of these things on my own through trial and error (and probably by osmosis through some uncredited smarter people telling me these things in a way that I was too slow to internalize). 

His list of 5 dangerous ideas are just perfect—make sure you read and internalize his article more than this short ramble.

Here are my thoughts, emphatic head nods, and tacky add-ons:

1. Everyone is a designer

I definitely used to roll my eyes at this one. Where Scott landed on “ambassador”, I landed on “enabler”—a designer has the unique position to enable everyone on the team to add their expertise, experience, skills, etc. to the solution. But only if the designer lets them. In my experience, that’s two-sided collaboration: bringing others into my process, and forcing myself into others’ processes. Kindly forcing, of course. 

2. You have no power

This is the one I would optimistically add on to—or frame a little differently, at least. 

1. I think one inherent way that designers do have power, and Mike Monteiro talked about this in his book Ruined By Design, is that designers are a vital (if not required) part of any process they are in. In product design specifically, someone playing the role of the designer is going to give it form—define the interactions, give the information importance and hierarchy, etc. These are decisions, and decisions are power. That doesn’t mean they are final decisions, and that’s a source of frustration in this conversation. But just like Mike won’t let designers abdicate responsibility for bad, evil products going out the door and into the world, you can’t say you don’t have power. 

2. The second way designers have power is built off the first way: you can articulate things in a way that no one else can. You can make people see. Is there tension on the team about what’s most important? Are people talking in circles? Do you agree with a faction of the team—and want to enable them to make a better case for their solution? GO DESIGN IT. Put the idea into the room. Give it form. Ideas can claim squatter’s rights. In the bad version of brainstorming, the loudest voice wins, right? Well, you can use that to your advantage. You have skills that can give you a louder voice. You can use that to advocate for good things (and bad things). And that’s power! But you have to use the skills (i.e., your ability to give form to ideas) that enable that power, not just wait for others to tell you haw to use those skills.

3. The generalists are in charge

This is still mainly about power, just focused on the people who have it—and why. And I think accepting that is ok. The idea of a Jony Ive-like role is not reasonable for most organizations. Design is a capability that has to be embedded into the organization, not a top down model. That would probably not actually make most designers happier, right? I’ve confronted this and accepted it—and referencing number 1, I can design better products by enabling those generalists with power to make it better with me.

4. You are in sales

I’ve used this line so many times—and with no attribution! (Sorry Scott…) The way I’ve framed it for the designers I’ve coached and mentored is this: great work doesn’t speak for itself. You have to speak for it. And it also relates back to power. Or more specifically, how designers often feel the lack of power: that they don’t have the impact they want. Worst case scenario, the end product isn’t as good as it should be. Their design skills might get called into question, when in reality it might just be their sales skills. Which are actually design skills after all! You want impact? Advocate like hell for good ideas and solutions. (Doesn’t “advocate” sound better than “sell”? Ick.)

5. Creativity is a risk

I came to this from the “you need a point of view” angle. I got feedback that I needed to bring my expertise to the proverbial table earlier and often-er. And that’s risky. But this is where I’m often talking to designers about confidence. Having confidence is hard. It’s not a skill, per se, but it’s something you can work on. Confidence in your creativity and expertise is risky and vulnerable. But important.

Design, self-assessing, and AI

Based on the headline to this post, The Future of Design? Using AI to Enhance Human Cognition and Creativity, I did not expect EEGs and virtual reality headsets. You should go read it before I spoil anything more than I have already.

What drew me in initially (before the turn in the second act) was the clear articulation of the role of metacognition for designers—thinking about our own thought process:

Metacognitive monitoring specifically involves assessing one's own knowledge, thoughts, and progress on a task.

That’s a much more science-y sounding way of describing what I find myself coaching designers about fairly often. This covers a theme that I often boil down to catchphrase-like idioms—“fall in love with a problem, not a solution,” or “don’t get lost in the pixels,” etc.

The general theme here is to deliberately step back and evaluate how well a solution is working to solve the given problem. And as stated above, assess our own knowledge, thoughts, and progress on a task—that last bit may be the hardest to be honest with ourselves about.

At our worst, designers do some initial divergent thinking, pick a direction, and then start designing the solution—while in parallel building the case for why this direction is correct and great. This is necessary, but also a trap. Solidifying the case for the solution will help communicate it to others (being your own internal product marketer). But beware: it can also cut off the individual’s ability to be properly critical about the solution—which is necessary to make it better.

Oftentimes, the designer spends a good bit of time or effort nailing down a solution, while also building the case to defend it. This can lead to those meetings that we’ve all experienced where feedback is not received productively because we defend our approach, our work, our baby. We dig in our heels.

This leads to the emotional aspect of the article and the study that it centers on. What stood out to me, as a parent of two young boys, was the focus on emotional regulation. I’m far from a paragon of emotional regulation, but it’s often top of mind in my parenting approach—for both myself and my kids. (It’s a process, right?)

An important part of the metacognitive monitoring process is monitoring your emotional reactions to design ideas and options. Emotions give us clues that can indicate levels of confidence, inspiration, and subjective uncertainty (Taura & Nagai, 2017). Monitoring emotions accurately during design, however, can be challenging.

I’ve been doing this metacognitive monitoring more proactively for a lot longer as a professional and a designer than as a parent. I believe this is a strong trait for myself and probably for most seasoned designers—self-assessing, self-editing, self-evaluating. This article is helpful for me to articulate these concepts more clearly as I work to make my junior colleagues more self-aware of their process.

And then—this is where I sat bolt upright, as I did not expect things to go in this direction—the article delves into a study monitoring brain activity in real-time to proactively notify a designer when their emotions change, and how that may be a helpful poke that can inform their own metacognition/self-assessment during the design process. I won’t do that part justice, so go check it out.

Ideas multiplied by execution

I can’t believe I have never come across this brilliant nugget from Derek Sivers:

Ideas are worth nothing unless executed. They are just a multiplier. Execution is worth millions.

I love this as an equation. Beautiful.

The hard part

Nick Scialli puts very nicely something that non-technical folks don’t often say (or understand?) when extolling the virtue of general purpose LLM use cases on the topic of “replacing” roles like developers when it comes to code generation:

Impressive! But here’s the problem: generating code was never the hard part.

The value I bring to my job is not generating code. I mean, I suppose that is a part of it in the end, but my value is largely in the work that happens before I generate the code: things like requirements clarification, negotiation, technical design, and tradeoff analysis.

He goes on to outline how the model should have A) asked clarifying questions to better tailor the output to the requirements and B) essentially used abstraction laddering to ensure that the function was even needed.

He’s right, but also: the model (ChatGPT in this case) can and probably already does do those things if told to or asked to. What will be more important is knowing how to work well with these capabilities to allow someone like Scialli to spend more quality time doing the valuable things he outlines. That part has probably been talked about ad nauseam.

To strengthen the case for the role being much more than code generation, he points out that the task of clarifying requirements of a request and determining if the initial request is correct needs to be done “on a much, much larger scale,” as he puts it. That point is starting to get at the corollary from the “how to work well” point I made above: when to work with models and agents. Because we’re still a ways off from those models being good at what Steve Jobs described:

Designing a product is keeping five thousand things in your brain and fitting them all together in new and different ways to get what you want. And every day you discover something new that is a new problem or a new opportunity to fit these things together a little differently.

That’s the broader value that Scialli is getting at. Productivity tools are not replacements, but—while impressive, revolutionary, and largely mind-blowing—still very primitive tools.

Adoption through better experiences, not through capabilities

In Ethan Mollick’s post What Can be Done in 59 Seconds: An Opportunity (and a Crisis), he touches on a subject that is so important that it’s easy to overlook it as a “of course that’s what’s happening” type of thing.

He highlights 2 recent developments that are not as model-capability-focused as most of what has gotten people excited over the last year.

1. Integrating LLMs into existing tools that a billion people use: Microsoft’s Copilot is now integrated into their Office suite

2. Creating and sharing purpose-built GPTs: OpenAI’s GPT Store and teams

His articulation of challenges in getting the most value out of ChatGPT is revealing:

It certainly didn’t help that the ubiquitous chatbot approach to AI hid a lot of its power, which was only revealed after hours of experimentation.

This is a much better way of articulating what I oversimplified (and ranted about) as a usability problem. It is a usability and a usefulness problem, but not simply a “user didn’t know how to complete a task” style of usability. Open-ended chat is amazing if you know how to have the conversation and ask the right questions. I think we can all agree that people are generally not great at doing exactly that in real life, so why would we collectively get better at asking great questions when we’re talking to a bot?

This feels like the next big step in the overall trend of how GenAI becomes more and more mainstream—usable and useful.

The technology came first: LLMs existed for a good while, but only a few people used them as they grew in capability.

The first good UX came next: ChatGPT was a usability breakthrough—for all of chat’s usability shortcomings, it is also the thing that made the technology accessible to billions.

Now comes thoughtful products, experiences, and ecosystems: the overall ease of use is increasing as the tech is being integrated (a la Microsoft), democratized (a la GPT Store), and normalized—not just a select few will be using this in the background of their work, but it will be part of their collaboration in teams and more.

And this growth phase as I’ve described it is completely ignoring how fast the technologies underneath are advancing. That will also increase adoption in more and more scenarios, but will have to follow the same paths to success as any other technology: to meet the fullest potential, everything must be thoughtfully and deliberately designed into peoples’ lives.

Isaac Asimov Asks, “How Do People Get New Ideas?”

Isaac Asimov on the circumstances of creativity from 1959:

It seems to me then that the purpose of cerebration sessions is not to think up new ideas but to educate the participants in facts and fact-combinations, in theories and vagrant thoughts.

His term “cerebration sessions” is a wonderful 1950's term. I might steal that.

And the concept of giving participants “sinecure” tasks to do for payment—making the creativity a less important task—is genius. Getting paid to "think" is probably more common now than back then, but it's still a difficult sell.

Realizing—and destroying—the value of multi-disciplinary collaboration

I think a lot about collaboration. How to do it. When to do it. And most philosophically, why to do it. A former manager of mine, Greg, once put it so plainly that I immediately fell in love with how he wrote it:

Interdisciplinary collaboration is hard by definition. There will be disagreements about what is important. This is exactly the point.

I’ve reused that line (and line of thinking) a lot over the years, and I feel more strongly about that than ever. I’ve used that to set expectations with teams and colleagues. I’ve used it to comfort myself (or others) after a maybe-too-spirited debate in a meeting. That simple three sentences packs a lot into it.

Interdisciplinary collaboration is hard by definition

“Interdisciplinary” is carrying a lot of weight in this first part. Depending on your experience or perspective, you might not think that it is actually very hard. I used to think of the scope of this for myself as collaborating with engineers and user researchers. Then I added product managers into that mix. But I think that’s a designer’s view of the world—those are the most basic and closely related inputs and outputs to a designer’s work product. And in a more mature team or organization, all of those disciplines are generally rowing in the same direction and have some experience working in those types of product teams, so the collaborative cow paths are pretty well worn.

I’ve learned to expand my definition of “interdisciplinary” to mean basically “everyone with a stake in an effort.” Part of my career maturity has exposed me to working hand in hand with data scientists, architects, strategists, marketers, MBAs, PhDs, 24 year olds, 64 year olds, etc. And in a lot of cases, they weren’t experts in working with designers or engineers—and most importantly, they weren’t experienced in a product-driven style of working. So if we’re not all familiar with the same playbook or principles, how do we get moving and determine some ways of working?

There will be disagreements about what is important.

At BCG, when we are assembling a new team, one excercise we do to establish working norms has a series questions that address preferences like communications (Slack, email, phone, etc.) and feedback style (real-time, scheduled, etc). My favorite one is the spectrum of when to collaborate, and I’m typically the most extreme one at the “Start Together” end of the range.

Why is that? Because I want to be “the collaboration guy”? Not really. I’ve just learned that if we don’t start together, it will lead to misaligned everything. Misaligned priorities, information, schedules—even a misaligned understanding of the problem we’re solving. And if we’re not on the same page, we’re going to have two primary problems: collaborative process and collaborative decision making.

Process is important, but I’m not that designer who pontificates on the elegance of the double diamond, etc. There is no “one true way” that I’m arguing for. I’m just trying to realistically make sure our processes are compatible at a minimum and electric as an aspiration. Figuring out the various inputs and outputs on an interdisciplinary team is hard work, but vital.

But doing that hard work starts to reveal what’s important to different people and disciplines. That lays the ground work for better collaborative decision making. And decision making is where collaboration is tested.

This is exactly the point.

If you’re not arguing, if there isn’t any friction in how you make decisions, if everyone is doing what they’ve always done in their own silo’d disciplines—why are you working together? Are you just coordinating and not collaborating? Boring.

When it comes to decision making, that’s where what’s important is on full display. Timelines, budgets, user needs, business goals, etc. Everyone is representing some subset of priorities when you’re making decisions. They might care about their process, their metrics, their boss, or their users. Now, they might not be saying those things, but it’s baked into their recommendations, questions, and solutions. And that’s OK. Acknowledge those differences and talk about them, not just the solution. It’s easy to try and ignore them, though.

I see these symptoms of ignoring or working around those differences flare up in many teams. These are warning signs that I need to invest more time in our collaborative relationship. Things like:

• You find yourself saying “Why are they asking for that?”

  • This is a great flag that someone doesn’t understand others’ processes, and they are expecting something that will plug into their process.

• You feel a general sense of stay-in-your-lane

  • If someone is asking you “Why are you asking for that?” that probably means that they are unclear about the role you are playing on the team, what your responsibilities are, and how they might overlap with theirs. At worst, they don’t want to let you into their process.

• You’re told that others “can handle it” without you

  • When someone says “We can handle that, we don’t need design for that,” they aren’t acting open to collaboration. There can be many valid reasons, too, but it’s worth interrogating. If this is a constant

If the team is not careful, this is where we can squash the value of interdisciplinary collaboration. There is trap where we collectively gloss over the differences, stay in our own lanes, and then just deliver mediocrity.

But do we need to collaborate?

This all doesn’t even get into the need for collaboration: to solve hard problems. I believe that most regular problems have been solved (at least once), and an existing solution gives us a playbook to follow or at least an example to draw inspiration from. A solution from the real world is a great way to align a team to a vision—“it’s like Github, but for XYZ”—and that not only makes collaboration easier, but it also makes solving the problem easier in a lot of ways.

It is the challenges that need expertise that also need collaboration. You can’t have one without the other. I like to think that the solved problems I mentioned above are also generally single-domain or single-discipline problems. Data scientists have their own set of solved problems, designers have design systems ad nauseam, etc. It’s only when we reach the limits of what can be solved on our own that it gets interesting.

So we identify a new problem and it can’t be solved without bringing in an expert in that thing, and then we need to realize that we haven’t worked with them before, and they probably haven’t worked with us before (or someone like us). This is going to be hard.

But that is exactly the point.