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.

When you’re building a SaaS app, I believe it’s important to understand the building blocks, or objects, in your app. What are they? How do they relate to each other? Should those relationships be peer-to-peer or parent-child? Early in my tenure at BuildOps, I mentioned this way of thinking to one of my designers and they pointed me to Object-Oriented UX (OOUX), a methodology pioneered by Sophia Prater.

Mateusz Litarowicz writes:

Object-Oriented UX is a way of thinking about design, introduced and popularized by Sophia Prater. It assumes that instead of starting with specific screens or user flows, we begin by identifying the objects that should exist in the system, their attributes, the relationships between them, and the actions users can take on those objects. Only after this stage do we move on to designing user flows and wireframes.

To be honest, I’d long thought this way, ever since my days at Razorfish when our UX director Marisa Gallagher talked about how every website is built around a core unit, or object. At the time, she used Netflix as an example—it’s centered around the movie. CRMs, CMSes, LMSes, etc. are all object-based.

Anyway, I think Litarowicz writes a great primer for OOUX. The other—and frankly more important, IMHO—advantage to thinking this way, especially for a web app, is because your developers think this way too.

Apologies for linking to a lot of Christopher Butler recently, but I really love his thinking about design. This time, Butler reminds us about the importance of structure and how the proto-graphic designers we studied in art history, like Piet Mondrian, mastered it.

A well-composed photograph communicates something essential even before we register its subject. A thoughtfully designed page layout feels right before we read a single word. There’s something happening in that first moment of perception that transcends the individual elements being composed.

My favorite passage in his essay begins here:

Perhaps we “read” composition the way we read text — our brains processing visual structure as a kind of fundamental grammar that exists beneath conscious recognition. Just as we don’t typically think about parsing sentences into subjects and predicates while reading, we don’t consciously deconstruct the golden ratio or rule of thirds while looking at an image. Yet in both cases, our minds are translating structure into meaning.

The next eight short paragraphs build on this idea and crescendo with this banger:

In recognizing composition as this fundamental visual language, we begin to understand why good design works at such a deep level. It’s not just about making things look nice — it’s about speaking fluently in a language that predates words, tapping into patterns of perception that feel as natural as breathing.

Composition is a fundamental visual language. I had never thought of it that way and yet it feels right.

The whole thing is great. Please go read it.

I am a huge Severance fan (as evidenced by my Outie fact generator). Here’s a behind-the-scenes look at how the “Lumon Listens” animated sequence from the premiere of season two came together.

For as long as I can remember, I’ve been fascinated by how television shows and movies are made. I remember the specials ABC broadcast about the making of The Empire Strikes Back and other Lucasfilm movies like the Indiana Jones series. More recently—especially with the advent of podcasts—I’ve loved listening to how show runners think about writing their shows. For example, as soon as an episode of Battlestar Galactica aired, I would rewatch it with Ronald D. Moore’s commentary. These days, I‘m really enjoying the official The Last of Us podcast because it features commentary from both Craig Mazin and Neil Druckmann.

Anyway, thinking about personas as characters from TV shows and movies and using screenwriting techniques is right up my alley. Laia Tremosa for the IxDF:

Hollywood spends millions to bring characters to life. UX design teams sometimes spend weeks… only to make personas no one ever looks at again. So don’t aim for personas that look impressive in a slide deck. Aim for personas that get used—in design reviews, product decisions, and testing plans.

Be the screenwriter. Be the director. Be the casting agent.

Dan Maccarone:

If users don’t trust the systems we design, that’s not a PM problem. It’s a design failure. And if we don’t fix it, someone else will, probably with worse instincts, fewer ethics, and a much louder bullhorn.

UX is supposed to be the human layer of technology. It’s also supposed to be the place where strategy and empathy actually talk to each other. If we can’t reclaim that space, can’t build products people understand, trust, and want to return to, then what exactly are we doing here?

It is a long read but well worth it.

Elliot Vredenburg writing for Fast Company:

Which is why creative direction matters more now than ever. If designers are no longer the makers, they must become the orchestrators. This isn’t without precedent. Rick Rubin doesn’t read music or play instruments. Virgil Abloh was more interested in recontextualizing than inventing. Their value lies not in original execution but in framing, curation, and translation. The same is true now for brand designers. Creative direction is about synthesizing abstract ideas into aesthetic systems—shaping meaning through how things feel, not just how they look.

Haiyan Zhang gives us another way of thinking about AI—as material, like clay, paint, or plywood—instead of a tool. I like that because it invites exploration:

When we treat AI as a design material, prototyping becomes less about refining known ideas — and more about expanding the space of what’s possible. It’s messy, surprising, sometimes frustrating — but that’s what working with any material feels like in its early days.

Clay resists. Wood splinters. AI misinterprets.

But in that material friction, design happens.

The challenge ahead isn’t just to use AI more efficiently — it’s to foster a culture of design experimentation around it. Like any great material, AI won’t reveal its potential through control, but through play, feedback, and iteration.

I love this metaphor. It’s freeing.