Skip to content

title: Mental-model preference coherence type: concept created: 2026-04-24 updated: 2026-04-24 tags: [ux, preferences, mental-model, user-experience, product-engineering, coherence, predictability, settings] sources: [2026-03-19-slack-how-slack-rebuilt-notifications] related: concepts/preference-schema-decoupling, concepts/support-burden-as-architecture-signal, concepts/explicit-state-over-implicit-sync, systems/slack-notifications-2-0

Mental-model preference coherence

Mental-model preference coherence is the architectural discipline of designing preference schemas so that the storage model matches the user's internal model of what the system should do. When coherent, setting X reliably does Y; when incoherent, users must learn the system's hidden derivation rules to predict outcomes.

Canonical framing from the 2026-03-19 How Slack Rebuilt Notifications post: "The architecture now matches users' mental models, making behavior predictable." Slack is explicitly framing the preference schema itself as architecture — and the mental-model mismatch as an architectural defect, not a UX polish issue.

Three symptoms of incoherence

  1. Unpredictable setting effects. Users change a setting and can't predict what will happen. Slack's legacy state: "Users couldn't predict what would happen when they changed a setting." The diagnostic test: if a user has to try a setting to see what it does, the schema is incoherent.
  2. Hidden semantics across options with identical labels. Slack's pre-rebuild state had 'desktop': 'nothing' and 'mobile': 'nothing' meaning structurally different things. "A 'nothing' setting on mobile meant something entirely different from 'Off' on desktop." When the same label denotes different behaviour, the model is incoherent.
  3. Sustained support burden. If a feature generates disproportionate CX tickets for years, the fix is usually structural schema work, not better copy or better help docs. See concepts/support-burden-as-architecture-signal.

Coherence as decomposition into orthogonal concepts

Coherent preference schemas decompose into concepts the user already holds in their head. For Slack notifications, the user's mental model has two orthogonal dimensions:

  • "What should I be aware of?" (content)
  • "How should the system interrupt me?" (delivery)

The legacy schema conflated these into a single enum; the user had no way to express "aware but not interrupted" (the desire for all-activity + no-push). The rebuilt schema splits them into two axes, and user mental model → schema axes → storage columns is now a 1:1 mapping.

Incoherence typology

Four recurring failure modes:

  • Conflated axes — one enum for multiple concerns; see concepts/preference-schema-decoupling.
  • Hidden coupling — changing X secretly also changes Y. Slack's legacy: picking "nothing" for desktop push also silently disabled desktop in-app badges.
  • Implicit derivation rules — the effective setting is a function of stored state + some rule the user doesn't know. Slack's legacy sync parameter; concepts/explicit-state-over-implicit-sync is the companion discipline.
  • Discovery by defect — power-user controls scattered across menus with no clear hierarchy. Slack legacy: "Features like 'badge all unreads' on mobile were hidden, and there was no unified place to understand all your notification options."

Coherence dividend

The rebuild's post-launch metrics (canonical verbatim):

  • "Settings engagement increased 5×" sustained for weeks.
  • "Push notification toggles led to higher usage, with users immediately discovering the decoupled desktop/mobile controls."
  • "Better defaults meant fewer workarounds — the percentage of users needing per-channel overrides decreased."
  • "Support burden decreased significantly."

Collectively these describe a system where users find the settings they want, make changes that match their intent, and don't file tickets about it. That's what coherence buys.

Relationship to product-engineering altitude

This is one of several wiki concepts that sit at the product-engineering altitude — where user-facing design choices are architectural decisions with downstream systems-engineering consequences. The others:

Caveat: coherence is model-dependent

User mental models differ across user segments. Slack's post implicitly assumes a knowledge-worker-power-user model where the two-axis decomposition (content × channel) matches intuition. A less-sophisticated user base might prefer a further simplification to a single enum; a more sophisticated base might want more axes (per-channel, per-keyword, per-time-window, etc.). Coherence is not a universal optimum — it's alignment with the target user's mental model. The right segmentation is an empirical question answered by user research + support- ticket pattern analysis.

Seen in

  • systems/slack-notifications-2-0 — canonical instance. Storage schema (desktop, desktop_push_ enabled, mobile) aligned with user mental model (content × channel × per-platform).
Last updated · 470 distilled / 1,213 read