Problems You Recognise

Enterprise AI products in regulated industries can stall during sales evaluation when the product interface cannot show how AI-influenced decisions are traced, configured, explained, audited, and kept under accountable human control. The documented Callsign case shows this pattern in financial services, where governance capability became visible through policy architecture, audit trails, and domain-readable configuration.

Human control is weak in practice when AI systems provide formal intervention mechanisms but fail to provide the interface conditions that make those mechanisms usable for informed judgement, domain reasoning, and audit evidence.

This situation describes a gap between model performance and product behaviour. It occurs when teams have training data, evaluation metrics, and benchmark results, but have not specified what AI outputs should surface, how confidence should be communicated, or where human override belongs in the workflow.

This situation describes the gap between model capability and product behaviour in AI-enabled products. The documented pattern appears as capability invisibility, a configuration-behaviour gap, or accessibility failure, with Owkin K, Callsign, and Hudex used as grounded cases.

This situation describes AI-enabled products that perform well on average but behave inconsistently across scenarios. The inconsistency often comes from absent behavioural requirements, invisible context sensitivity, unmanaged edge cases, uniform confidence presentation, or uncommunicated behavioural drift.

This situation describes a failure pattern in AI-enabled products: model outputs vary in confidence, but the interface presents them with uniform apparent authority. At decision points, this forces users either to verify everything or to trust everything, both of which undermine effective human oversight.

This situation describes AI capability opacity: a trust failure where users avoid or underuse an AI system because they do not understand its capability range, data scope, or useful starting queries. The page distinguishes this from accuracy-based skepticism and confidence miscalibration, and uses Owkin K as a grounded example of making specialist AI capability visible at entry.

Users trust the AI too much when AI product interfaces make acceptance of AI output feel more warranted, safer, or easier than the evidence supports. In Creative Navy's documentation, this situation concerns automation bias and the design conditions that produce over-reliance on AI recommendations.

This page describes a specific operational failure pattern: a product appears usable under median conditions but degrades or breaks when real use involves high load, environmental stress, simultaneous faults, or exception-heavy workflows. The page distinguishes this pattern from broader demo-to-real-use gaps and from general expert-workflow friction, then grounds the pattern in petrol station, maritime HMI, Cox Marine, and Triopsis examples.

This situation describes expert software whose domain logic and technical capability are genuine, but whose interface fails under real operating conditions such as movement, interruption, degraded visibility, gloves, non-linear task switching, and time pressure.

This situation describes how a single interface can accumulate friction when it is built around one role's mental model and then extended for others. Creative Navy's Critical Systems Design method classifies the problem as either a unified-model issue or an architectural-separation issue by examining observed workarounds and task structures.

This situation describes interfaces that appear usable because experienced operators compensate for inconsistent layout, mode behaviour, or state presentation through memory. The failure becomes visible when new users, unfamiliar modes, abnormal conditions, or time pressure remove the capacity needed for active search.

This situation describes products whose interfaces reflect internal architecture, specialist abstractions, or ideal test conditions instead of the operational reality of intended users. The source examples show the pattern in analytics, intelligence analysis, AI biomedical research, and smart home control.

This situation describes interfaces where multiple subsystem readings are technically visible but not integrated into a single readable picture of current system state. The documented examples are Torqeedo hybrid vessel control and Cox Marine multi-engine vessel displays.

This situation describes the performance gap between controlled product demonstrations and unsupervised operational use. It explains the structural causes, commercial cost, organisational cost, and documented examples from Polymatica, Pixelart Fugo, and Squaremind.

Design debt is a delivery-and-execution situation where shipped design decisions that were once adequate now impose operational costs. The costs appear through training overhead, recurring support questions, user error at scale, workaround infrastructure, and development friction.

Design does not survive development when implementation diverges from design intent, or when a technically correct implementation fails to produce the intended operational outcome. Creative Navy describes three structural expressions: velocity erosion, translation loss, and the production gap.

This situation describes interface difficulty that is real but not located in a single describable event. Creative Navy's documentation frames the issue as an accumulated interaction of small workflow frictions that self-report methods can confirm but usually cannot explain.

Previous agency delivered surfaces not clarity describes a redesign pattern in which polished screens, component libraries, typography, colour systems, and high-fidelity mockups are delivered without resolving the structural problems that determine operational performance. Evidence from documented cases shows repeated redesigns, unused deliverables, demo-to-use gaps, unresolved warning architecture, and measurable improvements only after structural redesign.

This situation describes product decision-making that continues without causal, operational evidence. The documented mechanisms are absence of research, symptom evidence without causal grounding, and research findings that exist but do not answer the decisions the product team must make.

Stakeholder misalignment occurs when product stakeholders hold different, locally coherent models of users, priorities, or direction and the organisation lacks shared evidence to resolve the disagreement. Creative Navy's Critical Systems Design method addresses this by moving abstract disputes into observable design consequences through evidence, prototypes, sequencing logic, and transferred design reasoning.

This situation describes teams that can prioritise features but cannot prioritise UX work with the same rational structure. The problem appears when UX decisions are sequenced by urgency, release pressure, or stakeholder concern instead of explicit dependency mapping and operational evidence.

A team is shipping without a clear behaviour model when delivery continues without a governing specification for product behaviour. The product may grow feature by feature while actions, states, data presentation, AI behaviour, and workflow entry points become difficult to explain as a coherent whole.

This situation describes products that appear valuable in demos or commercial discussions but are treated as hard to adopt in practice. The documented pattern is not limited to weak products: capable products can fail commercially when the path to first value, migration, habit formation, or buyer confidence is not made operationally viable.

This situation describes the gap between valuable domain expertise and a product that can be understood, evaluated, built, funded, or used without the domain expert present. Creative Navy's Critical Systems Design method addresses the gap through domain learning, architecture reasoning, and prototype artefacts that make the product model explicit.

Legacy systems can block product roadmaps when teams inherit interface, workflow, and architecture decisions without access to the reasoning behind them. Creative Navy's Critical Systems Design method addresses this by treating the legacy system as encoded operational knowledge, then distinguishing decisions that should be preserved from decisions that can be changed.

This situation describes product growth where each deliberate capability addition increases navigational and interaction complexity because the product lacks an architecture for absorbing new domains. The source examples show Chemical Watch using a competitive vector to unify four new capability areas, and OLX using a marketplace coherence framework to govern multi-market variation.

This situation describes products that work for specialist users but cannot reach a broader, different, or geographically distributed user population because the interface assumes domain knowledge that those target users do not have. Creative Navy distinguishes this from high training burden by asking whether free, instantaneous, unlimited training would solve the scale problem; if not, the interface has become the scaling ceiling.

Product fragmentation under growth describes the structural inconsistency that accumulates when features, flows, market adaptations, and modules are added without a shared architecture for what must remain consistent and what may vary.

This situation describes products that are technically stronger than competitors but weaker at communicating their capability during evaluation. Creative Navy's Critical Systems Design method addresses this through a competitive vector that makes the product's genuine advantage legible without reducing the depth that makes it valuable.

A product is hard to sell when the interface cannot carry the product's value to the evaluation moment. Sales teams then compensate with mediated demos, narrative workarounds, or specialist explanations, which constrains sales velocity and makes the sales motion harder to scale.

A product can contain many useful capabilities and still fail at first encounter if the interface gives those capabilities equal weight, asks for configuration before value, or showcases features according to the team's internal view rather than the user's immediate needs.

This situation describes products whose growth is limited by the need to train every new user, customer, geography, or organisational unit. The documented pattern is that high training burden often indicates an interface that does not communicate enough of its own logic for untrained users to proceed.

Delayed understanding creates risk when information is present but structured in a way that requires interpretive work the operating context does not allow. The pattern appears as immediate temporal pressure, where the operator needs current state understanding at the moment of action, and as deferred error discovery, where a misread or incorrectly configured state becomes visible only after downstream consequences have started to form.

Handoffs create failures when a system does not preserve the context needed by the receiving party at the moment work, information, or responsibility changes hands. The situation is visible through escalation, workarounds, and repeated reliance on parallel communication channels.

This situation describes a policy-to-workflow gap in regulated, high-consequence, and institutionally governed contexts. Oversight requirements may exist in governance frameworks, regulatory standards, and institutional procedures, while the interface used for the work fails to enforce or support the required verification.

Interfaces can perform acceptably under typical usability conditions while imposing unsafe or inefficient cognitive load under real operational pressure. The pattern appears when environmental degradation, attentional division, and task urgency make interpretation harder at the moment the interface must be easiest to use.

A system supports procedure but not judgment when it guides known sequences for standard cases while leaving non-standard cases without contextual information, state visibility, or structured decision support. The documented examples span simulation, scheduling, clinical research, surgical devices, fraud detection, and consumer finance.

This situation describes software contexts where user error is not merely a source of friction. In medical devices, industrial safety engineering, and high-throughput operational systems, interface failure can create use-related risk, unreliable safety assessments, financial discrepancy, supervisor escalation, or stress at operational volume.

This situation describes complex operational systems where error prevention is not enough because the interface does not support clean recovery after an error is detected. The page defines recovery path, clean recovery, corrective load, actionable error communication, and escalation as a signal of recovery design failure, with case evidence from Gexcon, Triopsis, Kardion, Beissbarth, and Squaremind.

This situation describes warning systems that are present in the interface but fail under real operating conditions because the warning format, timing, urgency hierarchy, or screen architecture does not support correct action.