Tommaso Nervegna, a Design Director at Accenture Song, gives one of the clearest practitioner accounts I’ve seen of what using Claude Code as a designer looks like day to day.

The guide is detailed—installation steps, terminal commands, deployment. This is essential reading for any designer interested in Claude Code. But for me, the interesting part isn’t the how-to. It’s his argument that raw AI coding tools aren’t enough without structure on top:

Claude Code is powerful, but without proper context engineering, it degrades as the conversation gets longer.

Anyone who’s used these tools seriously has experienced this. You start a session and the output is sharp. Forty minutes in, it’s forgotten your constraints and is hallucinating component names. Nervegna uses a meta-prompting framework called Get Shit Done that breaks work into phases with fresh contexts—research, planning, execution, verification—each getting its own 200K token window. No accumulated garbage.

The framework ends up looking a lot like good design process applied to AI:

Instead of immediately generating code, it asks:

“What happens when there’s no data to display?” “Should this work on mobile?” “What’s the error state look like?” “How do users undo this action?”

Those are the questions a senior designer asks in a review. Nervegna calls it “spec-driven development,” but it’s really the discipline of defining the problem before jumping to solutions—something our profession has always preached and often ignored when deadlines hit.

Nervegna again:

This is spec-driven development, but the spec is generated through conversation, not written in Jira by a project manager.

The specification work that used to live in PRDs and handoff docs is happening conversationally now, between a designer and an AI agent. The designer’s value is in the questions asked before any code gets written.

Steve Yegge has been talking to nearly 40 people at Anthropic over the past four months. What he describes looks nothing like the feature factory world that NN/g catalogs. No 47-page alignment documents. No 14-meeting coordination cycles. Instead, campfires:

Everyone sits around a campfire together, and builds. The center of the campfire is a living prototype. There is no waterfall. There is no spec. There is a prototype that simply evolves, via group sculpting, into the final product: something that finally feels right. You know it when you finally find it.

As evidence of this, Anthropic, from what I’m told, does not produce an operating plan ahead more than 90 days, and that is their outermost planning cycle. They are vibing, on the shortest cycles and fastest feedback loops imaginable for their size.

No roadmap beyond 90 days. They group-sculpt a living prototype. Someone told Yegge that Claude Cowork shipped 10 days after the idea first came up. Ten days. A small team with real ownership, shipping at the speed the tools now allow.

Yegge argues this works partly because of a cultural requirement most companies would struggle with. He describes a three-person startup called SageOx that operates the same way:

A lot of engineers like to work in relative privacy, or even secrecy. They don’t want people to see all the false starts, struggles, etc. They just want people to see the finished product. It’s why we have git squash and send dignified PRs instead of streaming every compile error to our entire team.

But my SageOx friends Ajit and Ryan actually want the entire work stream to be public, because it’s incredibly valuable for forensics: figuring out exactly how and why a teammate, human or agent, got to a particular spot. It’s valuable because merging is a continuous activity and the forensics give the models the tools and context they need to merge intelligently.

So at SageOx they all see each other’s work all the time, and act on that info. It’s like the whole team is pair programming at once. They course-correct each other in real time.

Yegge calls this “the death of the ego.” Everyone sees your mistakes, your wrong turns, how fast you work. Nothing to hide. Most designers and engineers I know would be deeply uncomfortable with that. We like to polish before we share. We present finished comps, not the 13 variations we tried and abandoned.

But if the campfire model is where things are heading—and the speed advantage over the feature factory is hard to argue with—then the culture has to change before the process can. That’s the part nobody wants to talk about.

I recently spent some time to move my entire note-taking system away from Notion to Obsidian because the latter runs on Markdown files, which are text files. Why? Because AI runs on text.

And that is also the argument from Patrick Morgan. Your notes, your documented processes, your collected examples of what “good” looks like—if those live in plain text, AI can actually work with them. If they live in your head, or scattered across tools that don’t export, they’re invisible.

There’s a difference between having a fleeting conversation and collaborating on an asset you both work on. When your thinking lives in plain text — especially Markdown — it becomes legible not just to you, but to an AI that can read across hundreds of files, notice patterns, and act at scale.

I like that he frames this as scaffolding rather than some elaborate knowledge management system. He’s honest about the PKM fatigue most of us share:

Personal knowledge management is far from a new concept. Honestly, it’s a topic I started to ignore because too many people were trying to sell me on yet another “life changing” system. Even when I tried to jump through the hoops, it was all just too much for me for too little return. But now that’s changed. With AI, the value is much greater and the barrier to entry much lower. I don’t need an elaborate system. I just need to get my thinking in text so I can share it with my AI.

This is the part that matters for designers. We externalize visual thinking all the time—moodboards, style tiles, component libraries. But we rarely externalize the reasoning behind those decisions in a format that’s portable and machine-readable. Why did we choose that pattern? What were we reacting against? What does “good” look like for this particular problem?

Morgan’s practical recommendation is dead simple: three markdown files. One for process, one for taste, one for raw thinking. That’s it.

This is how your private thinking becomes shared context.

The designers who start doing this now will have documented judgment that AI can actually use.

Many designers I’ve worked with want to get to screens as fast as possible. Open Figma, start laying things out, figure out the structure as they go. It works often enough that nobody questions it. But Daniel Rosenberg makes a case for why it shouldn’t be the default.

Rosenberg, writing for the Interaction Design Foundation, argues that the conceptual model—the objects users manipulate, the actions they perform, and the attributes they change—should be designed before anyone touches a screen:

Even before you sketch your first screen it is beneficial to develop a designer’s conceptual model and use it as the baseline for guiding all future interaction design decisions.

Rosenberg maps this to natural language. Objects are nouns. Actions are verbs. Attributes are adjectives. The way these elements relate to each other is the grammar of your interface. Get the grammar wrong and no amount of visual polish will save you.

His example is painfully simple. A tax e-sign system asked him to “ENTER a PIN” when he’d never used the system before. There was no PIN to enter. The action should have been “CREATE.” One wrong verb and a UX expert with 40 years of experience couldn’t complete the task. His accountant confirmed that dozens of clients had called thinking the system was broken.

Rosenberg on why this cascades:

A suboptimal decision on any lower layer will cascade through all the layers above. This is why designing the conceptual model grammar with the lowest cognitive complexity at the very start… is so powerful.

This is the part I want my team to internalize. When you jump straight to screens, you’re making grammar decisions implicitly—choosing verbs for buttons, deciding which objects to surface, grouping attributes in panels. You’re doing conceptual modeling whether you know it or not. The question is whether you’re doing it deliberately.

Everyone wants to talk about the AI use case. Nobody wants to talk about the work that makes the use case possible.

Erika Flowers, who led NASA’s AI readiness initiative, has a great metaphor for this on the Invisible Machines podcast. Her family builds houses, and before they could install a high-tech steel roof, they spent a week building scaffolding, setting up tarps, rigging safety harnesses, positioning dumpsters for debris. The scaffolding wasn’t the job. But without it, the job couldn’t happen.

Flowers on where most organizations are with AI right now:

We are trying to just climb up on these roofs with our most high tech pneumatic nail gun and we got all these tools and stuff and we haven’t clipped off to our belay gear. We don’t have the scaffolding set up. We don’t have the tarps and the dumpsters to catch all the debris. We just want to get up there. That is the state of AI and transformation.

The scaffolding is the boring stuff: data integration, governance, connected workflows, organizational readiness. It’s context engineering at the enterprise level. Before any AI feature can do real work, someone has to make sure it has the right data, the right permissions, and the right place in a process. Nobody wants to fund that part.

But Flowers goes further. She argues we’re not just skipping the scaffolding—we’re automating the wrong things entirely. Her example: accounting software uses AI to help you build a spreadsheet faster, then you email it to someone who extracts the one number they actually needed. Why not just ask the AI for the number? We’re using new technology to speed up old workflows instead of asking whether the workflow should exist at all.

Then she gets to the interesting question—who’s supposed to design all of this?

I don’t think it exists necessarily with the roles that we have. It’s going to be a lot closer to Hollywood… producer, director, screenwriter. And I don’t mean as metaphors, I mean literally those people and how they think and how they do it because we’re in a post software era.

She lists therapists, psychologists, wedding planners, dance choreographers. People who know how to choreograph human interactions without predetermined inputs. That’s a different skill set than designing screens, and I think she’s onto something.

Daniel Miessler pulls an idea from a recent Karpathy interview that’s been rattling around in my head since I read it:

Humans collapse during the course of their lives. Children haven’t overfit yet. They will say stuff that will shock you because they’re not yet collapsed. But we [adults] are collapsed. We end up revisiting the same thoughts, we end up saying more and more of the same stuff, the learning rates go down, the collapse continues to get worse, and then everything deteriorates.

Miessler’s description of what this looks like in practice is uncomfortable:

How many older people do you know who tell the same stories and jokes over and over? Watch the same shows. Listen to the same five bands, and then eventually two. Their aperture slowly shrinks until they die.

I’ve seen this in designers. The ones who peaked early and never pushed past what worked for them. Their work from five years ago looks exactly like their work today. Same layouts, same patterns, same instincts applied to every problem regardless of context. They collapsed and didn’t notice.

Then Miessler, almost in passing:

This was a problem before AI. And now many are delegating even more of their thinking to a system that learns by crunching mediocrity from the internet. I can see things getting significantly worse.

If collapse is what happens when you stop seeking new inputs, then outsourcing your thinking to AI is collapse on fast-forward. You’re not building pattern recognition, you’re borrowing someone else’s average. The outputs look competent. They pass a first glance. But nothing in there surprises anyone, because the model optimizes for the most statistically probable next token.

Use AI to accelerate execution, not to replace the part where you actually have an idea.

There’s a version of product thinking that lives in frameworks and planning docs. And then there’s the version that shows up when someone looks at a screen and immediately knows something is off. That second version—call it product sense, call it taste or judgement—comes from doing the work, not reading about it.

Peter Yang, writing in his Behind the Craft newsletter, shares 25 product beliefs from a decade at Roblox, Reddit, Amazon, and Meta. The whole list is worth reading, but a few items stood out.

On actually using your own product:

I estimate that less than 10% of PMs actually dogfood their product on a weekly basis. Use your product like a first-time user and write a friction log of how annoying the experience is. Nobody is too senior to test their own shit.

Ten percent. If that number is even close to accurate, it’s damning. You can’t develop good product judgment if you’re not paying attention to the thing you ship. And this applies to designers just as much as PMs.

Yang again, on where that judgment actually shows up:

Default states, edge cases, and good copy — these details are what separates a great product from slop. It doesn’t matter how senior you are, you have to give a damn about the tiniest details to ship something that you can be proud of.

Knowing that default states matter, knowing which edge cases to care about, knowing when copy is doing too much or too little—you can’t learn that from a framework. That’s pattern recognition from years of seeing what good looks like and what falls apart.

And on what qualifies someone to do this work:

Nobody cares about your FAANG pedigree or AI product certificate. Hire high agency people who have built great side projects or demonstrated proof of work. The only credential that matters is what you’ve shipped and your ideas to improve the product.

Reps and shipped work, not reading and credentials. The people who’ve done the reps are the ones who can see the details everyone else misses.

Earlier this week I linked to Gale Robins’ argument that AI makes execution cheap but doesn’t help you decide what to build. Christina Wodtke is making the same case from the research side.

Christina Wodtke opens with a designer who spent two weeks vibe-coding a gratitude journaling app. Beautiful interface, confetti animations, gentle notifications. Then she showed it to users. “I don’t really journal,” said the first one. “Gratitude journaling felt performative,” said the second. Two weeks building the wrong thing. Wodtke’s diagnosis:

That satisfaction is a trap. You’re accumulating artifacts that may have nothing to do with what anyone needs.

Wodtke draws a line between need-finding and validation that I think a lot of teams blur. Skipping the first and jumping to the second means you’re testing your guess, not understanding the problem:

Need-finding happens before you have a solution. You’re listening to people describe their lives, their frustrations, their workarounds. You’re hunting for problems that actually exist—problems people care enough about that they’re already trying to solve them with spreadsheets and sticky notes and whatever else they’ve cobbled together.

Wodtke’s version of fast looks different from what you’d expect:

The actual fast path is unsexy: sit down with five to ten people. Ask them about their lives. Shut up and listen. Use those three magic words—“tell me more”—every time something interesting surfaces. Don’t show them anything. Don’t pitch. Just listen.

“You’ll build less. It’ll be the right thing.” When building is cheap, the bottleneck moves upstream to judgment, knowing what to build. That judgment comes from listening, not prompting.

Every team I’ve ever led has had one of these people. The person who writes the doc that gives the project its shape, who closes context gaps in one-on-ones before they turn into conflicts, who somehow keeps six workstreams from drifting apart. They rarely get the credit they deserve because the work, when it’s done well, looks like it just happened on its own.

Hardik Pandya writes about this on his blog. He shares a quote from a founder friend describing his most valuable employee:

“She’s the reason things actually work around here. She just… makes sure everything happens. She writes the docs. She runs the meetings that matter. She talks to people. Somehow everything she touches stays on track. I don’t know how I’d even describe what she does to a person outside the company. But if she left, we’d fall apart in a month. Maybe less.”

I’ve known people like this at every company I’ve worked at. And I’ve watched them get passed over because the performance system couldn’t see them. Pandya nails why:

When a project succeeds, credit flows to the people whose contributions are easy to describe. The person who presented to the board. The person whose name is on the launch email. The person who shipped the final feature. These contributions are real, I’m not diminishing them. But they’re not more real than the work that made them possible. They’re just easier to point at.

Most organizations try to fix this by telling the invisible workers to “be more visible”—present more, build your personal brand internally. Pandya’s advice goes the other direction, and I think he’s right:

If you’re good at the invisible work, the first move isn’t to get better at visibility. It’s to find the leader who doesn’t need you to be visible.

As a leader, I take this as a challenge. If someone on my team is doing the work that holds everything together, it’s my job to make sure the organization sees it too—especially when it doesn’t announce itself.

When I managed over 40 creatives at a digital agency, the hardest part wasn’t the work itself—it was resource allocation. Who’s got bandwidth? Who’s blocked waiting on feedback? Who’s deep in something and shouldn’t be interrupted? You learn to think of your team not as individuals you assign tasks to, but as capacity you orchestrate.

I was reminded of that when I read about Boris Cherny’s approach to Claude Code. Cherny is a Staff Engineer at Anthropic who helped build Claude Code. Karo Zieminski, writing in her Product with Attitude Substack, breaks down how Cherny actually uses his own tool:

He keeps ~10–15 concurrent Claude Code sessions alive: 5 in terminal (tabbed, numbered, with OS notifications). 5–10 in the browser. Plus mobile sessions he starts in the morning and checks in on later. He hands off sessions between environments and sometimes teleports them back and forth.

Zieminski’s analysis is sharp:

Boris doesn’t see AI as a tool you use, but as a capacity you schedule. He’s distributing cognition like compute: allocate it, queue it, keep it hot, switch contexts only when value is ready. The bottleneck isn’t generation; it’s attention allocation.

Most people treat AI assistants like a single very smart coworker. You give it a task, wait for the answer, evaluate, iterate. Cherny treats Claude like a team—multiple parallel workers, each holding different context, each making progress while he’s focused elsewhere.

Zieminski again:

Each session is a separate worker with its own context, not a single assistant that must hold everything. The “fleet” approach is basically: don’t make one brain do all jobs; run many partial brains.

I’ve been using Claude Code for months, but mostly one session at a time. Reading this, I realize I’ve been thinking too small. The parallel session model is about working efficiently. Start a research task in one session, let it run while you code in another, check back when it’s ready.

Looks like the new skill on the block is orchestration.

If design’s value isn’t execution—and AI is making that argument harder to resist—then what is it? Dan Ramsden offers a framework I find useful.

He breaks thinking into three types: deduction (drawing conclusions from data), induction (building predictions from patterns), and abduction—generating something new. Design’s unique contribution is abductive thinking:

When we use deduction, we discover users dropping off during a registration flow. Induction might tell us why. Abduction would help us imagine new flows to fix it.

Product managers excel at sense-making (aka “Why?”). Engineers build the thing. Design makes the difference—moving from “what is” to “what could be.”

On AI and the temptation to retreat to “creativity” or “taste” as design’s moat, Ramsden is skeptical:

Some might argue that it comes down to “taste”. I don’t think that’s quite right — taste without a rationale is just an opinion. I think designers are describers.

I appreciate that distinction. Taste without rationale is just preference. Design’s value is translating ideas through increasing levels of fidelity—from sketch to prototype to tested solution—validating along the way.

His definition of design in a product context:

Design is a set of structured processes to translate intent into experiments.

That’s a working definition I can use. It positions design not as the source of ideas (those can come from anywhere, including AI), but as the discipline that manages ideas through validation. The value isn’t in generating the concept—it’s in making it real while managing risk.

I’ve spent a lot of my product design career pushing for metrics—proving ROI, showing impact, making the case for design in business terms. But I’ve also seen how metrics become the goal rather than a signal pointing toward the goal. When the number goes up, we celebrate. When it doesn’t, we tweak the collection process. Meanwhile, the user becomes secondary. Last week’s big idea was around metrics, this piece piles on.

Pavel Samsonov calls this out:

Managers can only justify their place in value chains by inventing metrics for those they manage to make it look like they are managing.

I’ve sat in meetings where we debated which numbers to report to leadership—not which work to prioritize for users. The metrics become theater. So-called “vanity metrics” that always go up and to the right.

But here’s where Pavel goes somewhere unexpected. He doesn’t let designers off the hook either:

Defining success by a metric of beauty offers a useful kind of vagueness, one that NDS seems to hide behind despite the slow loading times or unnavigability that seem to define their output; you can argue with slow loading times or difficulty finding a form, but you cannot meaningfully argue with “beautiful.”

“Taste” and “beauty” are just another avoidance strategy. That’s a direct challenge to the design discourse that’s been dominant lately—the return to craft, the elevation of aesthetic judgment. Pavel’s saying it’s the same disease, different symptom. Both metrics obsession and taste obsession are ways to avoid the ambiguity of actually defining user success.

So what’s the alternative? Pavel again:

Fundamentally, the work of design is intentionally improving conditions under uncertainty. The process necessarily involves a lot of arguments over the definition and parameters of “improvement”, but the primary barrier to better is definitely not how long it takes to make artifacts.

The work is the argument. The work is facing the ambiguity rather than hiding behind numbers or aesthetics. Neither Figma velocity nor visual polish is a substitute for the uncomfortable conversation about what “better” actually means for the people using your product.

It’s January and by now millions of us have made resolutions and probably broken them already. The second Friday of January is known as “Quitter’s Day.”

OKRs—objectives and key results—are a method for businesses to set and align company goals. The objective is your goal and the KRs are the ways to reach your goals. Venture capitalist John Doerr learned about OKRs while working at Intel, brought it to Google, and later became the framework’s leading evangelist.

Christina Wodtke talks about how to use OKRs for your personal life, and maybe as a way to come up with better New Year’s resolutions. She looked at her past three years of personal OKRs:

Looking at the pattern laid out in front of me, I finally saw what I’d been missing. My problem wasn’t work-life balance. My problem was that I didn’t like the kind of work I was doing.

The key results kept failing because the objective was wrong. It wasn’t about balance. It was about joy.

This is the second thing key results do for you: when they consistently fail, they’re telling you something. Not that you lack discipline—that you might be chasing the wrong goal entirely.

And I love Wodtke’s line here: “New Year’s resolutions fail because they’re wishes, not plans.“ She continues:

They fail because “eat better” and “be healthier” and “find balance” are too vague to act on and too fuzzy to measure.

Key results fix this. Not because measurement is magic, but because the act of measuring forces clarity. It makes you confront what you actually want. And sometimes, when the data piles up, it reveals that what you wanted wasn’t the thing you needed at all.

Building on our earlier link about measuring the impact of features, how can we keep track of the overall health of the product? That’s where a North Star Metric comes in.

Julia Sholtz writes and introduction to North Star Metrics in the analytics provider Amplitude’s blog:

Your North Star Metric should be the key measure of success for your company’s product team. It defines the relationship between the customer problems your product team is trying to solve and the revenue you aim to generate by doing so.

How is it done? The first step is to figure out the “game” your business is playing: how your business engages with customers:

1. The Attention Game: How much time are your customers willing to spend in your product?
2. The Transaction Game: How many transactions does your user make on your platform?
3. The Productivity Game: How efficiently and effectively can someone get their work done in your product?

They have a whole resource section on this topic that’s worth exploring.

How do we know what we designed is working as intended? We measure. Vitaly Friedman shares something called the TARS framework to measure the impact of features.

We need UX metrics to understand and improve user experience. What I love most about TARS is that it’s a neat way to connect customers’ usage and customers’ experience with relevant product metrics.

Here’s TARS in a nutshell:

• Target Audience (%): Measures the percentage of all product users who have the specific problem that a feature aims to solve.
• Adoption (%): Tracks the percentage of the target audience that successfully and meaningfully engages with the feature.
• Retention (%): Assesses how many users who adopted the feature continue to use it repeatedly over time.
• Satisfaction Score (CES): Gauges the level of satisfaction, specifically how easy it was for retained users to solve their problem after using the feature.

Friedman has more details in the article, including how to use TARS to measure how well a feature is performing for your intended target audience.

Here is a good reminder from B. Prendergast to “stop asking users what they want—and start watching what they do.”

Asking people what they want is one of the most natural instincts in product work. Surveys, interviews, and feature wish lists feel accessible, social, and collaborative. They open channels to understand and empathise with the user base. They help teams feel closer to the people they serve. For teams under pressure, a stack of opinions can feel like solid data.

But this breaks when we compare what users say to what they actually do (say-do gap).

We all want to present ourselves a certain way. We want to seem more competent than confused (social desirability bias). Our memories can be fuzzy, especially about routine tasks (recall bias). Standards for what feels “easy” or “intuitive” can vary wildly between people (reference bias).

And of course, as soon as we start to ask users to imagine what they’d want, they’ll solve based on their personal experiences—which might be the right solution for them, but might not be for other users in the same situation.

Prendergast goes on to suggest “watch what people do, measure what matters, and use what they say to add context.” This approach involves watching user interactions, analyzing real behaviors through analytics, and treating feature requests as signals of underlying problems to uncover genuine needs. Prioritizing decisions based on observed patterns and desired outcomes leads to more effective solutions than relying on user opinions alone.

Echoing my series on the design talent crisis and other articles warning against the practice of cutting back on junior talent, Vaughn Tan offers yet another dimension: subjective decision-making skills are only honed through practice. But the opportunities given to junior staff for this type of decision-making are slim.

But to back up, here’s Tan explaining what subjective decision-making is:

These are decisions where there’s no one “correct” answer and the answers that work can’t be known in advance. Subjective decisionmaking requires critical thinking skills to make strongly reasoned arguments, identify appropriate evidence, understand the tradeoffs of different arguments, make decisions that may (or may not) be correct, and develop compelling narratives for those decisions.

While his article isn’t about AI nor is it about companies not hiring juniors, it is about companies not developing juniors and allowing them to practice this type of decision-making in low-stakes situations.

Critical thinking and judgment require practice. Practice needs to be frequent, and needs to begin at a low level with very few consequences that are important. This small-scale training in subjective decisionmaking and critical thinking is the best way to learn how to do it properly in more consequential situations.

If you wait until someone is senior to teach judgment, their first practice attempts have serious consequences. High-stakes decisionmaking pressure cannot be simulated realistically; learning how to deal with it requires actual practice with real consequences that progressively increases in scope and consequentiality.

And why is this all important? Not developing junior staff means there will be a bottleneck issue—only seniors can make these judgement calls—and one day, there will be a succession problem, i.e., who takes over when the seniors leave or retire.

This short article could easily fall under the motivational category, but I couldn’t help but draw parallels to what we do as designers when working as part of a product team.

Hazel Weakly says that people who see systems also tend to become in charge of them, sooner or later. And to be a leader is to “understand that you’ll find yourself stranded in the middle of the ocean one day.”

Not just you, but everyone you lead. And you’ll need to chart a course. In the ever-changing winds, the ever-shifting tides, the unknown weather, and with an inability to see up or down or basically anywhere except a few minutes away. You won’t have the time to find your bearings even if you could. Yet, somehow, in this sea of swirling and infinite complexities and probabilities, in the midst of incalculable odds, you will find yourself needing to have simultaneously several different things…

The first thing is that you will fail. I equate this to knowing that design is about trial and error, testing and measuring, and then adjusting.

The second thing is unshakable conviction that “you will succeed.” I see success as solving the problem, coming up with a solution that helps users do what they need. And you know what? Designers will succeed when they follow the design process.

Finally, the third thing is to “prepare and make ready everyone around you.” Which means influencing your product and engineering counterparts and other stakeholders that the solution your advocating for is the right one.

I spend a lot of time not talking about design nor hanging out with other designers. I suppose I do a lot of reading about design to write this blog, and I am talking with the designers on my team, but I see Design as the output of a lot of input that comes from the rest of life.

Hardik Pandya agrees and puts it much more elegantly:

Design is synthesizing the world of your users into your solutions. Solutions need to work within the user’s context. But most designers rarely take time to expose themselves to the realities of that context.

You are creative when you see things others don’t. Not necessarily new visuals, but new correlations. Connections between concepts. Problems that aren’t obvious until someone points them out. And you can’t see what you’re not exposed to.

Improving as a designer is really about increasing your exposure. Getting different experiences and widening your input of information from different sources. That exposure can take many forms. Conversations with fellow builders like PMs, engineers, customer support, sales. Or doing your own digging through research reports, industry blogs, GPTs, checking out other products, YouTube.

Scott Berkun enumerates five habits of the worst designers in a Substack post. The most obvious is “pretentious attitude.” It’s the stereotype, right? But in my opinion, the most damaging and potentially fatal habit is a designer’s “lack of curiosity.” Berkun explains:

Design dogma is dangerous and if the only books and resources you read are made by and for designers, you will tend to repeat the same career mistakes past designers have made. We are a historically frustrated bunch of people but have largely blamed everyone else for this for decades. The worst designers are ignorant, and refuse to ask new questions about their profession. They repeat the same flawed complaints and excuses, fueling their own burnout and depression. They resist admitting to their own blindspots and refuse to change and grow.

I’ve worked with designers who have exhibited one or more of these habits at one time or another. Heck, I probably have as well.

Good reminders all around.

Critiques are the lifeblood of design. Anyone who went to design school has participated in and has been the focus of a crit. It’s “the intentional application of adversarial thought to something that isn’t finished yet,” as Fabricio Teixeira and Caio Braga, the editors of DOC put it.

A lot of solo designers—whether they’re a design team of one or if they’re a freelancer—don’t have the luxury of critiques. In my view, they’re handicapped. There are workarounds, of course. Such as critiques with cross-functional peers, but it’s not the same. I had one designer on my team—who used to be a design team of one in her previous company—come up to me and say she’s learned more in a month than a year at her former job.

Further down, Teixeira and Braga say:

In the age of AI, the human critique session becomes even more important. LLMs can generate ideas in 5 seconds, but stress-testing them with contextual knowledge, taste, and vision, is something that you should be better at. As AI accelerates the production of “technically correct” and “aesthetically optimized” work, relying on just AI creates the risks of mediocrity. AI is trained to be predictable; crits are all about friction: political, organizational, or strategic.

He told me his CEO - who’s never written a line of code - was running their company from an AI code editor.

I almost fell out of my chair.

OF COURSE. WHY HAD I NOT THOUGHT OF THAT.

I’ve since gotten rid of almost all of my productivity tools.

ChatGPT, Notion, Todoist, Airtable, Google Keep, Perplexity, my CRM. All gone.

That’s the lede for a piece by Derek Larson on running everything from Claude Code. I’ve covered how Claude Code is pretty brilliant and there are dozens more use cases than just coding.

But getting rid of everything and using just text files and the terminal window? Seems extreme.

Larson uses a skill in Claude Code called “/weekly” to do a weekly review.

1. Claude looks at every file change since last week
2. Claude evaluates the state of projects, tasks, and the roadmap
3. We have a conversation to dig deeper, and make decisions
4. Claude generates a document summarizing the week and plan we agreed on

Then Claude finds items he’s missed or procrastinating on, and “creates a space to dump everything” on his mind.

Design Thinking has gotten a bad rap in recent years. It was supposed to change everything in the corporate world but ended up changing very little. While Design Thinking may not be the darling anymore, designers still need time to think, which is, for the sake of argument, time away from Figma and pushing pixels.

Chris Becker argues in UX Collective:

However, the canary in the coalmine is that Designers are not being used for their “thinking” but rather their “repetition”. Much of the consternation we feel in the UX industry is catapulted on us from this point of friction.

He says that agile software development and time for designers to think aren’t incompatible:

But allowing Designers to implement their thinking into the process is about trust. When good software teams collaborate effectively, there are high levels of trust and autonomy (a key requirement of agile teams). Designers must earn that trust, of course, and when we demonstrate that we have “done the thinking,” it builds confidence and garners more thinking time. Thinking begets thinking. So, Designers, let’s continue to work to maximise our “thinking” faculties.