Domain Expertise Cannot Become A Product

Summary of the domain expertise to product gap

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.

Domain expertise cannot become a product by itself when the expertise has not been structured into a product model. A researcher may understand workplace safety incident patterns, a studio may have built a novel embedded development paradigm, a clinician may understand a clinical workflow, or an operations provider may run a complex service better than competitors. That knowledge can be valuable, technically sound, and commercially relevant without being navigable as software.

A product requires entities and relationships: the objects users act on and the rules that govern how those objects relate. A product also requires user journeys, scope decisions, and a model of how users move through the system. The product model must be understandable to designers, engineers, investors, buyers, and early users without the domain expert present to interpret it.

Without product structure, domain expertise usually becomes one of three artefacts: a document that articulates knowledge but cannot be navigated as a product, a demo that works only with expert narration, or a beta product that confuses users because the interface reflects domain understanding without a product model.

The product gap is structural rather than a documentation problem

The gap between domain knowledge and product is structural. More documentation can describe what the domain contains, but documentation does not establish which entities users act on, which actions must happen first, which scope belongs in the first version, or which parts can wait.

A product model answers use questions rather than content questions. It must describe who encounters the product, under what conditions, with what prior knowledge, and what the user is trying to accomplish. That reasoning is design reasoning, even when it is grounded in expert domain knowledge.

Experts who attempt to build product models from domain knowledge alone can over-scope, under-structure, or under-communicate. Over-scoping includes everything the domain contains because everything is relevant. Under-structuring produces flat inventories of features instead of architectures with primary and secondary paths. Under-communicating produces models that other experts can read but that investors, buyers, developers, or early users cannot evaluate.

Bridging domain expertise into product structure requires three linked steps

Creative Navy's Critical Systems Design method addresses this situation through three linked steps: domain learning, architecture reasoning, and prototype artefacts. The sequence matters because each step makes a different part of the product model explicit.

Domain learning extracts product structure from expert knowledge

Domain learning is the process of extracting the implicit product structure inside expert knowledge. In this situation, domain learning is not limited to interviewing the expert or reading existing documentation. It identifies the entities, relationships, information dependencies, and domain categories that the product must preserve.

The output is a conceptual model that is explicit, structured, and validatable. That conceptual model becomes the foundation for architecture and interaction decisions because it shows what the product must encode before design work can decide how users will move through it.

Architecture reasoning makes the product navigable

Creative Navy's Critical Systems Design method uses architecture reasoning to turn the conceptual model into navigable product structure. This includes deciding which objects are primary, how users navigate between them, what the entry path looks like for a non-expert, and what belongs in the first version.

In this situation, Concept Convergence is applied to a product that does not yet exist. The work uses option space mapping across competing architectures, tension-driven reasoning through trade-offs, and convergence on a structure that satisfies both domain requirements and product navigation requirements.

Prototype artefacts make the product model evaluable

A conceptual model and architecture document are not sufficient for an investor meeting, procurement evaluation, or early user session. The product model must be expressed as an artefact that can be evaluated visually and interactively without the domain expert narrating every screen.

In this situation, the prototype is not presented as a polished product. It is the structured communication of a product model that has not yet been built. Its function is to make the architecture legible to external audiences under demo, evaluation, or early validation conditions.

Greenlight translated doctoral research into a navigable workplace safety product model

Greenlight began with Samantha Gruskin's completed doctoral thesis on how workplace safety incidents are recorded, escalated, and followed up in real organisations. The research was thorough, peer-reviewed, and grounded in observed practice. It described the domain with precision, but it did not specify what the software should contain, how it should be organised, or what a first-time user would encounter.

Creative Navy's Critical Systems Design method applied domain learning to the thesis corpus before product decisions were made. Creative Navy read the main chapters, extracted incident categories, severity scales, near-miss classifications, escalation dependencies, and follow-up action structures, then validated the synthesis in working sessions with Gruskin until the conceptual model was stable.

The Greenlight conceptual model defined entities, relationships, and the sequence in which information must exist before other actions can be taken. That product-ready model became the foundation for subsequent design work.

Creative Navy explored three information architecture concepts through Sandbox Experiments: a linear flow, a modular architecture with context-sensitive conditional sections, and intermediate variants. Each concept was evaluated against minor incidents, serious injuries, and near-miss reports. The modular architecture was selected because it could accommodate conditional structure without requiring users to navigate sections that did not apply to their incident type.

Iterative System Building produced three successive wireframe versions over two weeks. The first version focused on the core reporting journey. The second added incident type variations and list and detail views. The third refined wording, field groupings, and action order. A round of testing with users who regularly handle workplace incidents confirmed the architecture and identified refinements: reordering sections reduced hesitation at form length transitions, grouping evidence attachments with contextual details reduced backtracking, and simplified branching rules improved comprehension of conditional fields.

Greenlight deliverables included documented information architecture, an interactive prototype, two UI directions for branding exploration, and a build sequencing roadmap. The work was produced in approximately five weeks. The evidence basis is Creative Navy-observed. No deployed system exists, and no operational user performance data is available for Greenlight.

Veecle translated a working embedded development paradigm into a communicable product model

Veecle was building a cloud-based IDE for automotive and embedded software engineers. The browser-based environment let developers write, test, simulate, and debug vehicle software without physical hardware, with tools, licences, and dependencies pre-configured.

Veecle had a working technology and approximately ten beta users. The product model was still difficult for users and investors to understand without extensive narration. Beta users knew they could write code, but they did not understand the intended workflow, what to do when something went wrong, or the platform's intended scope as a replacement for an entire local development setup rather than another tool added to an existing one.

Creative Navy's Critical Systems Design method addressed this through domain learning into the embedded development paradigm, including automotive telemetry behaviour, async log structures, and the code → simulate → debug workflow. Creative Navy then explored four primary UX topics: the onboarding flow, the telemetry screen, workspace creation, and AI integration.

The Veecle work included four concept directions for onboarding, three layout iterations for the telemetry screen, three full-flow iterations for workspace creation, and two directions for AI integration. The central design tension was between developer preferences for technical control and new users' need for orientation. Creative Navy resolved that tension through progressive disclosure as a system-wide principle: simple by default, with expert functionality available on demand rather than imposed on entry.

The resulting design system included an onboarding flow, telemetry screen, workspace creation logic, AI optimisation screen, and full UI starter kit. The interface communicated Veecle's product paradigm visually and interactively without requiring Veecle to narrate it. Veecle reported that the interface comprised approximately 70% of investor pitch content and that the engagement unlocked £2M in development funding. The funding claim is client-reported, with direct causal attribution stated by the client, and no independent verification of the funding figure is available.

IMServ translated operational energy data capability into a procurement prototype

IMServ is a UK energy data services company that collects, processes, and presents energy usage data for large B2B portfolios. At the time of the engagement, IMServ was appointed across more than 24,000 meter points for a single supplier's portfolio. IMServ had operational capability in fault detection, multi-stage resolution, and settlement data processing across thousands of meters, but did not have a product through which a supplier could see that capability working.

IMServ's context differed from Greenlight and Veecle because the audience was a commercial buyer in a competitive tender rather than an investment audience. The energy supplier SSE would evaluate the concept through people who understood energy settlement deeply. The product model therefore had to be credible to domain experts at the tender demo date.

The starting material was not a product specification. It was a dense set of first-person operational anxieties from the buyer's perspective, expressed through more than fifteen “I need to…” statements. The statements covered trust in the agent, proactive prompting before issues occur, unambiguous ownership of every blockage, and cost-to-serve. Creative Navy's documentation describes this as the blanks phenomenon at structural level: a verbal description plus an unstructured anxiety dump, not a specification.

Creative Navy's Critical Systems Design method applied domain learning at speed across UK energy settlement, MHHS, settlement runs, MPAN-level fault resolution, and the multi-party structure of data collection. The resulting product model organised the portal around a five-stage meter journey: agent appointed → meter installed → meter health → data retrieval → settlement processing. Each blockage was attributed to an owner across a six-party set.

The meter journey backbone was grounded in IMServ's operational practice rather than Creative Navy field observation. The owner-attribution concept was Creative Navy's proposal, with the specific mapping optimised by IMServ.

Creative Navy expressed the IMServ product model as a thirteen-screen clickable prototype produced in a one-week build sprint. The prototype was navigable in the pitch without narration. IMServ won the tender, then created an internal design team to build the real product. Creative Navy supported that team over a roughly seven-month Implementation Partnership toward independent operation.

The IMServ tender win and Peter McFord statement are client-reported. McFord said the engagement left IMServ with a solid foundation to build the product itself. There are no measured user outcomes because the prototype was built for buyers and was not tested with users. The prototype's assistant was a help/chat assistant, not an AI feature, so the IMServ case is not an AI-product engagement.

This situation differs from a deployed product that cannot scale without specialist onboarding

This situation concerns the prior condition before a navigable product model exists. The challenge is establishing the product model in the first place, not redesigning an existing product to remove access barriers.

The related scaling-ceiling situation concerns products that already exist and are deployed but cannot reach the user population they need because the interface requires specialist knowledge as a prerequisite. In that situation, the product model exists but non-experts cannot navigate it.

Both situations involve translating specialist knowledge into something non-specialists can use. The difference is what exists at the start: a deployed product with a scaling problem, or a domain of expertise that has not yet been structured as a product.

Evidence boundaries for this situation

The evidence in this situation is case-based and should not be read as a universal outcome claim. Greenlight evidence is Creative Navy-observed from a pre-product engagement; no deployed system or operational user performance data is available.

Veecle's reported £2M development funding outcome is client-reported and not independently verified. The client directly attributed the funding unlock to the engagement, but no independent verification of the funding figure is available.

IMServ's tender win and Peter McFord statement are client-reported. The IMServ prototype was built for buyers and was not tested with users, so there are no measured user outcomes from that prototype.