Ted Goas, writing in UX Collective:

I predict the early parts of projects, getting from nothing to something, will become shared across roles. For designers looking to branch out, code is a natural next step. I see a future where we’re fixing small bugs ourselves instead of begging an engineer, implementing that animation that didn’t make the sprint but you know would absolutely slap, and even building simple features when engineering resources are tight.

Our new reality is that anyone can make a rough draft.

But that doesn’t mean those drafts are good. That’s where our training and taste come in.

I think Goas is right and it echoes the AI natives post by Elena Verna. I wrote a little more extensively in my newsletter over the weekend.

Miquad Jaffer, a product leader at OpenAI shares his 4D method on how to build AI products that users want. In summary, it’s…

• Discover: Find and prioritize real user pain points and friction in daily workflows.
• Design: Make AI features invisible and trustworthy, fitting naturally into users’ existing habits.
• Develop: Build AI systematically, with robust evaluation and clear plans for failures or edge cases.
• Deploy: Treat each first use like a product launch, ensuring instant value and building user trust quickly.

Geoffrey Litt, Josh Horowitz, Peter van Hardenberg, and Todd Matthews writing a paper for research lab Ink & Switch, offer a great, well-thought piece on what they call “malleable software.”

We envision a new kind of computing ecosystem that gives users agency as co-creators. … a software ecosystem where anyone can adapt their tools to their needs with minimal friction. … When we say ‘adapting tools’ we include a whole range of customizations, from making small tweaks to existing software, to deep renovations, to creating new tools that work well in coordination with existing ones. Adaptation doesn’t imply starting over from scratch.

In their paper, they use analogies like kitchen tools and tool arrangement in a workshop to explore their idea. With regard to the current crop of AI prompt-to-code tools…

We think these developments hold exciting potential, and represent a good reason to pursue malleable software at this moment. But at the same time, AI code generation alone does not address all the barriers to malleability. Even if we presume that every computer user could perfectly write and edit code, that still leaves open some big questions.

How can users tweak the existing tools they’ve installed, rather than just making new siloed applications? How can AI-generated tools compose with one another to build up larger workflows over shared data? And how can we let users take more direct, precise control over tweaking their software, without needing to resort to AI coding for even the tiniest change? None of these questions are addressed by products that generate a cloud-hosted application from a prompt.

Kind of a different take than the “personal software” we’ve seen written about before.

John Calhoun joined Apple 30 years ago as a programmer to work on the Color Picker.

Having never written anything in assembly, you can imagine how overjoyed I was. It’s not actually a very accurate analogy, but imagine someone handing you a book in Chinese and asking you to translate it into English (I’m assuming here that you don’t know Chinese of course). Okay, it wasn’t that hard, but maybe you get a sense that this was quite a hurdle that I would have to overcome.

Calhoun was given an old piece of code and tasked with updating it. Instead, he translated it into a programming language he knew—C—and then decided to add to the feature. He explains:

I disliked HSL as a color space, I preferred HSV (Hue, Saturation, Value) because when I did artwork I was more comfortable thinking about color in those terms. So writing an HSV color picker was on my short list.

When I had my own color picker working I think I found that it was kind of fun. Perhaps for that reason, I struck out again and wrote another color picker. The World Wide Web (www) was a rather new thing that seemed to be catching on, so I naturally thought that an HTML color picker made sense. So I tackled that one as well. It was more or less the RGB color picker but the values were in hexadecimal and a combined RGB string value like “#FFCC33” was made easy to copy for the web designer.

So an engineer decided, all on his own, that he’d add a couple extra features. Including the fun crayon picker:

On a roll, I decided to also knock out a “crayon picker”. At this point, to be clear, the color picker was working and I felt I understood it well enough. As I say, I was kind of just having some fun now.

And Calhoun makes this point:

It was frankly a thing I liked about working for Apple in those days. The engineers were the one’s driving the ship. As I said, I wrote an HSV picker because it was, I thought, a more intuitive color space for artists. I wrote the HTML color picker because of the advent of the web. And I wrote the crayon picker because it seemed to me to be the kind of thing Apple was all about: HSL, RGB — these were kind of nerdy color spaces — a box of crayons is how the rest of us picked colors.

Making software—especially web software—has matured since then, with product managers and designers now collaborating closely with engineers. But with AI coding assistants, the idea of an individual contributor making solo decisions and shipping code might become de rigueur again.

Read past some of the hyperbole in this piece by Andy Budd. I do think the message is sound.

If you’re working at a fast-growth tech startup, you’re probably already feeling the pressure. Execs want more output with fewer people. Product and engineering are experimenting with AI tooling. And you’re being asked to move faster than ever — with less clarity on what the team should even own.

I will admit that I personally feel this pressure too. Albeit, not from my employer but from the chatter in our industry. I’m observing the younger companies experiment with the process, collapsing roles, and expanding responsilities.

As AI eats into the production layer, the traditional boundaries between design and engineering are starting to dissolve. Many of the tasks once owned by design will soon be handled by others — or by machines.

Time will tell when this becomes widespread. I think designers will be asked to ship more code. And PMs and engineers may ship small design tweaks.

The reality is, we’ll likely need fewer designers overall. But the ones we do need will be more specialised, more senior, and more strategically valuable than ever before.

You’ll want AI-literate, full-stack designers — people who are comfortable working across the entire product surface, from UX to code, and from interface to infrastructure. Designers who can navigate ambiguity, embrace new tooling, and confidently operate in the blurred space between design and engineering.

I don’t know if I agree with the fewer number of designers. At least not in the near-term. The more AI is embedded into app experiences, the trend—I predict—will go in the opposite direction. The term “AI as material” has been floating around for a few months, but I think its meaning will morph. AI will be the new UI, and thus we need designers to help define those experiences.

Tom Scott, giving advice to startups about how to hire designers:

The worst thing for a designer is join a company under the premise they are going to invest in craft and never get serious about it. This results in the designer getting stuck in an average company, making it harder for them to move into a top-tier design-led company afterwards.

The TL;DR is if you’re serious about hiring great talent, put your money where your mouth is, create the right environment and get serious about design like you do with product, eng, marketing etc.

While the post is aimed at startup employers, it’s good for designers to understand the advice they’re being given.

Here we go. Figma has just dropped their S-1, or their registration for an initial public offering (IPO).

Rollup of stats from Figma’s S-1.

While a lot of the risk factors are boilerplate—legalese to cover their bases—the one about AI is particularly interesting, “Competitive developments in AI and our inability to effectively respond to such developments could adversely affect our business, operating results, and financial condition.”

Developments in AI are already impacting the software industry significantly, and we expect this impact to be even greater in the future. AI has become more prevalent in the markets in which we operate and may result in significant changes in the demand for our platform, including, but not limited to, reducing the difficulty and cost for competitors to build and launch competitive products, altering how consumers and businesses interact with websites and apps and consume content in ways that may result in a reduction in the overall value of interface design, or by otherwise making aspects of our platform obsolete or decreasing the number of designers, developers, and other collaborators that utilize our platform. Any of these changes could, in turn, lead to a loss of revenue and adversely impact our business, operating results, and financial condition.

There’s a lot of uncertainty they’re highlighting:

• Could competitors use AI to build competing products?
• Could AI reduce the need for websites and apps which decreases the need for interfaces?
• Could companies reduce workforces, thus reducing the number of seats they buy?

These are all questions the greater tech industry is asking.

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.”

Darragh Burke and Alex Kern, software engineers at Figma, writing on the Figma blog:

Building code layers in Figma required us to reconcile two different models of thinking about software: design and code. Today, Figma’s visual canvas is an open-ended, flexible environment that enables users to rapidly iterate on designs. Code unlocks further capabilities, but it’s more structured—it requires hierarchical organization and precise syntax. To reconcile these two models, we needed to create a hybrid approach that honored the rapid, exploratory nature of design while unlocking the full capabilities of code.

The solution turned out to be code layers, actual canvas primitives that can be manipulated just like a rectangle, and respects auto layout properties, opacity, border radius, etc.

The solution we arrived at was to implement code layers as a new canvas primitive. Code layers behave like any other layer, with complete spatial flexibility (including moving, resizing, and reparenting) and seamless layout integration (like placement in autolayout stacks). Most crucially, they can be duplicated and iterated on easily, mimicking the freeform and experimental nature of the visual canvas. This enables the creation and comparison of different versions of code side by side. Typically, making two copies of code for comparison requires creating separate git branches, but with code layers, it’s as easy as pressing ⌥ and dragging. This automatically creates a fork of the source code for rapid riffing.

In my experience, it works as advertised, though the code layer element will take a second to render when its spatial properties are edited. Makes sense though, since it’s rendering code.

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.

If you want an introduction on how to use Cursor as a designer, here’s a must-watch video. It’s just over half-an-hour long and Elizabeth Lin goes through several demos in Cursor.

Cursor is much more advanced than the AI prompt-to-code tools I’ve covered here before. But with it, you’ll get much more control because you’re building with actual code. (Of course, sigh, you won’t have sliders and inputs for controlling design.)

Vincent Nguyen writing for Yanko Design, interviewing Alan Dye, VP of Human Interface Design at Apple:

This technical challenge reveals the core problem Apple set out to solve: creating a digital material that maintains form-changing capabilities while preserving transparency. Traditional UI elements either block content or disappear entirely, but Apple developed a material that can exist in multiple states without compromising visibility of underlying content. Dye’s emphasis on “celebrating user content” exposes Apple’s hierarchy philosophy, where the interface serves content instead of competing with it. When you tap to magnify text, the interface doesn’t resize but stretches and flows like liquid responding to pressure, ensuring your photos, videos, and web content remain the focus while navigation elements adapt around them.

Since the Jony Ive days, Apple’s hardware has always been about celebrating the content. Bezels got smaller. Screens got bigger and brighter. Even the flat design brought on by iOS 7 and eventually adopted by the whole ecosystem was a way to strip away the noise and focus on the content.

Dye’s explanation of the “glass layer versus application layer” architecture provides insight into how Apple technically implements this philosophy. The company has created a distinct separation between functional controls (the glass layer) and user content (the application layer), allowing each to behave according to different rules while maintaining visual cohesion. This architectural decision enables the morphing behavior Dye described, where controls can adapt and change while content remains stable and prominent.

The Apple platform UI today sort of does that, but Liquid Glass seems to take it even further.

Nguyen about his experience using the Music app on Mac:

The difference from current iOS becomes apparent in specific scenarios. In the current Music app, scrolling through your library feels like moving through flat, static layers. With Liquid Glass, scrolling creates a sense of depth. You can see your album artwork subtly shifting beneath the translucent controls, creating spatial awareness of where interface elements sit in relation to your content. The tab bar doesn’t just scroll with you; it creates gentle optical distortions that make the underlying content feel physically present beneath the glass surface.

Sara Paul writing for NN/g:

The core principles of UX and product design remain unchanged, and AI amplifies their importance in many ways. To stay indispensable, designers must evolve: adapt to new workflows, deepen their judgment, and double down on the uniquely human skills that AI can’t replace.

They spoke with seven UX practitioners to get their take on AI and the design profession.

I think this is great advice and echoes what I’ve written about previously (here and here):

There is a growing misconception that AI tools can take over design, engineering, and strategy. However, designers offer more than interaction and visual-design skills. They offer judgment, built on expertise that AI cannot replicate.

Our panelists return to a consistent message: across every tech hype cycle, from responsive design to AI, the value of design hasn’t changed. Good design goes deeper than visuals; it requires critical thinking, empathy, and a deep understanding of user needs.

Great reminder from Kai Wong about getting stuck on a solution too early:

Imagine this: the Product Manager has a vision of a design solution based on some requirements and voices it to the team. They say, “I want a table that allows us to check statuses of 100 devices at once.”

You don’t say anything, so that sets the anchor of a design solution as “a table with a bunch of devices and statuses.”

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.

Nate Jones performed a yeoman’s job of summarizing Mary Meeker’s 340-slide deck on AI trends, the “2025 Technology as Innovation (TAI) Report.” For those of you who don’t know, Mary Meeker is a famed technology analyst and investor known for her insightful reports on tech industry trends. For the longest time, as an analyst at Kleiner Perkins, she published the Internet Trends report. And she was always prescient.

Half of Jones’ post is the summary, while the other half is how the report applies to product teams. The whole thing is worth 27 minutes of your time, especially if you work in software.

As a reaction to the OpenAI + io announcement two weeks ago, Christopher Butler imagines a mesh computing device network he calls “personal ambient computing”:

…I keep thinking back to Star Trek, and how the device that probably inspired the least wonder in me as a child is the one that seems most relevant now: the Federation’s wearables. Every officer wore a communicator pin — a kind of Humane Pin light — but they also all wore smaller pins at their collars signifying rank. In hindsight, it seems like those collar pins, which were discs the size of a watch battery, could have formed some kind of wearable, personal mesh network. And that idea got me going…

He describes the device as a standardized disc that can be attached to any enclosure. I love his illustration too:

Christopher Butler: “I imagine a magnetic edge system that allows the disc to snap into various enclosures — wristwatches, handhelds, desktop displays, wearable bands, necklaces, clips, and chargers.”

Essentially, it’s an always-on, always observing personal AI.

Following up on OpenAI’s acquisition of Jony Ive’s hardware startup, io, Mark Wilson, writing for Fast Company:

As Ive told me back in 2023, there have been only three significant modalities in the history of computing. After the original command line, we got the graphical user interface (the desktop, folders, and mouse of Xerox, Mac OS, and Windows), then voice (Alexa, Siri), and, finally, with the iPhone, multitouch (not just the ability to tap a screen, but to gesture and receive haptic feedback). When I brought up some other examples, Ive quickly nodded but dismissed them, acknowledging these as “tributaries” of experimentation. Then he said that to him the promise, and excitement, of building new AI hardware was that it might introduce a new breakthrough modality to interacting with a machine. A fourth modality.

Hmm, it hasn’t taken off yet because AR hasn’t really gained mainstream popularity, but I would argue hand gestures in AR UI to be a fourth modality. But Ive thinks different. Wilson continues:

Ive’s fourth modality, as I gleaned, was about translating AI intuition into human sensation. And it’s the exact sort of technology we need to introduce ubiquitous computing, also called quiet computing and ambient computing. These are terms coined by the late UX researcher Mark Weiser, who in the 1990s began dreaming of a world that broke us free from our desktop computers to usher in devices that were one with our environment. Weiser did much of this work at Xerox PARC, the same R&D lab that developed the mouse and GUI technology that Steve Jobs would eventually adopt for the Macintosh. (I would also be remiss to ignore that ubiquitous computing is the foundation of the sci-fi film Her, one of Altman’s self-stated goalposts.)

Ah, essentially an always-on, always watching AI that is ready to assist. But whatever the form factor this device takes, it will likely depend on a smartphone:

The first io device seems to acknowledge the phone’s inertia. Instead of presenting itself as a smartphone-killer like the Ai Pin or as a fabled “second screen” like the Apple Watch, it’s been positioned as a third, er, um … thing next to your phone and laptop. Yeah, that’s confusing, and perhaps positions the io product as unessential. But it also appears to be a needed strategy: Rather than topple these screened devices, it will attempt to draft off them.

Wilson ends with the idea of a subjective computer, one that has personality and gives you opinions. He explains:

I think AI is shifting us from objective to subjective. When a Fitbit counts your steps and calories burned, that’s an objective interface. When you ask ChatGPT to gauge the tone of a conversation, or whether you should eat better, that’s a subjective interface. It offers perspective, bias, and, to some extent, personality. It’s not just serving facts; it’s offering interpretation.

The entire column is worth a read.

Nick Babich writing for UX Planet:

Because AI design and code generators quickly take an active part in the design process, it’s essential to understand how to make the most of these tools. If you’ve played with Cursor, Bolt, Lovable, or v0, you know the output is only as good as the input.

Well said, especially as prompting is the primary input for these AI tools. He goes on to enumerate his five parts to a good prompt. Worth a quick read.

Related to my earlier post today about Arc’s novelty tax, here’s an essay by DOC, a tribute to consistency.

Leveraging known, established UX patterns and sticking to them prevent users from having to learn net-new interactions and build net-new mental models every time they engage with a new product.

But, as Josh Miller wrote in the aforementioned post, “New interfaces start from familiar ones.” DOC’s essay uses jazz as a metaphor:

Consistency is about making room for differentiation. Think about a jazz session: the band starts from a known scale, rhythm. One musician breaks through, improvising on top of that pattern for a few minutes before joining the band again. The band, the audience, everyone knows what is happening, when it starts and when it ends, because the foundation of it all is a consistent melody.

Patrick Morgan writing for UX Collective:

The tactical tasks that juniors traditionally cut their teeth on are increasingly being delegated to AI tools. Tasks that once required a human junior designer with specialized training can now be handled by generative AI tools in a fraction of the time and cost to the organization.

This fundamentally changes the entry pathway. When the low-complexity work that helped juniors develop their skills is automated away, we lose the natural onramp that allowed designers to gradually progress from tactical execution to strategic direction.

Remote work has further complicated things by removing informal learning opportunities that happen naturally in an in-person work environment, like shadowing senior designers, being in the room for strategy discussions, or casual mentorship chats.

I’ve been worried about this a lot. I do wonder how the next class of junior designers—and all professionals, for that matter—will learn. (I cited Aneesh Raman, chief economic opportunity officer at LinkedIn, in my previous essay.)

Morgan does have some suggestions:

Instead of waiting for the overall market to become junior-friendly again (which I don’t see happening), focus your search on environments more structurally accepting of new talent:

1. Very early-stage startups: Pre-seed or seed companies often have tight budgets and simply need someone enthusiastic who can execute designs. It will be trial-by-fire, but you’ll gain rapid hands-on experience.

2. Stable, established businesses outside of ‘big tech’: Businesses with predictable revenue streams often provide structured environments for junior designers (my early experience at American Express is a prime example). It might not be as glamorous as a ‘big tech’ job, but as a result they’re less competitive while still offering critical experience to get started.

3. Design agencies: Since their business model focuses on selling design services, agencies naturally employ more designers and can support a mix of experience levels. The rapid exposure to multiple projects makes them solid launchpads even if your long-term goal is to work in-house in tech.