domain-expert-configuration

Domain Expert Configuration

A domain expert configuration UI exposes the parameters of a complex system — an optimisation algorithm, a planning engine, a simulation — to users who understand the problem domain deeply but have no knowledge of the system's internals.

The challenge: the system's parameters are defined in technical terms (weights, thresholds, flags, tolerances). The user thinks in domain terms (how long to wait, when to retry, how to group results). The UI must translate between these two vocabularies — always favouring the user's language.

---

The Core Principle: Domain Language Over Technical Language

Every parameter label, tooltip, and error message should describe what the parameter means in the user's world, not what it does inside the system.

Technical label	Domain label
max_concurrent_jobs	Maximum tasks running at once
enable_auto_retry	Retry failed tasks automatically
batch_allocation_threshold	Start a new batch after (% filled)
request_timeout_ms	Maximum wait per request (seconds)
enable_fuzzy_matching	Allow approximate matches

If you cannot write a domain label for a parameter, question whether the user should be exposed to it at all. Parameters that cannot be explained in domain terms belong in a developer configuration file, not in the user-facing UI.

---

Grouping by Domain Concept

Parameters should be grouped by the aspect of the real-world problem they control — not by their technical category (booleans together, numbers together) and not alphabetically.

A processing tool might group as:

Processing limits
  └─ Maximum tasks at once
  └─ Maximum wait per request
  └─ Memory ceiling

Matching rules
  └─ Allow approximate matches
  └─ Case sensitivity
  └─ Required fields

Batching behaviour
  └─ Batch fill threshold
  └─ Maximum batches

Each group should have a short heading that describes what aspect of the task it controls, not what kind of parameter it is.