Conceptual integrity means covering all functionality with as few consistent concepts as possible

What it is

Conceptual integrity means the product explains all functionality through one small, stable, mutually consistent set of objects, states, actions, and rules. After users learn “project—task—owner—submit—review,” they should not learn a near-synonymous scheme on each page. Integrity concerns coverage and coherence, not the number of features.

Why it happens

Few concepts let users build a composable mental model. Objects indicate possible actions, states indicate next steps, actions indicate results, and rules indicate exceptions; when a new feature maps to existing concepts, it reuses established predictions. More concepts force users to maintain a mapping table: which list equals which record, which button is synonymous with which, and which state affects which permission. When concept boundaries are unclear, the system looks flexible but transfers combinatorial burden to users.

Studying it

Inventory all user-visible concepts and classify them as objects, states, actions, permissions, and feedback; count synonymous concepts, undefined terms, exception rules, and combinations. Card sorting can ask users to group and name concepts; feature-mapping tasks can test whether each function is explainable by existing concepts. Then measure novice explanation agreement, misclassification, and training time.

Where it stops holding

Fewest concepts does not mean fewest features, nor should complex business be flattened artificially. Professional domains may require precise distinctions; merging concepts that preserve safety, legal, or computational boundaries sacrifices correctness for simplicity. Integrity is also not visual uniformity: attractive styling cannot cover conflicting concepts.

Applying it

• Draw the concept model: core objects, life-cycle states, allowed actions, responsible roles, and failure states.
• Map every new requirement to an existing concept; when a new concept is truly needed, define it, mark its boundaries, relate it to existing objects, and plan migration.
• When deleting or merging synonyms, update the interface, help, API names, and logs together, avoiding one concept model for users and another for the system.
• Review requirements with “which object and state does this belong to?” If there is no answer, repair the model first.

Related

• Same group: B2.25.1 Interface structure should match task structure, not organizational or technical implementation structure · B2.25.3 Adding a new concept costs more learning than adding a function under an existing concept · B2.25.4 Independent design by multiple people without a shared concept model necessarily creates conceptual redundancy and near-equivalent controls
• Nearby: B2.23 Internal Consistency · B2.10 Consistency
• Search terms: conceptual integrity · concept model · domain modeling