Not crazy

I was listening to Jenny Wen on Lenny's Podcast and about 8 or 9 minutes in, I got so excited I had to turn it off. Weird, right? But I paused it so I could capture my thoughts and the moment I realized that… I’m not crazy?

Why I’ve felt like an oddball

I’ve bounced between two primary conflicting beliefs over the years:

1. I’m good at this—look, people like me and things I work on are good

2. I’m lucky and/or hiding in places where my bullshit passes

Note: I don’t call this imposter syndrome because A) that’s quite a trope by now, and B) I don’t really believe the second one. (I’m too egotistical for that). But because I’ve never worked in “big tech” or somewhere with a big, well-oiled team, I’ve always been left wondering, “what if…”

Much of my success has come from thinking fast, moving forward, politicking for the right thing, and delivering damn good work in demanding situations. A lot of that happened in the consulting world, which was a great place for me to evolve beyond the often dogmatic world of human-centered design. We built real software with real impact. And in many ways, we did have well-oiled teams, they just didn’t look like the ones being lionized in online product and design circles.

Consulting led me to be a more ruthless, efficiency-seeking pragmatist—cutting out anything that felt like design theater, being more hypothesis-driven, re-using the good parts of process, and looking for any shortcut to impact.

All of which is… good?

Jenny characterized two ways of working she’s seen emerge recently (under the clickbait-y title of the podcast, “The design process is dead”):

1. Supporting the execution (or I’d just say “Delivering”)

2. Creating a vision or direction—for the team to sprint towards

This was my ⚡ moment: this is almost all I’ve done for the last 2-3 years.

Delivering, or “Supporting the execution”

NOTE: I don’t love calling this support, and I think that’s probably why I renamed it delivering. I think this was what I referred to in my own head as ”read and react”, Which, whenever I say it is, when I feel these pains of doubt about, I don’t know the sustainability of it, or the validity of the way I’m doing things. I think the output from this way of working is fine, but it was the lack of a formal process that made it feel slightly off. And it felt like I would have trouble explaining it to my next employer when they ask how I work.

The last year I was BCG, everyone was ChatGPT crazy. It was 2023, after all. I was lucky enough to lead the design and be the pseudo-product-manager for an internal LLM-driven slide building tool called Deckster. (Building decks, get it?)

It was an awesome experience because it was on the cutting edge of building on top of LLMs for an actually valuable use case for a big organization. And it was pretty good! I missed using it when I left. It was better than anything else that was shipping in terms of public products at the time.

But what was most interesting to me, a student of collaboration, was the way our team had to change our ways of working as we built a product like this. It was a big part of the Deckster case study I made when getting my job at Gecko. From that case study, in early 2024:

Things move extremely fast, which broke our “design-test-build” pattern. As ideas came from users, leaders, engineers, and everyone else, [we] had to separate experiments from development tasks. Many items were explored for a day or a week before being tossed or incorporated into the roadmap. Feasbility has never been harder to pin down than when working with generative AI…

This was even before Claude enabled the “cheap execution” that we’ve seen explode over the last few quarters. But the pace of feature development on top of the GPT-4 models was insane at the time. We started doing “product crits” instead of design crits because everyone was bringing new work and experiments for sharing and feedback.

As the designer, you have to be the one to keep it all in your head in order to shape this new thing towards a cohesive product—in real time. That’s never easy, but it feels more under control when there is a more designerly process in place. When you’re doing it live—with the whole team, with senior stakeholders, in 1:1s—you need quick thinking and experience to make decisions snap together into a whole.

Set a direction

I think I (and many designers) have traditionally tried to do this, and even been responsible for it within product teams. But the way in which I’ve approached it has certainly changed.

Last fall I joined the Gecko Manufacturing team as the team was moving from a technical proof of concept system towards deploying with third party operators at forges. I was coming from our flagship field software team with a clear goal to transfer my knowledge into a new team building a new system.

I dove deep into the problem space and hardware/software stack, and without waiting to truly understand everything about it, I took a drastic, scary step: I vibe coded a prototype that overhauled their entire application.

It was not perfect, but it was right enough that the team was able to rally around it, poke holes in it, ask great questions, and make it better than I could. And then we used it to inform the general direction of the app for months after that. But I didn’t revisit it as we made new decisions. I didn’t make v2 or v3 every month. It served its purpose of aligning us at a critical point in time so that we had a shared understanding of what the product could and should be.

In the before times, this type of prototyping was different. It was slower, sure. But it was looked at as a source of truth, which meant it was informed by research. Now it can inform the research. A good prototype was a way to de-risk what was to be built. Now building and shipping is its own de-risking process.

So what?

I don’t know really. I still rely on some tried-and-true human-centered design methods and pull them out of the quiver as needed. But I rarely think about or pitch anyone on anything resembling a double diamond. I am still advocating for more design-forward and user-centered approaches to problems, but my rhetoric has changed.

It’s a very interesting time. And hearing someone else say the things I’ve been feeling on a popular podcast felt like a bit of validation.

What does it mean for what comes next, how the product triad roles converge, or whether or not we’ll all have jobs in a few years? ¯\_(ツ)_/¯

Be non-fungible

I don’t remember who this phrase, “be non-fungible”, was attributed to, but I think it was on an episode of Lenny’s Podcast with Marc Andreessen, and it was referenced during a conversation about how AI is reshaping roles, enhancing the best people even more than the average person, blah blah blah.

But it struck me like a lightning bolt when I heard it. I’ve rallied against senior leaders thinking of junior roles and people as fungible—whether talking about staffing particular engineers on a team, or even the broader world of generalists in consulting. It always rubbed me the wrong way—but to an unreasonable degree. Like, my reactions in those scenarios probably held me back from developing better relationships with those leaders. I think it was because I knew I was always doing more and different things than the next designer, so I was special, I wasn’t fungible.

This simple phrase, when used as a way of looking at myself or presenting myself, was novel to me. Or at least, something I’d never tried explicitly articulating like that. And I fell in love with it, because I’ve struggled to position myself when looking for a job, or asking for a promotion—or even introducing myself to a new team. I think it is because I feel the assumptions that others make about designers in whatever room I am in. I know most people haven’t worked with great designers, and I expect that I’m going to be a change of pace for them. Not just “better”, but very different in several ways that come from experience and training. But that doesn’t lend itself to a pithy headline on natebishop.com, does it?

Not sure what I’ll do with this lovely phrase, but pretty soon you’ll see my narrative on the homepage shift to include “non-fungible”.

Two-way collaborative empathy

This observation from John Gruber at Daring Fireball lives in my head rent free:

One thing I learned long ago is that people who prioritize design, UI, and UX in the software they prefer can empathize with and understand the choices made by people who prioritize other factors […]. But it doesn’t work the other way: most people who prioritize other things can’t fathom why anyone cares deeply about design/UI/UX because they don’t perceive it.

I worry about this a lot when working with new people and teams. Is this especially germane to designers because designers have traditionally been put in arranged marriage situations? I know I’ve been dropped into those environments where they are now paired with people who “don’t perceive” the value of design, understanding users, making thing good, etc. Which then just leads to terrible collaboration, etc.

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.