Last month I shipped an iOS app. I designed it, wrote the code (with the help of Claude), got it through App Store review, and published a blog post about what it taught me about designing a solid onboarding experience. I’m a UX director by title. I did it because I could, and because it solved a problem I have in a novel way that I think will be useful.

Earlier this year I created a feature to help Invoca customers understand the built-in and custom data in their accounts and how it travels within and outside of the platform. I did so because I found that even the most knowledgeable Invocans disagreed about how the customers they support had configured the platform, and as I investigated one such customer I had to do a lot of manual work to trace the flow of data as calls came in and were measured, webhooks fired, writebacks accomplished, signals evaluated. The centerpiece of my pitch, now on the roadmap, was a working prototype using actual customer configuration data that exposed the relationships between the fields and the classifiers, events, and integrations that write, read, and manipulate them. I did it because I could, and because it solved a problem users have in a way that customers find useful and Customer Success Managers desperately want.

This isn’t a flex; if anything, it’s becoming table-stakes for any product manager or designer.

The lines between product management, engineering, and design have been blurring for years. Who owns research? Who owns the customer problem? Who owns accessibility? Who owns measurement? AI design and development tooling has accelerated this trend past the point where anyone can ignore it. A PM who can write a working prototype in an afternoon changes what they need from a designer. An engineer who can generate UI variations in minutes changes what “handoff” means. A designer who can correct an accessibility problem in code and submit a pull request to put that into production has reduced the load on engineering. A designer who can solve a customer problem via a prototype that uses real data has made product management easier and provided more direction to engineering than a sheaf of pictures of interfaces ever could.

If you stay in your lane you are now the bottleneck. This isn’t bad news for designers; it’s exciting to be able to do more, to bring concepts all the way up to the glass.

The best designers I’ve worked with were never purely visual thinkers. Many didn’t have formal design training. They came from mechanical engineering, psychology, industrial design, education – fields that gave them a broader perspective. They were curious about systems, could hold a technical constraint in one hand and a user need in the other, and knew enough to offer possibilities about system behavior, to open engineers’ eyes to alternative solutions. What’s changed is that the tools now let designers satisfy their curiosity more directly. AI-powered prototyping shrinks the distance between an idea and a working thing you can test.

The closer you get to shipping, the better your design gets. You start making decisions with real consequences. You trip over edge cases earlier as you find the limits of the data available to you.

The flip side is that the blur creates a challenge for design leaders. The jobs that matter most — raising the strategic value of design, keeping teams focused on actual customer needs, developing designer capability and integration — are all in flux at once as teams figure out how to work together anew.

Getting your hands dirty with the new tools is critical for design leaders in this moment of upheaval. Design leaders once could champion established processes they learned earlier in their careers; these processes are being thoroughly upset now. You still have to establish standards, reassert the user’s interests, and manage competing priorities, but the way the team will work is not yet established. A director who hasn’t used these tools can’t lead the conversation about them.

A PM with Figma Make might feel they don’t need a designer to make something ready for engineers to chew on. An engineer with Claude Code might prefer to ship and measure in hopes that their idea about the customer problem was sound. A designer with Lovable might race on past the product manager and the engineer to put a prototype in customer hands. Any of these can move fast. Any of them can also skip right past the problem they were trying to solve. The tools accelerate both good judgment and bad — which is exactly why someone needs to stay oriented to what users actually need, and why that someone needs to be in the room, not waiting to be consulted.

Designers can no longer be a translation layer between PM and engineering. A designer’s knowledge of workflows, alternative controls, customer vocabulary, user attention management, and patterns from outside their industry is especially well-suited to offer useful new ideas to their organization. The pressure is on designers to explore and offer concepts that are more fully-realized, more directly testable, and more cognizant of the engineering environment than ever before.

The result is a demand for designers that have more depth in areas adjacent to their traditional role, with more fluency in front-end development, data structures, customer development, metrics. There’s more pressure to have range. A designer with range understands enough about product strategy and code to collaborate without translation – to drive the conversation rather than draft behind it. That’s different from being asked to do everyone’s job.

The designers and design leaders who will matter most in the next few years are the ones who have genuine range and can show that their concepts are actually useful, feasible, and convenient for users, not just assert that through good diagramming. Not decorators, not generalists who do a little of everything. People who know how to use AI tools to close the gap between intent and execution and who understand that the hardest design problem is finding and expressing the direction that is sound, not just generating options or polishing the chosen solution.

That’s still what design is for: knowing whether what you’re building will actually work for the people who have to use it, and having the prototyping capability to prove it before it ships. The tools make that proof faster and more convincing. They don’t make the underlying judgment less necessary.