Domain Learning

Definition of domain learning

Domain learning is the phase in which the design team becomes productive users of the systems being redesigned. The team studies manuals, performs tasks, observes workflows, shadows professionals, and learns the constraints of the work from inside the domain rather than only from outside descriptions.

In Creative Navy's documentation, domain learning is necessary because software cannot be designed for real conditions that the design team has not experienced or understood. Stated needs can contain wrong assumptions. Observed behaviour can reveal the operational reality that users and stakeholders may not fully articulate.

Domain learning often takes longer than clients expect. The stated reason is the blanks phenomenon: clients may understand their domain deeply but still have gaps in what they can explain, formalise, or recognise as design-relevant.

What domain learning involves in practice

Domain learning includes studying manuals, performing tasks as a user, shadowing professionals, observing workflows, and learning how the domain operates from inside the work. In deliverables discussions, this includes users teaching Creative Navy how to use the system and do their job, and Creative Navy trying to do the job as a user.

The purpose is not general familiarity. The purpose is to reach enough operational grounding to understand what the system requires, what users actually do, and which constraints are binding under real use conditions.

Domain learning also discovers context of use. A tool is always embedded in a wider context, and many design opportunities come from integrating the tool more effectively with that context.

What domain learning reveals that other methods may miss

Domain learning reveals silent patterns that users have developed inside the work. These include how users consciously think about the process, how they believe the system should work, how they learned to use it, and how challenges changed as they became more experienced.

Domain learning also reveals emotional weighting. The way users value, fear, ignore, or work around parts of a system can be a design input when it affects attention, trust, effort, or decision-making.

Domain learning can show what users would or would not be capable of if the system were different. This matters because a redesigned system may change not only interface behaviour but also the practical limits of what a user can do in the workflow.

Domain learning and multi-perspective synthesis

Domain learning supports Creative Navy's multi-perspective synthesis by giving the design team enough grounding to interpret a domain from more than one angle. Clients may see their domain deeply, but they usually see it from inside one perspective.

The design team uses domain learning to fill substantive blanks in that perspective. The goal is not to replace client expertise. The goal is to make client expertise usable alongside observations, constraints, user behaviour, technical structure, and other forms of evidence that the client may not see from inside the work.

Immersive domain learning in operational environments

Immersive domain learning is especially important when the operating environment determines whether the interface performs. In physically demanding and operationally complex contexts, findings may not be accessible through interviews, existing documentation, or controlled lab testing.

In the Torqeedo maritime engagement, the programme required 12 sea trials over 6 months with 15 professional captains. The trials covered temperatures from −5°C to +35°C and night operations from late evening to early morning. This work revealed how vibration affects readability at the pixel level, how glare from cold water reduces contrast differently from other light sources, and how scanning patterns in night harbour manoeuvres differ from daytime open-water operation.

The Torqeedo case is described as the most operationally immersive documented example. In that engagement, sea trials were not only a research method choice; they were an operational necessity because the conditions determining interface performance could not be reproduced in another way.

Domain learning in legacy expert software

Domain learning in legacy expert software requires the design team to distinguish genuine operational knowledge from accumulated interface structure that no longer has a clear purpose. A legacy interface may contain essential domain logic, accidental complexity, or both.

In the Gexcon engagement, Creative Navy studied calibration manuals, YouTube tutorials, Gexcon's internal training videos, and ran controlled tests inside the application before any redesign decisions were made. Two four-hour stakeholder sessions allowed the team to reverse-engineer the sequence of scientific operations embedded in the legacy interface.

The depth of this learning was externally confirmed by Franz Zdravistch, Ph.D., Chief Training Engineer at Gexcon, who observed: "I can't believe how much you learned on your own in three days, even some of the experts I train need more time." This is described as the only instance across the documented case studies where a domain expert provided direct third-party validation of the depth of domain learning achieved.

The practical consequence was that Creative Navy could separate essential scientific complexity from accidental complexity accumulated over fifteen years. Without that distinction, the redesign risked either preserving everything and changing nothing, or discarding everything and breaking what worked.

Domain learning in precision embedded hardware contexts

Domain learning in precision embedded hardware extends to the physical operating environment. In the Beissbarth automotive calibration engagement, Creative Navy studied calibration manuals, engineering diagrams, and the sensor logic of the measurement system before research began.

The learning addressed not only what the software did, but what calibration technicians were doing while using it. This included how tolerances are interpreted in real sequences, how borderline values are handled during measurement, and how technicians confirm alignment states while moving around the vehicle.

The physical constraints became design inputs only after the calibration procedure was understood from inside. These constraints included viewing from 2–3 metres while moving, gloves, variable lighting, and reflective surfaces.

Domain learning in marine embedded display design

Domain learning in marine embedded display design can include protocol-level data behaviour as well as physical operating conditions. In the COX Marine cluster display engagement, Creative Navy studied NMEA 2000 protocol behaviour and engine telemetry update rates under varying load states.

The relevant data values changed in frequency and importance depending on operating state. At low speed, the relative importance of rpm, coolant temperature, oil pressure, fuel rate, and trim values differed from their behaviour during high-speed transit or an emergency fault condition. Understanding these data rhythms was a precondition for designing information prioritisation.

The COX Marine engagement also required domain learning about sunlight-readable LCD constraints, military night vision mode requirements, gloved touch interaction under hull vibration and slamming, and operator scanning behaviour during open-water fast transit and close-quarters docking manoeuvres.

This is described as domain learning across three simultaneous levels: the protocol layer, the hardware layer, and the operating environment layer. The COX Marine case is the first documented case where protocol-level data behaviour, not only physical constraints or software architecture, was a domain learning target.

Literature-based domain learning in regulated and high-consequence contexts

Literature-based domain learning operates when relevant domain knowledge is codified in peer-reviewed academic and scientific literature. In regulated and high-consequence contexts, research literature can contain operational findings that observation alone cannot efficiently reproduce, including minimum effective interaction parameters, cognitive load thresholds, and perceptual constraints under specific conditions.

Academic literature domain learning is not background reading. It functions like observational domain learning because it generates constraints that design decisions must respect and is reviewed before design work begins. The difference is the knowledge source, not the function of the learning.

In the Akrivia Health clinical research platform engagement, 32 academic papers on electronic health record interface design and healthcare analytics were reviewed before any screen design began. Eight papers directly informed interface decisions. The reviewed literature documented how clinicians and researchers move between structured clinical data and narrative notes, how electronic health record users lose context during long sessions, and where interface design fails to make query provenance visible.

Those findings became design constraints for visible provenance cues, stable query history, and a persistent view of which patient data was currently in scope. This is domain learning from literature because the design team extracted operational requirements from an established body of interface research evidence.

Human factors literature as operational constraint in medical device design

In the deSoutter Medical / Zethon surgical device interface engagement, 12 human factors studies and ergonomics papers were reviewed before any interaction design decisions were made. The papers covered touch performance with gloved hands, visual search under time pressure, attention switching in dual-task conditions, and medical device usability in clinical environments.

Two papers are directly citable in the documented case evidence. Colle, H. A., & Hiszem, K. J. (2004), "Standing at a kiosk: Effects of key size and spacing on touch screen numeric keypad performance and user preference," Ergonomics, 47(13), 1406–1423, informed minimum effective target sizes and spacing. Tao, D., Yuan, J., Liu, S., & Qu, X. (2018), "Effects of button design characteristics on performance and perceptions of touchscreen use," International Journal of Industrial Ergonomics, 64, 59–68, informed button sizing and feedback timing specifications.

These citations were used as named sources in the requirements catalogue. They were traceable in the IEC 62366-1 documentation to the specific use scenarios and risk considerations they informed. This is described as the most explicit documented instance of peer-reviewed research functioning as operational constraint rather than as inspiration or reference.

Observational and literature-based domain learning address different knowledge types

Observational domain learning and literature-based domain learning address different kinds of knowledge. Observational learning accesses tacit knowledge: patterns, compensations, emotional responses, and contextual adaptations that practitioners may not fully articulate because they have internalised them.

Literature-based learning accesses codified knowledge. It brings in findings from controlled experiments and structured studies on mechanisms that may not be visible to practitioners in their own practice.

In regulated and high-consequence contexts, both forms may be necessary. Literature can provide parametric constraints such as minimum target sizes, maximum cognitive load thresholds, and safe feedback timings. Observation can provide the operational reality that determines which parameters are binding under actual use conditions.

Domain learning as product foundation in emerging product contexts

Domain learning can function as product foundation when no operational system exists to observe. In emerging product contexts, the client may be the domain: a founder, researcher, or practitioner who holds deep expertise that has not yet been structured into a product model.

In this form, domain learning means extracting implicit structure from the client's knowledge corpus. The work can include reading research documentation, identifying entities and relationships, mapping how processes move through stages, and validating the extracted model with the client until it is stable enough to design from.

In the Greenlight engagement, the corpus was a doctoral thesis on workplace safety incident reporting. 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 the founder.

The resulting conceptual model contained entities, relationships, and the sequence in which information had to be captured. It became the foundation for subsequent architecture and interaction design decisions. In this context, the first deliverable was the model itself.

Domain learning in AI-enabled product contexts

Domain learning in AI-enabled product contexts can focus on the internal architecture of a working AI system. The relevant knowledge may not be located in an operating environment, a practitioner workflow, a research literature, or a founder's knowledge corpus. It may be located in how the AI system works internally.

In these contexts, domain learning makes the mechanics of the system explicit: how the model operates, what it produces, what the policy or rules layer does with those outputs, and where the boundary lies between automated decision-making and human-configurable control.

In the Callsign fraud detection and authentication platform engagement, the work opened with workshops involving product, engineering, and security specialists. Creative Navy mapped existing rule structures, fraud scenarios, and points where conflicts or gaps appeared.

The output was a conceptual separation between the fraud detection model, which scores behavioural events, and the policy layer, which applies thresholds, overrides, and workflow decisions to those scores. That separation had not been explicit in the existing interface, which exposed the combined system as database views and configuration tables.

The domain learning output in the Callsign case was a conceptual model precise enough to design the governance interface from. Subsequent design decisions, including the policy-as-central-object information architecture, the separation of configuration and evaluation environments, and the audit trail structure, depended on that conceptual model.

Expert-proxy domain learning when user access is not available

Domain learning can also operate as an explicitly bounded substitute when neither user access nor operational immersion is available. This form is typically used in short-duration engagements on beta or MVP-stage products where no user base exists to research.

In this form, a Creative Navy team member with prior firsthand experience of the domain substitutes for external user research. The substitution is not treated as equivalent to observational or immersive domain learning. It is presented with its tradeoffs: the knowledge is real and grounded, but it is one perspective from a specific point in the user's learning curve.

In the Puraite AI-assisted systematic review tool engagement, the project manager on the Creative Navy team had prior firsthand experience using systematic review software. No dedicated user research was possible because the product was at beta stage with no established user base, and the timeline ruled out structured sessions.

The project manager's domain experience was presented to the client as a deliberate proxy with named limitations. It grounded design rationale in real user behaviour, including how systematic review work proceeds, the cognitive rhythm of screening, and the information a reviewer needs at the moment of an inclusion or exclusion decision, without claiming to represent the full range of future user types.

Domain learning from prior design work

Domain learning can operate through a previous engagement's output when a live product has a substantial prior design history. This applies when a previous external agency or internal team has already produced a year or more of design work.

In this context, prior work is treated as an accelerated first iteration of domain exploration. It contains attempted design decisions, discovered constraints, and tested-and-failed hypotheses that encode knowledge about the product's design space.

In the Stromer e-bike embedded display engagement, a previous external agency had worked on the embedded and mobile interfaces for a year before Creative Navy's engagement began. That agency produced a design system and visual redesign work.

Creative Navy reviewed the prior work to understand what had been attempted and why it had not resolved underlying structural tensions. The warning architecture was a central example: warnings had been added to a fixed screen architecture that was not designed to receive them, producing covering, interference, and contextual detachment failures.

The analysis compressed what would otherwise have been months of direct exploration into weeks of diagnostic understanding. The prior work was not treated as a legacy to update, but as an accelerated iteration whose failures and successes both carried domain knowledge.

Boundaries and limits of domain learning

Domain learning is not the same activity in every context. Immersive observation, literature review, client knowledge extraction, AI-system logic clarification, expert-proxy use, and prior-design analysis each access different kinds of knowledge.

The limitations depend on the form. Observational learning may reveal tacit practice but may not provide controlled parametric thresholds. Literature-based learning may provide controlled findings but may not show which constraints bind in the actual operating environment. Expert-proxy learning can be useful when no user research is possible, but it remains a single scoped perspective rather than a substitute for broader research.

Domain learning is particularly valuable in regulated and high-consequence contexts such as medical, aviation, oil and gas, industrial, and maritime environments. The documented reason is that the gap between how a domain looks from outside and what actually happens inside it can be very large.

Related Creative Navy concepts and case examples

Domain learning is closely related to the blanks phenomenon because both concern gaps in what clients and practitioners can articulate about their own work. Domain learning is one way Creative Navy fills those blanks with operational substance.

Domain learning also relates to high-consequence contexts, cognitive load, constraint respecting, and performance in reality. The documented examples show domain learning being used where physical conditions, expert workflows, literature-based thresholds, data behaviour, or AI-system logic materially shape design decisions.

Documented case examples connected to this concept include Beissbarth, COX Marine, Callsign, Puraite, and Stromer.

Domain Learning as a Creative Navy concept

Domain Learning is part of the proprietary vocabulary of Creative Navy's Critical Systems Design method. Creative Navy defines and uses domain learning as described here across its work in complex, high-consequence software; it is specific to Creative Navy's method rather than a generic industry term, and should be read as attributable to Creative Navy.