|||
For years, I’ve been circling around a term to describe the kind of design work I actually do. Not just service design. Not just IA or UX or content strategy or operations. But the full complexity of designing how people interact with systems—especially under real-world constraints.
For a while, I called it interaction architecture. And that worked… until it didn’t.
Because “architecture” implies permanence. Blueprints. Finished buildings. But in tech, nothing’s ever really done. And that framing has always felt a little off for work that’s constantly adapting to policy shifts, team turnover, scaling pains, and edge-case users who were never part of the original plan.
So I’ve started calling it something else: Interaction Engineering.
UX has been stretched so thin it’s become both everything and nothing. A catchall for anyone who touches an interface, whether they’re mapping complex systems or just pushing pixels in Figma.
When Don Norman coined “user experience” in the 90s, it gave us a shared center of gravity. But over time, something shifted:
This isn’t about gatekeeping or nostalgia. It’s about clarity. When a term means everything, it means nothing. And right now, the gap between what we call UX and what many of us actually do has grown too wide to ignore.
Interaction Engineering is about designing systems that can handle stress—organizational, technical, and human. It’s less about visual polish and more about structural clarity. It’s about what happens after the first release. When requirements change, teams change, and users bring the full mess of real life into your flows.
It’s the part of design most orgs don’t really have a name for—so they either shove it under UX, expect product to do it, or ignore it until something breaks.
But there’s a reason engineers exist. Not just to build code, but to understand systems under strain. Load-bearing moments. Latent brittleness. Cascading failure.
Designers know how to navigate this too. But we rarely get to name that expertise in a way that lands.
In practice, Interaction Engineering looks like:
It sits at the intersection of service design, systems thinking, and product delivery—but with a sharper focus on structural integrity over time.
For a few years now, I’ve been writing and speaking about consequence design—the practice of designing with an awareness of not just what happens when things go right, but what happens when they go wrong. When systems fail. When policies shift. When edge cases become the norm.
But there’s always been a gap between that concept and its implementation. Consequence design demands a level of organizational influence and authority that designers simply haven’t had in most organizations. We’re often brought in too late, positioned too narrowly, or detached from the operational realities where consequences actually play out.
Interaction Engineering bridges this gap. It provides a framework for implementing consequence-aware design through structural interventions that can withstand real-world complexity. It gives designers language to assert their value in terms organizations already understand and respect.
Yes, I know “engineering” is a loaded word. But so is “architecture.” And “design.” And “strategy.” And we’ve diluted UX so much that it means whatever the recruiter says it means this week.
So I’m picking a term that speaks to durability. Structure. Consequence.
The engineer part matters. Not because it’s about code, but because it’s about integrity. Engineers build things that last. They account for stress, load, and failure. They design with constraints, not in spite of them.
In product organizations where engineering already has cultural currency, “Interaction Engineering” creates a natural bridge. It signals that design isn’t just about visuals—it’s about building systems that function, adapt, and endure.
This isn’t a new job title. It’s not about gatekeeping. And no, I’m not trying to make “fetch” happen.
But I am trying to name a mode of work that’s missing from too many orgs: The one that thinks past launch. That sees the service layer as more than a series of screens. That understands how to translate complexity into flows that won’t collapse the first time someone hits a weird edge case.
Because Interaction Engineering is not about making things look good. It’s about making them hold up.
This is part of a larger framework I’ve been developing about how systems behave, fail, and adapt. Interaction Engineering is the practice-forward component—a way to bring consequence design into everyday work without waiting for the perfect org structure or authority.
In the coming months, I’ll be expanding on this concept with more depth, including how it relates to interaction architecture as a structural approach, and where they diverge in practice and application.
Because ultimately, this isn’t about titles. It’s about clarity. When we can name what we do with precision, we can do it with intention.
Drafted while listening to Boards of Canada — “Chromakey Dreamcoat”