When everyone can make UI, what does the design team own?When everyone can make UI, what does the design team own?

When a PM, an engineer, and a designer can each produce a working screen in an afternoon, nobody can claim design by pointing at the screen. Designer Fund's AI in Design 2026 report found that 65% of designers are taking on more product or engineering work, that 40% say PMs and engineers contribute more to design than they used to, and that the share who say AI has reduced collaboration with teammates went from 5% to 20%. The boundary has moved, and a design org that keeps defending the old one will spend its energy on turf. The territory worth holding is the system everyone builds from, the checks that say whether a thing is right, the written-down taste that lets anyone judge a screen, and the decision about what gets built.

When PMs prototype

PMs on my team have started prototyping, and design's response that worked was to review the prototypes and coach the PMs on what to fix. A prototype shows what a PM means better than a document does, and a review of it turns into a short, specific lesson about the system, the states, or the interaction that the PM carries into the next prototype. The coaching also keeps the relationship pointed the right way: the PM learns what on-system looks like, design sees the product question earlier than a handoff would have shown it, and the designer's week moves from redrawing screens to teaching the people who now make them.

The system

Design owns the shared definition of what the product is made of, and the test of ownership is whether generated work lands inside it by default. Whoever maintains the token source, the components, and the written design doc decides what everyone else's output looks like, which is more design influence than reviewing screens ever gave. A PM who starts a prototype from those pieces produces something that already belongs to the product, and the review conversation can spend its time on the idea.

Taste, written down

Taste stays implicit until someone writes it as a list, and implicit taste can only be applied by the person who has it. A design org can write a short list of the specific things that make an interface feel wrong in its product (spacing that ignores the scale, a modal where an inline edit belongs, a loading state that vanishes), specific enough that a PM's session can check itself against it. The same move works for text, and the guide behind this site's voice shows how far a written list goes. A list like that lets design's judgment apply to every screen the other roles now produce.

What gets built

When anyone can build anything, the scarce decision is which thing to build and which to leave alone. Design should hold the calls that are expensive and hard to undo, such as a new shared component that everything downstream will depend on, and let everything cheap and reversible move without a gate. A team that says so out loud gives PMs and engineers a clear zone of freedom, and they use it.

The org move

Put these four into your team's charter and tell the team that screens are no longer the territory. Rewrite the ladder so a senior's row describes owning the system, the checks, the written taste, and the build decision, as I covered in what a design career ladder actually measures, since the rows people are promoted against decide what they spend their week on. Then start with the least visible of the four and write down five things that make an interface feel wrong in your product, specific enough that someone outside design could check a screen against them.