How To Buy Design Work For Regulated Or Critical Systems

Regulated and high-consequence design commissions require process integrity

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.

Buying design work for a regulated or high-consequence product requires a different assessment from buying design work for ordinary software. Standard design procurement often asks whether a partner can produce functional, visually coherent interfaces on time and within budget. That question remains relevant, but it is not sufficient where the interface can affect regulatory acceptance, operational safety, financial control, or other forms of high-consequence system performance.

The additional requirement is process integrity. In an IEC 62366-1 medical device context, the relevant question is not whether the final interface appears usable in a subjective sense. The relevant question is whether the design process identified use-related hazards, addressed them through traceable design decisions, and produced a usability engineering record suitable for the manufacturer's regulatory submission.

Documented reasoning is a deliverable in regulated and critical systems

A design partner in a regulated or high-consequence context is not only producing screens. The design partner is also producing a documented reasoning trail: what was investigated, what was found, what alternatives were considered, what decisions were made, and why those decisions followed from the evidence.

In regulated contexts, that reasoning trail can become a regulatory artefact. In high-consequence contexts without formal regulation, the same record is still important because it protects the product team against later claims that a design decision was arbitrary or uninformed.

Commissioning a design partner without this distinction creates a specific failure mode. The partner may deliver interface screens without the reasoning behind them. The product team then has to reconstruct design intent during development, while the regulatory team may have to reconstruct documentation after the fact. Both reconstructions are expensive, and post-hoc regulatory documentation introduces regulatory risk.

Creative Navy's scope in IEC 62366-1 medical device contexts

In IEC 62366-1 medical device contexts, Creative Navy's Critical Systems Design method produces formative evaluation support for the manufacturer's own IEC 62366-1 compliance activities. This scope includes domain research, formative usability work, and design rationale documentation structured to support the manufacturer's regulatory process.

Creative Navy's work in this context can include identifying use scenarios, researching intended users and their environments, conducting formative evaluation sessions, and producing design decisions traceable to identified use-related hazards.

Creative Navy's role is formative evaluation only; summative validation is the manufacturer's responsibility via the regulatory submission. FDA approval for a medical device is determined through the manufacturer's regulatory submission, reviewed by the FDA, against a standard the manufacturer is accountable for meeting. Creative Navy structures design work to support that submission, but the submission, the clearance decision, and the regulatory accountability belong to the manufacturer.

Creative Navy does not certify compliance with IEC 62366-1 or any other standard. Compliance is determined through the relevant regulatory process, not through a design deliverable.

Creative Navy's scope in financial services compliance contexts

In financial services contexts involving SCA, PCI DSS, and PSD2, Creative Navy designs the interaction architecture that makes compliance requirements behavioural rather than merely documentary.

The relevant design principle is that an audit trail that is not produced as a natural consequence of normal system use is unlikely to exist in practice. In this type of engagement, Creative Navy's design work aims to make the compliance requirement a property of the workflow, not a separate documentation activity.

Creative Navy does not certify compliance with SCA, PCI DSS, PSD2, or any other financial services standard. The design deliverable is the workflow and interaction structure that gives the organisation's own compliance activities a sound foundation.

Creative Navy's scope in high-consequence contexts without formal regulation

High-consequence operational contexts without formal regulation still require documented design reasoning. The source examples include industrial simulation tools, custody intelligence platforms, and high-volume transactional systems.

In these contexts, Creative Navy produces reasoning documentation similar to the documentation produced in regulated contexts: what the research found, what design decisions followed, and why. The absence of a formal standard does not remove the need for a defensible evidence base.

This record supports future defence, extension, and maintenance of the product. Without it, later teams may have to reinvent the reasoning behind core interface and workflow decisions.

Procurement should assess documentation structure

Procurement for regulated or high-consequence design work should assess the structure of the design rationale, not only the visual quality of deliverables.

An organisation should ask what form the reasoning record takes. The relevant question is whether the partner can show how a design decision addressing a specific identified risk is documented. A second question is whether the partner can explain how that record differs for development handoff and regulatory review.

A partner that cannot answer these questions with specificity may not have worked in regulated contexts before, or may have worked in them without treating documentation as a design requirement.

Procurement should assess compliance scope clarity

Procurement for regulated design work should ask directly what the design partner delivers in relation to regulatory requirements and what remains outside the partner's scope.

A partner that conflates formative evaluation work with regulatory compliance creates risk. The issue may be a misunderstanding of the distinction, or it may be a scope description that will not withstand scrutiny from a regulatory affairs team.

The correct scope distinction is precise. Creative Navy handles the design process with the rigour, documentation structure, and traceability that the regulatory requirement demands. The regulatory process itself remains the manufacturer's responsibility.

Procurement should assess the evidence standard for design decisions

In high-consequence contexts, design decisions cannot be arbitrary. Procurement should assess the standard a partner uses to determine whether a design decision is adequately evidenced.

The useful question is not whether the partner is generally evidence-based. The useful question is when the partner considers it acceptable to proceed with a design direction, and when additional research or testing must happen first.

A credible answer describes how evidential confidence is calibrated. It should explain how the design partner decides whether the evidence is strong enough for the consequence level of the decision.

Common procurement failure: treating design as a production phase

A regulated or high-consequence design engagement is partly a risk management activity. Treating the engagement only as production work misses the role of design in identifying interface-related risk, producing design decisions that address those risks, and documenting the reasoning behind those decisions.

Organisations that commission screens first and expect compliance documentation to appear at the end have the sequence wrong. The documentation must be produced through the investigation and decision process, not reconstructed after interface production.

Common procurement failure: separating design from regulatory affairs

In medical device contexts, the design team and the regulatory affairs team work on the same problem from different angles. A design process conducted without input from regulatory affairs can produce findings and decisions that later need to be reworked to fit the required documentation structure.

Integrating design and regulatory affairs from the start is presented in this guide as cheaper and more reliable than coordinating the two activities at the end.

Common procurement failure: selecting primarily on visual quality

Visual quality is not the primary assessment criterion for regulated or high-consequence interface design. The primary concern is whether the interface avoids use-related hazards that the design process should have identified.

A visually striking interface that has not been tested against the relevant use scenarios can be more dangerous than an unglamorous interface supported by a complete usability engineering record.

Related buying guidance

This guide extends the evaluation criteria described in How To Evaluate A UX Partner For Complex Products by adding the regulated and high-consequence requirements of documentation structure, compliance scope clarity, and evidence standards.

How To Scope A Complex UX Engagement is also relevant when the commission needs explicit boundaries around design work, research, documentation, development handoff, and regulatory responsibilities.

How To Brief A Project When The Problem Is Still Fuzzy is relevant where the organisation has not yet separated interface production needs from the operational, regulatory, or evidential risks that the design engagement must address.