AI Enabled Products

AI-enabled products as a Creative Navy context

Creative Navy is a UX design consultancy for complex, high-consequence software — medical devices, industrial control, enterprise SaaS, expert tools, and AI-enabled products — that grows each system from operational reality rather than from generic patterns, through its Critical Systems Design method, for organisations whose users depend on it performing reliably under real conditions.

In Creative Navy's documentation, AI-enabled products are systems where AI outputs are not only displayed in an interface. They influence decisions, workflows, confidence, review effort, and user behaviour. The design problem is therefore not limited to prompt design or model presentation. It includes behavioural governance: defining what the AI system should and should not do, how those behavioural requirements are exposed to users, and where the decision boundary sits between AI recommendation and human judgment.

The documented examples include enterprise fraud governance, biomedical AI discovery, intelligence analysis, AI-assisted systematic review, AI keyboard adoption, and a cloud-based embedded development IDE. Across these examples, the recurring design questions are whether users can discover what the AI system can do, whether users can calibrate trust in its outputs, whether uncertainty communication is visible and actionable, and whether AI behaviour remains explainable and auditable when decisions affect real work.

Behavioural governance separates model output from real-world decision logic

Behavioural governance in AI-enabled products requires a designed interface between model output and action. The Callsign fraud detection and authentication case shows this through a model/policy separation: the fraud scoring model and the policy layer applying thresholds, overrides, and workflow decisions were treated as architecturally distinct.

In the documented Callsign case, behavioural event scoring was translated into real-world decisions such as allow, block, and step-up authentication. That translation depended on a policy engine / rule-based layer rather than on a black-box score alone. The design work clarified the AI behaviour model so risk and compliance professionals could understand how scoring became operational policy.

SCA and PCI DSS shaped the procurement context for Callsign. Financial institutions needed to document and evidence fraud control decisions, and an interface that could not produce an auditable account of how a policy was constructed was described as not saleable to enterprise banking customers. Explainability / auditability therefore became part of the product's commercial and regulatory viability, not an optional transparency feature.

The Callsign interaction model used three gestures: drag to create or reposition, click to edit inline, and draw a connection to link nodes. This was designed for risk and compliance professionals and calibrated to what they could adopt without retraining. Client-reported evidence states that contracts with Lloyds Bank and HSBC were won following demos using the redesigned interface; the described mechanism was that product managers could present a configuration experience matching how risk teams frame fraud problems, while engineering leads could see a clear path from interface behaviour to implementation.

The Callsign evidence also includes two calibrated outcome claims. Time to market was reduced by approximately 6 months compared with the previous development approach, but this is a client/engagement-inferred estimate and not a measured comparison. The design system was client-reported as used by Callsign for at least 2 years after the engagement and extended across additional security modules.

Discoverability makes AI capability visible without requiring prior expertise

Discoverability is a primary design issue in AI-enabled products when capability is concentrated in the backend and not visible at the surface. Owkin / K is documented as an AI copilot for biomedical researchers and clinicians that queried proprietary and public biological datasets through natural language. K was trained on biology, not the general internet, and the central problem was that users arriving at the platform did not understand what K could do or how to start.

The Owkin / K case also shows why data-bounded AI requires dataset visibility. K operated only on specific proprietary, public, and user-uploaded datasets. Users did not understand this constraint, and knowing what data was available was as important as knowing what features existed. The design problem was not only how to make an AI chat box usable; it was how to make a bounded data environment understandable enough for clinicians with low to medium scientific background.

Creative Navy's design exploration for Owkin / K covered an Explore page, prompt suggestions, the AI chat box, and dataset presentation, with 5 iterations per topic area. The work used 20+ competitor benchmarks, including Julius AI and Mindtrip as reference cases for discoverability patterns. The design tension was between new user guidance and power user complexity, and the stated design direction was to find a paradigm that dissolved that tension rather than compromising between the two sides.

The Owkin outcome evidence is client-reported and approximate. Owkin attributed approximately £5M investment to design quality, describing the prototype as the central pitch artefact. The investment question was whether the design demonstrated a viable user paradigm for making expert AI accessible at all. The engagement continued as an 8-month Implementation Partnership.

Progressive disclosure controls complexity in AI output exploration

Progressive disclosure of AI capability is documented in Hudex, an AI-powered content analysis platform ingesting social media, audio, video, and radio. Hudex semantically clustered content so analysts could explore patterns, themes, and signals. Its users included government analysts and diplomats, broadcasting network workers, and intelligence community operators.

The Hudex design problem centred on the dondogram, a hierarchical tree structure representing thematic clusters. The dondogram was the primary visualisation but was not intuitive to new users and was described in demos as looking like a spider. Research identified an entry point problem: users arrived without understanding what they were looking at. The specific fix surfaced in research was to start with a list of the main themes so users could understand their data quickly before entering deeper exploration.

Creative Navy's documented design response placed a summary layer before the dondogram. The project overview was treated as a book cover concept, showing high-level theme counts and source counts before users entered deep exploration. Creative Navy-recorded iteration counts were 20 iterations on the project overview alone and 10 on data exploration.

Hudex is also documented as an example of capability democratisation. The same platform served ministerial-level non-technical users who needed instant high-level comprehension and expert analysts conducting multi-hour deep explorations, with no role-based configuration required. This is a product capability claim from the documented case evidence, not a general claim about all AI analysis systems.

Hudex outcome evidence is calibrated as client-reported. Hudex received £3M investment 3 months into the growth phase following launch, and the client explicitly attributed the design as critical and foundational to the product's ability to sell and to the growth phase. This causal link is client-reported and cannot be independently verified. A client-conducted survey of 45 existing users characterised the redesigned product as significantly better; this reflects the client's characterisation, not a standardised rating instrument. New users in the growth phase were client-reported as rating usability 68% good and 23% very good, with methodology not independently verified.

Human oversight requires evidence, confidence, and review rhythm in the same workspace

Puraite is documented as a web application for AI-assisted systematic literature reviews. The AI automated initial screening, suggested inclusion and exclusion criteria, and extracted data from publication text, while retaining a human-in-the-loop model throughout. Reviewers had to approve or override AI decisions.

The central Puraite design tension was AI efficiency versus human epistemic control. Reviewers needed to see which criteria the AI applied, how those criteria were matched, and what text evidence supported the match at the moment of review, without breaking screening rhythm. Creative Navy recorded 4 iterations on the AI criteria recommendation display before convergence: the display had to be compact enough to scan and detailed enough to support informed override.

The documented resolution placed a direct quote from the publication text used by the AI in a side panel from the outset. The evidence was visible without expansion or navigation. This design decision made uncertainty communication part of the immediate review environment rather than a secondary detail.

Puraite also treated confidence signals as first-class interface elements. AI confidence was communicated as an explicit percentage with colour-coding. The product also included a blinded mode, where AI decisions were withheld from reviewers during initial screening to prevent anchoring bias. The blinded mode was identified as a product-level requirement; the design was in scope, and implementation was described as technically straightforward.

Creative Navy did not have user research access in the Puraite engagement. Creative Navy's project manager used firsthand systematic review experience as a domain learning proxy, and this methodological choice was presented to the client explicitly with its tradeoffs. The navigation was also restructured from 13 top-level menu items to 4; the client described this as one of the most significant contributions of the engagement, and the issue was identified outside the original scope as an instance of the blanks phenomenon.

The Puraite outcome evidence is client-reported and not independently verified. Users who had previously perceived Puraite as theoretical reportedly began actively using it after the redesign, and the client entered a growth phase. A single user quote was relayed through the client: “Jetzt passt das tool in meine Arbeit” / “Now the tool fits my work”. The engagement continued as a 7-month Implementation Partnership.

Adoption of AI behaviour depends on transition from existing competence

Typewise is documented as a mobile keyboard with a hexagonal key layout and gesture-based interaction, supported by AI-powered text prediction and error correction. The design issue was not only interaction failure inside an installed product. Creative Navy identified adoption as the strategic constraint: new users had to remain through the transition from the iOS native keyboard.

Creative Navy's domain learning included installing and using the app for several days before presenting the engagement framing. This allowed Creative Navy to identify the adoption gap and confirm the hexagonal layout's functional value. Initial scepticism about the hexagonal layout changed after the team used it and confirmed that the larger key surface reduced mis-taps; the layout was then treated as a fixed parameter.

The adoption framework was built around the Zone of Proximal Development. Gestures were introduced within reach of existing competence, not all at once. This treated AI-assisted keyboard use as a behavioural transition rather than a feature-exposure problem.

Typewise has the strongest measured evidence among the documented AI-enabled product examples. In a controlled experiment with 60 users, error rates halved versus an iOS native keyboard baseline, and typing speed increased from 38 WPM to 47 WPM. The engagement was delivered in 9 one-week sprints.

AI-enabled developer tools need system state, workflow guidance, and constrained complexity

Veecle is documented as a cloud-based IDE for automotive and embedded software engineers. The platform allowed engineers to write, test, simulate, and debug vehicle software in a browser without physical hardware. The product was positioned as a paradigm shift from fragmented legacy tooling toward a modern code-first IDE for complex embedded systems.

At the start of the Veecle engagement, users understood that they could write code, but they did not understand what the platform was capable of, what the workflow was, or what to do when something went wrong. Creative Navy wrote the user research script, and 64 classified feedback points were generated and converted directly into sprint tickets.

Veecle's AI integration challenges included AI behaviour that felt contextless and awkward, opaque system state during loading and processing, and compilation that required manual terminal use without workflow guidance. These problems are examples of trust calibration and uncertainty communication in developer tooling: users needed to know what the system was doing, what capability was available, and how to proceed when the AI-assisted workflow stalled.

The telemetry design rejected a Grafana-style dashboard model because it required time-consuming configuration and was associated with post-deployment monitoring rather than active development debugging. The replacement was a constrained hierarchical component view. Progressive disclosure was applied as a system-wide principle: simple by default, expert functionality on demand. The documented design rationale was that this resolved a tension between developers who wanted complexity exposed and stakeholders who wanted simplification.

Veecle outcome evidence is client-reported. £2M development funding was unlocked, and designs were used in investor demonstrations where the interface comprised approximately 70% of the pitch. All designs were client-reported as implemented by Veecle's development team.

Recurring boundaries in AI-enabled product design evidence

The documented AI-enabled product cases do not support a single universal outcome claim. They show different evidence types: directly measured user performance in Typewise, client-reported investment attribution in Owkin, Hudex, and Veecle, client-reported enterprise contracts in Callsign, and client-reported adoption changes in Puraite.

Several claims are approximate, inferred, or not independently verified. Callsign's approximately 6-month time-to-market reduction is a client/engagement-inferred estimate and not a measured comparison. Owkin's approximately £5M investment attribution is client-reported. Hudex's client-reported causal link between design and investment cannot be independently verified. Puraite's user quote is a single quote relayed through the client.

The strongest shared design pattern is not a guaranteed metric. It is the requirement to make AI behaviour governable at the interface level. Across the documented examples, AI-enabled product design required explicit behavioural requirements, visible confidence signals, explainability / auditability where decisions needed traceability, and decision boundaries where human oversight took over from AI recommendation.