I think the headline is a hard stance, but I appreciate the sentiment. All the best designers and creatives—including developers—I’ve ever worked with do things on the side. Or in Rohit Prakash’s words, they tinker. They’re always making something, learning along the way.

Prakash, writing in his blog:

Acquiring good taste comes through using various things, discarding the ones you don’t like and keeping the ones you do. if you never try various things, you will not acquire good taste.

It’s important for designers to see other designs and use other products—if you’re a software designer. It’s equally important to look up from Dribbble, Behance, Instagram, and even this blog and go experience something unrelated to design. Art, concerts, cooking. All of it gets synthesized through your POV and becomes your taste.

Ethan Mollick, a professor of entrepreneurship at the Wharton School says that AI has gotten so good that our relationship with them is changing. “We’re moving from partners to audience, from collaboration to conjuring,” he says.

He fed NotebookLM his book and 140 Substack posts and asked for a video overview. AI famously hallucinates. But Mollick found no factual errors in the six-minute video.

We’re shifting from being collaborators who shape the process to being supplicants who receive the output. It is a transition from working with a co-intelligence to working with a wizard. Magic gets done, but we don’t always know what to do with the results. This pattern — impressive output, opaque process — becomes even more pronounced with research tasks.

Mollick believes that the most wizard-like model today is GPT-5 Pro. He uploaded an academic paper that took him a year to write, which was peer-reviewed, and was then published in a major journal…

Nine minutes and forty seconds later, I had a very detailed critique. This wasn’t just editorial criticism, GPT-5 Pro apparently ran its own experiments using code to verify my results, including doing Monte Carlo analysis and re-interpreting the fixed effects in my statistical models. It had many suggestions as a result (though it fortunately concluded that “the headline claim [of my paper] survives scrutiny”), but one stood out. It found a small error, previously unnoticed. The error involved two different sets of numbers in two tables that were linked in ways I did not explicitly spell out in my paper. The AI found the minor error, no one ever had before.

Later in his post, Mollick says that there’s a problem with this wizardry—it’s too opaque. So what can we do?

First, learn when to summon the wizard versus when to work with AI as a co-intelligence or to not use AI at all. AI is far from perfect, and in areas where it still falls short, humans often succeed. But for the increasing number of tasks where AI is useful, co-intelligence, and the back-and-forth it requires, is often superior to a machine alone. Yet, there are, increasingly, times when summoning a wizard is best, and just trusting what it conjures.

Second, we need to become connoisseurs of output rather than process. We need to curate and select among the outputs the AI provides, but more than that, we need to work with AI enough to develop instincts for when it succeeds and when it fails.

And lastly, trust it. Trust the technology, he suggests. “The question isn’t ‘Is this completely correct?’ but ‘Is this useful enough for this purpose?’”

I think we’re in that transition period. AI is indeed dastardly great at some things and constantly getting better at the tasks it’s not. But we all know where this is headed.

Remote work really exploded when the Covid-19 pandemic hit. Everyone had to adjust to working from home, relying on Zoom and Slack and other collaborative tools much more. But beyond tooling, there’s also process. Matt Mullenweg, CEO of Automattic, has famously been a proponent of distributed work for a while.

Paolo Belcastro peels back the curtain to share how the 1,500 or so global employees of Automattic stay connected via two core principles:

There are two ideas that define our communication culture:

Radical Transparency: we default to openness, with every conversation accessible to everyone in the company. Asynchronous by Design: we don’t expect everyone to be “on” at the same time.

Everything is written down:

Our internal platform, P2, started life as a WordPress theme (it was called Prologue, later updated to version 2 and eventually shortened to P2) that lets people post directly on the front end of a site—fast, simple, and visible to everyone. Over time it evolved into a network of thousands of P2s for teams, projects, and watercooler chats (couch surfing, classified ads, house renovations, babies, pets, music, or games, we kind of have it all).

…

Every post, every comment, every decision ever made in the history of Automattic is preserved there.

As you can imagine, it soon becomes a volume problem. There’s too much stuff.

No one can read everything.

That’s why onboarding is designed to help people adapt:

• Each newcomer is paired with a mentor from a different team, to give them a cross-company perspective.
• They receive a curated list of “milestone posts” that map the history of Automattic, along with role-specific threads relevant to their work.
• The Field Guide offers principles, templates, and advice about how to handle communication.

Somehow, they make it work.

Building on Matthew Ström-Awn’s argument that true quality emerges from decentralized, ground-level ownership, Sean Goedecke writes an essay exploring how software companies navigate the tension between formalized control and the informal, often invisible work that actually drives product excellence.

But first, what does legibility even mean?

What does legibility mean to a tech company, in practice? It means:

• The head of a department knows, to the engineer, all the projects the department is currently working on
• That head also knows (or can request) a comprehensive list of all the projects the department has shipped in the last quarter
• That head has the ability to plan work at least one quarter ahead (ideally longer)
• That head can, in an emergency, direct the entire resources of the department at immediate work

Note that “shipping high quality software” or “making customers happy” or even “making money” is not on this list. Those are all things tech companies want to do, but they’re not legibility.

Goedecke argues that while leaders prize formal processes and legibility to facilitate predictability and coordination, these systems often overlook the messier, less measurable activities that drive true product quality and user satisfaction.

All organizations - tech companies, social clubs, governments - have both a legible and an illegible side. The legible side is important, past a certain size. It lets the organization do things that would otherwise be impossible: long-term planning, coordination with other very large organizations, and so on. But the illegible side is just as important. It allows for high-efficiency work, offers a release valve for processes that don’t fit the current circumstances, and fills the natural human desire for gossip and soft consensus.

Matt Ström-Awn makes the argument that companies can achieve sustainable excellence by empowering everyone at each level to take ownership of quality, rather than relying solely on top-down mandates or standardized procedures.

But more and more I’ve come to believe that quality isn’t a slogan, a program, or a scorecard. It’s a promise kept at the edge by the people doing the work. And, ideally, quality is fundamental to the product itself, where users can judge it without our permission. That’s the shift we need: away from heroics at the center, toward systems that make quality inevitable.

The stakes are high. Centralized quality — slogans, KPIs, executive decrees — can produce positive results, but it’s brittle. Decentralized quality — continuous feedback, distributed ownership, emergent standards — builds resilience. In this essay, I’d like to make the case that the future belongs to those who can decentralize their mindset and approach to quality.

Ström-Awn offers multiple case studies, contrasting centralized systems with decentralized ones, using Ford, Amazon, Apple, Toyota, Netflix, 3M, Morning Star, W.L. Gore, Valve, Barnes & Noble, and Microsoft under Satya Nadella as examples.

These stories share a common thread: organizations that trusted their frontline workers to identify and solve quality problems. But decentralized quality has its own vulnerabilities. Valve’s radical structure has been criticized for creating informal power hierarchies and making it difficult to coordinate large projects. Some ex-employees describe a “high school clique” atmosphere where popular workers accumulate influence while others struggle. Without traditional management oversight, initiatives can moulder, or veer in directions that don’t serve broader company goals.

Still, these examples show a different path for achieving quality, where excellence is defined in the course of building a product. Unlike centralized approaches relying on visionary (but fallible) leaders, decentralized systems are resilient to individual failures, adaptable to change, and empowering to builders. The andon cord, the rolling desk, and the local bookstore manager each represent a small bet on human judgment over institutional control. Those bets look like they’re paying off.

As UX designers, we try to anticipate the edge cases—what might a user do and how can we ensure they don’t hit any blockers. But beyond the confines of the products we build, we must also remember to anticipate the unintended consequences. How might this product or feature affect the user emotionally? Are we creating bad habits? Are we fomenting rage in pursuit of engagement?

Martin Tomitsch and Steve Baty write in DOC, suggesting some frameworks to anticipate the unpredictable:

Chaos theory describes the observation that even tiny perturbations like the flutter of a butterfly can lead to dramatic, non-linear effects elsewhere over time. Seemingly small changes or decisions that we make as designers can have significant and often unforeseen consequences.

As designers, we can’t directly control the chain of reactions that will follow an action. Reactions are difficult to predict, as they occur depending on factors beyond our direct control.

But by using tools like systems maps, the impact ripple canvas, and iceberg visuals, we can take potential reactions out of the unpredictable pile and shift them into the foreseeable pile.

Sticking with the workslop or outsourcing our main work to AI, Douglas Rushkoff writes in Fast Company:

By using the AI to do the big stuff—by outsourcing our primary competencies to the machines instead of giving them the boring busywork—we deskill ourselves and deprive everyone of the opportunity for AI-enhanced outputs. Too many of us are using AI as the primary architect for a project, rather than the general contractor who supports the architect’s human vision.

People forget that it’s the process of doing something that helps us synthesize and form the connections necessary for innovation.

As the researcher behind MIT’s study “This is Your Brain on ChatGPT” explained at a recent ANDUS event, when people turn to an AI for a solution before working on a problem themselves, the number of connections formed in their brains decreases. But when they turn to the AI after working on the problem for a while, they end up with more neural connections than if they worked entirely alone.

That’s because the value of the AI is not its ability to create product for us, but to engage with us in our process. Working and iterating with an AI—doing what we could call generative thinking—is actually a break from Industrial Age thinking. We focus less on outputs than on cycles. Less on the volume of short-term results (assembly line), and more on the quality and complexity of thought and innovation.

Speaking of workslop, here’s an article from NN/g on how to avoid falling into over-reliance on AI in our design field. They call it the “7 Deadly AI Sins for UX Professionals.”

1. Outsourced Thinking
2. Wasted Time
3. Lost Details
4. Isolated Ideation
5. Naïve Trust
6. Bland Taste
7. Defensive Outlook

As Tanner Kohler writes:

It’s not about avoiding AI. It’s about maintaining your own growth and the quality of your work as you use AI. AI will constantly be changing. Never let yourself slip into repeatedly committing the sins that weaken you and your UX skills.

A former colleague of mine, designer Evan Sornstein wrote a wonderful piece on LinkedIn applying Buddhist principles to design.

Buddhism begins with the recognition that life is marked by impermanence, suffering, and non-self. These aren’t abstract doctrines — they are observations about how the world actually works. Over centuries, these ideas contributed to Japanese aesthetics: wabi-sabi (imperfection), ma (meaningful emptiness), yo no bi (beauty in usefulness), the humility of the shokunin, and the care of omotenashi. What emerges is not a set of rules, but an extraordinary perspective: beauty is inseparable from impermanence; usefulness is inseparable from dignity; care is inseparable from design. In an age when our digital products too often prioritize stickiness and metrics over humanity, these ideas offer a different path. They remind us that design is not about control or cleverness — it’s about connection, trust, and care.

The following eight principles aren’t new “methods” or “laws,” but reflections of this lineage, reframed for product design — though they apply to nearly any creative practice. They are invitations to design with the same attention, humility, and compassion that Buddhism and Japanese aesthetics have carried for centuries.

There’s a famous quote that Henry Ford allegedly said:

If I had asked people what they wanted, they would have said faster horses.

Anton Sten argues that a lot of people use this quote to justify not doing any user (or market) research:

This quote gets thrown around constantly—usually by someone who wants to justify ignoring user research entirely. The logic goes: users don’t know what they want, so why bother asking them?

I think he’s right. The question to ask users isn’t “What should we build?” but “What are your biggest pain points?”

Good research uncovers problems. It reveals pain points. It helps you understand what people are actually struggling with in their daily lives. What they’re working around. What they’ve given up on entirely.

Users aren’t supposed to design your product. That’s your job. But they’re the only ones who can tell you what’s actually broken in their world.

When you focus on understanding problems instead of collecting feature requests, you stop getting “faster horses” and start hearing real needs.

It’s always interesting to hear how others think about the design process from the outside. Eli Woolery and Aaron Walter interview creativity researcher and author Keith Sawyer to learn about what he’s found to be true after interviewing hundreds of art and design professors and students over a decade for his new book:

The creativity doesn’t come at the beginning. You don’t start by having a brilliant insight. You just dive into the process. And then as you’re engaging in the process, the ideas emerge.

Sawyer emphasizes that art and design schools are not just teaching students how to create, but how to “see.” He found that many professors believe students already possess creativity, but the role of art and design school is to help them realize and develop that potential by teaching them to observe, critique, and reflect more deeply on their own work.

When I interviewed these artists and designers, I would say, how are you teaching students how to create? And everyone was quite uncomfortable with that question. A lot of them would say, we’re not teaching students how to create. Or they’ll say something like, the students are already creative. We’re teaching them how to realize the potential they have as creatives.

Sawyer notes that the hardest thing for students to learn is how to see their own work—that is, to understand what they have actually made rather than sticking rigidly to their original idea.

When we talk about learning to see, you’re talking about learning to see yourself. The hardest thing to teach a student is how to see their own work, to see something that they’ve just generated. Because these studio classes, students have opportunities to share their work in interim stages along the way. You don’t go off and work for two weeks or four weeks and then bring back in the finished product. You bring in your interim and you get a lot of feedback and comments on it.

And what the professors tell me is these 18, 19, and 20-year-olds, they don’t realize what they put on the canvas. Or if they’re a graphic designer, they don’t realize what it is that they’ve generated. A lot of times, they’ll think they’ve done a certain thing. So they have this kind of linear approach—model of the creative process where I’m going to have an idea and I’m going to execute it so they’ll start with their idea and they’ll execute it. They’ll think that what they put on the canvas is their original idea, but in a lot of cases, it’s not. They can’t see what they’ve done themselves, so that’s kind of powerful how do you teach someone that what you put on the canvas isn’t what you say you’re doing.

You can’t just tell them, “Hey, you’re wrong. Let me tell you what you’ve done.” You have to lead someone through that. You have to walk them through it.

One way you do it is you put students in the classroom together and then have them comment on other students’ work so they will be on the other side. And they’ll see another student. talking about what they’ve done and not really describing what’s really on the canvas.

So I think that’s the hardest thing about learning to see is learning to see yourself, learning to see your own work.

I think that’s the power of art and design school, this studio learning environment. I’m biased, of course, because that’s how I learned. Those who are self-taught or have gone through bootcamps miss out on a lot of this experience. The other thing the design school environment teaches is how to give and take critiques. It’s about the work, not you.

When I read this, I thought to myself, “Geez, this is what a designer does.” I think there is a lot of overlap between what we do as product designers and what product managers do. One critical one—in my opinion, and why we’re calling ourselves product designers—is product sense. Product sense is the skill of finding real user needs and creating solutions that have impact.

So I think people can read this with two lenses:

• If you’re a designer who executes the assignments you’re given, jumping into Figma right away, read this to be more well-rounded and understand the why of what you’re making.
• If you’re a designer who spends 80% of your time questioning everything and defining the problem, and only 20% of your time in Figma, read this to see how much overlap you actually have with a PM.

BTW, if you’re in the first bucket, I highly encourage you to gain the skills necessary to migrate to the second bucket.

While designers often stay on top of visual design trends or the latest best practices from NNG, Jules Walter suggests an even wider aperture. Writing in Lenny’s Newsletter:

Another practice for developing creativity is to spend time learning about emerging trends in technology, society, and regulations. Changes in the industry create opportunities for launching new products that can address user needs in new ways. As a PM, you want to understand what’s possible in your domain in order to come up with creative solutions.

This post from Carly Ayres breaks down a beef between Michael Roberson (developer of an AI-enabled moodboard tool) and Elizabeth Goodspeed (writer and designer, oft-linked on this blog) and explores ragebait, putting in the reps as a junior, and designers as influencers.

Tweet from Michael Roberson

The tweet earned 30,000 views, but only about 20 likes. “That ratio was pretty jarring,” [Roberson] said. Still, the strategy felt legible. “When I post things like, ‘if you don’t do X, you’re not going to make it,’ obviously, I don’t think that. These tools aren’t really capable of replacing designers just yet. It’s really easy to get views baiting and fear-mongering.”

Much like the provocative Artisan campaign, I think this is a net negative for the brand. Pretty sure I won’t be trying out Moodboard AI anytime soon, ngl.

But stepping back from the internet beef, Ayres argues that it’s a philosophical difference about the role friction in the creative process.

Michael’s experience mirrors that of many young designers: brand audits felt like busywork during his Landor internship. “That process was super boring,” he told me. “I wasn’t learning much by copy-pasting things into a deck.” His tool promises to cut through that inefficiency, letting teams reach visual consensus faster and spend more time on execution.

Young Michael, the process is the point! Without doing this boring stuff, by automating it with AI, how are you going to learn? This is but one facet of the whole discussion around expertise, wisdom, and the design talent crisis.

Goodspeed agrees with me:

Elizabeth sees it differently. “What’s interesting to me,” Elizabeth noted, “is how many people are now entering this space without a personal understanding of how the process of designing something actually works.” For her, that grunt work was formative. “The friction is the process,” she explained. “That’s how you form your point of view. You can’t just slap seven images on a board. You’re forced to think: What’s relevant? How do I organize this and communicate it clearly?”

Ultimately, the saddest point that Ayres makes—and noted by my friend Eric Heiman—is this:

When you’re young, online, and trying to get a project off the ground, caring about distribution is the difference between a hobby and a company. But there’s a cost. The more you perform expertise, the less you develop it. The more you optimize for engagement, the more you risk flattening what gave the work meaning in the first place. In a world where being known matters more than knowing, the incentives point toward performance over practice. And we all become performers in someone else’s growth strategy.

…Because when distribution matters more than craft, you don’t become a designer by designing. You become a designer by being known as one. That’s the game now.

In a fascinating thread about designing a typeface in Illustrator versus a font editor, renowned typographer Jonathan Hoefler lets us peek behind the curtains.

But moreover, the reason not to design typefaces in a drawing program is that there, you’re drawing letters in isolation, without regard to their neighbors. Here’s the lowercase G from first corner of the HTF Didot family, its 96pt Light Roman master, which I drew toward the end of 1991. (Be gentle; I was 21.) I remember being delighted by the results, no doubt focussing on that delicate ear, etc. But really, this is only half the picture, because it’s impossible to know if this letter works, unless you give it context. Here it is between lowercase Ns, which establish a typographic ‘control’ for an alphabet’s weight, width, proportions, contrast, fit, and rhythm. Is this still a good G? Should the upper bowl maybe move left a little? How do we feel about its weight, compared to its neighbors? Is the ear too dainty?

Ben Davies-Romano argues that the AI chat box is our new design interface:

Every interaction with a large language model starts the same way: a blinking cursor in a blank text field. That unassuming box is more than an input — it’s the interface between our human intent and the model’s vast, probabilistic brain.

This is where the translation happens. We pour in the nuance, constraints, and context of our ideas; the model converts them into an output. Whether it’s generating words, an image, a video sequence, or an interactive prototype, every request passes through this narrow bridge.

It’s the highest-stakes, lowest-fidelity design surface I’ve ever worked with: a single field that stands between human creativity and an engine capable of reshaping it into almost any form, albeit with all the necessary guidance and expertise applied.

In other words, don’t just say “Make it better,” but guide the AI instead.

That’s why a vague, lazy prompt, like “make it better”, is the design equivalent of telling a junior designer “make it intuitive” and walking away. You’ll get something generic, safe, and soulless, not because the AI “missed the brief,” but because there was no brief.

Without clear stakes, a defined brand voice, and rich context, the system will fill in the blanks with its default, most average response. And “average” is rarely what design is aiming for.

And he makes a point that designers should be leading the charge on showing others what generative AI can do:

In the age of AI, it shouldn’t be everyone designing, per say. It should be designers using AI as an extension of our craft. Bringing our empathy, our user focus, our discipline of iteration, and our instinct for when to stop generating and start refining. AI is not a replacement for that process; it’s a multiplier when guided by skilled hands.

So, let’s lead. Let’s show that the real power of AI isn’t in what it can generate, but in how we guide it — making it safer, sharper, and more human. Let’s replace the fear and the gimmicks with clarity, empathy, and intentionality.

The blank prompt is our new canvas. And friends, we need to be all over it.

My former colleague from Organic, Christian Haas—now ECD at YouTube—has been experimenting with AI video generation recently. He’s made a trilogy of short films called AI Jobs.

You can watch part one above 👆, but don’t sleep on parts two and three.

Haas put together a “behind the scenes” article explaining his process. It’s fascinating and I’ll want to play with video generation myself at some point.

I started with a rough script, but that was just the beginning of a conversation. As I started generating images, I was casting my characters and scouting locations in real time. What the model produced would inspire new ideas, and I would rewrite the script on the fly. This iterative loop continued through every stage. Decisions weren’t locked in; they were fluid. A discovery made during the edit could send me right back to “production” to scout a new location, cast a new character and generate a new shot. This flexibility is one of the most powerful aspects of creating with Gen AI.

It’s a wonderful observation Haas has made—the workflow enabled by gen AI allows for more creative freedom. In any creative endeavor where the production of the final thing is really involved and utilizes a significant amount of labor and materials, be it a film, commercial photography, or software, planning is a huge part. We work hard to spec out everything before a crew of a hundred shows up on set or a team of highly-paid engineers start coding. With gen AI, as shown here with Google’s Veo 3, you have more room for exploration and expression.

UPDATE: I came across this post from Rory Flynn after I published this. He uses diagrams to direct Veo 3.

Coincidentally, I was considering adding a service designer to my headcount plan when this article came across my feeds. Perfect timing. It’s hard to imagine that service design as a discipline is so young—only since 2012 according to the author.

Joe Foley, writing in Creative Bloq:

As a discipline, service design is still relatively new. A course at the Royal College of Art in London (RCA) only began in 2012 and many people haven’t even heard of the term. But that’s starting to change.

He interviews designer Clive Grinyer, whose new book on service design has just come out. He was co-founder of the design consultancy Tangerine, Director of Design and Innovation for the UK Design Council, and Head of Service Design at the Royal College of Art.

Griner:

Great service design is often invisible as it solves problems and removes barriers, which isn’t necessarily noticed as much as a shiny new product. The example of GDS (Government Digital Service) redesigning every government department from a service design perspective and removing many frustrating and laborious aspects of public life from taxing a car to getting a passport, is one of the best.

The key difference between service design and UX is that it’s end product is not something on a screen:

But service design is not just the experience we have through the glass of a screen or a device: it’s designed from the starting point of the broader objective and may include many other channels and touchpoints. I think it was Colin Burns who said a product is just a portal to a service.

In other words, if you open the aperture of what user experience means, and take on the challenge of designing real-world processes, flows, and interaction—that is service design.

Stephanie Tyler, in a great essay about remembering what we do as designers:

In an age where AI can generate anything, the question is no longer ‘can it be made?’ but ‘is it worth making?’ The frontier isn’t volume—it’s discernment. And in that shift, taste has become a survival skill.

And this is my favorite passage, because this is how I think about this blog and my newsletter.

There will always be creators. But the ones who stand out in this era are also curators. People who filter their worldview so cleanly that you want to see through their eyes. People who make you feel sharper just by paying attention to what they pay attention to.

Curation is care. It says: I thought about this. I chose it. I didn’t just repost it. I didn’t just regurgitate the trending take. I took the time to decide what was worth passing on.

That’s rare now. And because it’s rare, it’s valuable.

We think of curation as a luxury. But it’s actually maintenance. It’s how you care for your mind. Your attention. Your boundaries.

This blog represents my current worldview, what I’m interested in and exploring. What I’m thinking about now.

Speaking of prompt engineering, apparently, there’s a new kind in town called context engineering.

Developer Philipp Schmid writes:

What is context engineering? While “prompt engineering” focuses on crafting the perfect set of instructions in a single text string, context engineering is a far broader. Let’s put it simply: “Context Engineering is the discipline of designing and building dynamic systems that provides the right information and tools, in the right format, at the right time, to give a LLM everything it needs to accomplish a task.”

In a dual profile, Ben Blumenrose spotlights Phil Vander Broek—whose startup Dopt was acquired last year by Airtable—and Filip Skrzesinski—who is currently working on Subframe—in the Designer Founders newsletter.

One of the lessons Vander Broek learned was to not interview customers just to validate an idea. Interview them to get the idea first. In other words, discover the pain points:

They ran 60+ interviews in three waves. The first 20 conversations with product and growth leaders surfaced a shared pain point: driving user adoption was painfully hard, and existing tools felt bolted on. The next 20 calls helped shape a potential solution through mockups and prototypes—one engineer was so interested he volunteered for weekly co-design sessions. A final batch of 20 calls confirmed their ideal customer was engineers, not PMs.

As for Skrzesinski, he’s learning that being a startup founder isn’t about building the product—it’s about building a business:

But here’s Filip’s counterintuitive advice: “Don’t start a company because you love designing products. Do it in spite of that.”

“You won’t be designing in the traditional sense—you’ll be designing the company’s DNA,” he explains. “It’s the invisible work: how you organize, how you think, how you make decisions. How it feels to work there, to use what you’re making, to believe in it.”

My family and I are going on vacation, and I thought it might be great to share this design summer reading list from Design Better. For me, I’ll be picking up Nonlinear by Kevin Bethune. It looks great.

Brian Balfour, writing for the Reforge blog:

Speed isn’t just about shipping faster, it’s about accelerating your entire learning metabolism. The critical metric isn’t feature velocity but rather your speed through the complete Insight → Act → Learn loop. This distinction separates products that compound advantages from those that compound technical debt.

The point being that now with AI, product teams are shipping faster. And those who aren’t might get lapped (to use an F1 phrase).

I’ve been very interested in finding tools to close the design-to-code gap. Martina Sartor writing in UX Planet articulates why that is so important:

After fifteen years hopping between design systems, dev stand-ups, and last-minute launch scrambles, I’m convinced design-to-dev QA is still one of the most underestimated bottlenecks in digital product work. We pour weeks into meticulous Figma files, yet the last mile between mock-up and production code keeps tripping us up.

This is an honest autopsy of why QA hurts and how teams can start healing it — today — without buying more software (though new approaches are brewing).

In the early days of computing, it was easy for one person to author a complete program. Nowadays, because the software we create is so complex, we need teams.

Gaurav Sinha writing for UX Planet:

The faster you accept that they’re not going to change their communication style, the faster you can focus on what actually works — learning to decode what they’re really telling you. Because buried in all that technical jargon is usually something pretty useful for design decisions.

It’s a fun piece on learning how to speak engineer.