Independent design by multiple people without a shared concept model necessarily creates conceptual redundancy and near-equivalent controls

What it is

When adjacent problems are solved simultaneously without shared object, state, and action models, each team invents local language: card, panel, drawer, and dialog all perform the same edit; task, ticket, item, and activity point to the same to-do. Conceptual integrity requires the model to act as a collaboration contract, not rely on later visual cleanup.

Why it happens

Locally reasonable decisions lack a shared naming boundary. One team calls the recipient “owner,” another “receiver,” and a third introduces “collaborator”; each word works on its page, but users must judge whether permissions and results are identical. Near-equivalent controls also fork data, duplicate states, and diverge in validation. Shared components can unify appearance, but if underlying concepts differ, they only hide redundancy inside one style system.

Where it stops holding

A unified model is not one-person authority or a ban on team autonomy. Domains may keep domain-specific subconcepts if they declare how they map to core objects and states; urgent fixes can ship a local solution and register migration afterward. If a product serves several non-overlapping professional groups, deliberately retaining separate modes may be clearer than forced merging.

Applying it

• Maintain a public concept model at project start: objects, life cycles, roles, actions, permissions, and banned synonyms.
• Add a concept check to interface review: which object does this entry belong to? Is there already a control for this action? What is the difference?
• Implement core objects as shared components and data types, and let interface copy read the vocabulary so visual unity does not mask semantic forks.
• Each release cycle, audit new entries, synonyms, duplicate lists, and state names, assigning an owner and deadline for merging.

Related

• Same group: B2.25.1 Interface structure should match task structure, not organizational or technical implementation structure · B2.25.2 Conceptual integrity means covering all functionality with as few consistent concepts as possible · B2.25.3 Adding a new concept costs more learning than adding a function under an existing concept
• Nearby: B2.23 Internal Consistency · R1 Design Systems
• Search terms: collaborative design · concept drift · duplicate controls