> One of the most common UX mistakes is designing UI around the underlying data model instead of user goals.

It's far worse to give users a false mental model of the system. If the underlying system is complex, but that's out of your control, then it will create confusion and frustration in users to paper over it. Please don't do this!

That is, unless you can create a nearly leak-free abstraction. The example given in the article is anything but leak-free.

(This kind of design error reminds me of the skeuomorphism debate nearly a decade ago. Though I do miss beautifully detailed app icons and overall whimsy, in-app false affordances and leaky abstractions both give users an incorrect mental model of the system.)

Especially, don't do this for interactions that aren't core to your business. Under the real world constraints where I work, this kind of design thinking causes non-core features to explode in complexity, cost, etc.

Spend your complexity where it has an impact!

If you have control of your data model, design its structure and endpoints around user goals. Then expose that layer as directly as possible in the UI.

That's probably a half-decent summary of domain-driven design.

hard agree. the issue here is that it tries to implement user goals but based on something other than asking the user and then respecting their choice. that becomes guessing at the user's goal, never confirming, and then acting on that goal anyway. the end result is that i as the user am presented with options and there's no map between what option i pick and what the behavior of the app actually is.