New Ways of Working

Systems, not screens: teaching an organization to design for AI

The hard part is not new tools. It is a bigger unit of design.

Designers are moving closer to engineering, and the common explanation gets it backwards. It is not happening because designers are learning to code. It is happening because the tools now generate the code, which pulls design and product into territory engineering used to hold alone. That distinction changes how you frame the role, and the framing decides whether people come along.

The real shift is that the unit of design gets bigger. A screen is no longer the whole object. The object is behavior: what the system knows, what it remembers, when it acts on its own, how it asks for help, how it fails. That behavior spans interfaces that never appear in a mockup. Designing it means specifying things designers were once allowed to treat as someone else's problem.

The risk we watch for is over-rotation. When the role evolution reads as become an engineer, two things go wrong at once. Experienced designers hear that their judgment is obsolete, which is false. And newer designers skip the discipline of understanding people, which is the one part that does not automate. Every version of the new role has to lead with the user, not the stack.

We also see teams skip low-fidelity work entirely and go straight to working prototypes. The purpose of the old artifacts survives. The form is chaos. The answer is not to mourn wireframes. It is to be explicit about what each artifact is for, so a working prototype can carry the same conversation a sketch used to.

The signal that the shift has taken hold: a design review where the artifact on the wall is a map of system behavior, not a set of screens. When that happens without anyone prompting it, the teaching is done.

Filed under New Ways of Working