Interaction Models: How Not to Make Users Hate Your Interface

Ever opened an app that behaves like a faulty elevator — buttons do random things, and you never know if you'll end up in the basement? That's a broken interaction model. In simple terms, it's the unwritten agreement between user and interface: "you click here, I do that." Break the deal, and you get a rage-quit.

Why should you care?

Imagine assembling IKEA furniture with instructions in Klingon and parts from different boxes. That's what users feel when the interaction model doesn't match their expectations. A good model is like a vending machine: predictable. Insert coin, get snack. No surprises like a modal asking "Are you sure?" for the fifth time.

The article breaks down three main approaches: command-based (like the good old terminal), dialog-based (system confirms like a worried parent: "You really want to delete this file?"), and manipulative (drag-and-drop, pinch-to-zoom — all the goodies). Each shines in its own context, but mix them mindlessly, and you'll be explaining to the client why users bounce after 3 seconds.

Props to the authors for covering anti-patterns. For instance, when the system goes silent after an action (a sad loading spinner with no progress) — it's like shouting into the void. Or when the model changes without warning: yesterday swipe deleted, today it archives. You'd need a JIRA board with 47 columns to keep track.

METABYTE studio comment: Interaction models are the secret sauce that turns raw code into a product users don't want to smash. In our projects, we always start with scenario prototyping to avoid rewriting logic after the first user test. And yes, we sometimes confuse swipes too — but we admit it in stand-ups.