System Design, Human Factors, Usability, and Clinical Decision Support

Human factors studies the relationship between people, tasks, tools, environment, and system design. The goal is not to make users more careful; it is to design work so normal human limitations are less likely to produce harm. Memory is limited, attention is selective, interruptions are common, and people develop shortcuts under pressure.

Cognitive load is a design variable. A nurse who must remember a result from one screen while navigating through three menus to act on it is carrying avoidable working-memory burden. Systems should externalize important information when possible through clear displays, task state, and meaningful defaults.

Visibility affects action. Information can technically exist in the chart while being functionally invisible. A critical code-status field buried several clicks away may satisfy documentation requirements without supporting time-sensitive care.

Consistency reduces the need to relearn. If the same clinical concept appears in different locations or uses different labels across modules, users must translate constantly. Some variation is clinically necessary, but arbitrary variation increases cognitive work.

Error recovery matters as much as error prevention. Users will make mistakes. Safe design allows them to notice, undo, correct, and understand consequences. A destructive action with no confirmation or clear recovery path turns ordinary slips into larger failures.

Usability concerns whether intended users can achieve intended goals effectively, efficiently, and with acceptable experience in the intended context. A system can be learnable but inefficient, attractive but error-prone, or fast for experts but confusing for occasional users.

Task-based testing is more informative than asking whether users “like” the system. Give representative users realistic tasks and measure completion, errors, time, navigation, help needed, and points of confusion. Satisfaction matters, but it should be interpreted alongside performance and safety.

Heuristic evaluation uses established design principles to identify likely problems. Common heuristics include visibility of system status, match with the real world, user control, consistency, error prevention, recognition rather than recall, and clear recovery. Heuristics do not replace user testing; they help find problems early and cheaply.

Representative users and environments matter. Testing with informatics staff who already know the build underestimates difficulty. Include novice and experienced users, relevant roles, device types, and realistic interruptions when possible.

Usability is not a one-time certification event. New content, devices, upgrades, and workflow changes can create new usability problems. Post-go-live tickets and workarounds are usability evidence.

A prototype is a learning tool, not a promise. Low-fidelity sketches help test information organization and workflow before expensive build. Higher-fidelity prototypes help test interaction details. Teams should state what is fixed and what remains open so users do not mistake a prototype for final design.

Clinical content should be designed around decisions and work, not around the database schema. A field may be easy for the system to store but awkward for clinicians to interpret. Group information according to clinical meaning, sequence, and decision points.

Defaults reduce effort but can create silent error. A default is appropriate when it is correct most of the time and the user can easily see and change it. Defaults are dangerous when users may accept them without reassessment, especially for time-sensitive clinical facts.

Structured data and narrative serve different purposes. Structured fields support consistency, decision support, exchange, and analytics. Narrative captures nuance and context that predefined categories may miss. Good design uses structure where standardization matters and narrative where meaningful variation cannot be represented safely.

Clinical decision support (CDS) uses patient- or context-specific information to support a clinical or operational decision. CDS includes alerts, reminders, order sets, dosing support, risk scores, documentation guidance, and relevant information display. Merely displaying data is not necessarily CDS; the system must meaningfully support a decision or action.

The “five rights” idea is a useful design test: right information, right person, right format, right channel, right time. A correct recommendation delivered after the decision is useless. A relevant alert sent to someone who cannot act creates noise. A complex explanation in a high-interruption moment may fail even if accurate.

Actionability is central. Good CDS should make the next appropriate action clear or reduce the effort required to act. Alerts that say “consider reviewing” without context may transfer cognitive burden to the clinician rather than support the decision.

CDS needs a closed-loop evaluation. Measure not only firing rate and clicks but whether the intended clinical action occurred, whether unintended actions increased, whether the effect persists, and whether some groups experience different performance or burden.

Alert fatigue is not simply “too many alerts.” It is a deterioration in appropriate response associated with repeated exposure to alerts that are excessive, low-value, poorly timed, or irrelevant. Recent systematic review work shows that alert-fatigue measurement remains inconsistently defined; override rate alone does not prove fatigue.

Override can be appropriate. A clinician may correctly dismiss an alert because the system lacks context. A high override rate should trigger investigation of specificity, timing, duplication, actionability, and workflow rather than automatic blame.

Automation bias occurs when people give excessive weight to automated recommendations. The opposite problem can also occur: repeated poor recommendations create distrust and underuse. Safe design needs calibrated trust—users should understand what the system is good at, where uncertainty exists, and when independent verification is necessary.

Explanations must support action, not decorate the output. A risk score labeled “high” without contributing factors or recommended next steps may not help the clinician. For AI-supported CDS, provenance, intended use, limitations, and relevant inputs become increasingly important.

Monitoring should look for both under-response and over-response. A highly sensitive alert may cause unnecessary testing; an AI recommendation may be followed too readily; a sepsis score may alter care differently across units. Evaluation should compare benefits, burden, and harm.