Design Input / Design Output

Dr.-Ing. Benedikt JannySenior Usability Engineer | Managing Partner
Stand: 2026
Kurz-Definition

Design Inputs sind die dokumentierten Anforderungen, Randbedingungen und Nutzerbedürfnisse, die als Grundlage für die Entwicklung eines Medizinprodukts dienen. Design Outputs beschreiben, wie diese Anforderungen konkret technisch umgesetzt werden – etwa als Zeichnungen, Spezifikationen, Software-Artefakte oder Gebrauchsanweisung. Im Usability Engineering umfassen beide insbesondere nutzerbezogene Anforderungen, Nutzungskontexte und Anforderungen an die Benutzungsschnittstelle, deren Übereinstimmung nachvollziehbar bewertbar sein muss.

Design Inputs im Usability-Engineering-Prozess

Im Usability Engineering entstehen Design Inputs nicht isoliert, sondern werden aus der Anwendungsspezifikation, der Analyse von Nutzungskontexten, bekannten Use Errors, Marktbeobachtungen und der Nutzungsrisikoanalyse abgeleitet. Die Qualität dieser Eingaben beeinflusst unmittelbar die spätere Gebrauchstauglichkeit und Sicherheit des Produkts. Unvollständige oder unscharfe Design Inputs führen häufig dazu, dass sicherheitskritische Nutzungsszenarien erst spät erkannt werden. Usability-relevante Design Inputs stammen typischerweise aus Anwenderforschung, Kontextanalysen, Beobachtungen im Feld, Interviews, Complaint-Daten, Vigilanzmeldungen, Konkurrenzanalysen und Human-Factors-Studien. Auch Ergebnisse formativer Evaluationen können zu neuen oder überarbeiteten Design Inputs führen.

Design Inputs versus User Needs

Ein häufiger Fehler besteht darin, User Needs und Design Inputs gleichzusetzen. User Needs beschreiben, was Nutzer erreichen müssen oder erwarten. Design Inputs übersetzen diese Bedürfnisse in überprüfbare Entwicklungsanforderungen. Beispielsweise kann die User Need „sichere Medikamentendosierung unter Zeitdruck" zu Design Inputs wie maximaler Schrittzahl im Programmierprozess, Mindestschriftgrößen oder spezifischen Alarmanforderungen führen. Design Inputs müssen ausreichend präzise sein, damit daraus Design Outputs entwickelt und verifiziert werden können. Viele Design Inputs sind zudem direkt aus dem Risikomanagement nach ISO 14971 abgeleitet: Werden nutzungsbezogene Gefährdungen oder Hazard-related Use Scenarios identifiziert, ergeben sich daraus Anforderungen an die Benutzungsschnittstelle, Schulungen, Warnhinweise oder Workflow-Unterstützung.

Design Output als Übersetzung der Anforderungen

Im Design-Control-Prozess bildet der Design Output die Brücke zwischen den Anforderungen und dem späteren Produkt. Während Design Inputs beschreiben, was das Produkt leisten muss, definiert der Design Output, wie diese Anforderungen technisch umgesetzt werden. Die Qualität der Design Outputs bestimmt maßgeblich die Nachvollziehbarkeit von Verifikation, Validierung und Design Transfer. Usability-Anforderungen aus Anwendungsspezifikation und Nutzungsrisikoanalyse müssen sich in konkreten Design Outputs wiederfinden – beispielsweise kann die Anforderung „Verwechslung von Dosierungen minimieren" als farblich differenziertes UI-Element, eindeutige Anzeige oder physische Formkodierung umgesetzt werden.

Typische Design Outputs im Medizinproduktebereich

Je nach Produktart können Design Outputs unterschiedliche Artefakte umfassen: Hardware-Zeichnungen und Konstruktionsunterlagen, Material- und Komponentenspezifikationen, Software-Architektur und -Spezifikationen, User Interface Specifications, Alarme und Fehlermeldungen, Kennzeichnung und Verpackung, Gebrauchsanweisung (IFU), Prüfverfahren und Akzeptanzkriterien sowie Produktions- und Montageanweisungen. Aus Human-Factors-Sicht gehören insbesondere alle benutzungsrelevanten Merkmale der Benutzungsschnittstelle zu den kritischen Design Outputs – dazu zählen etwa Dosierungsalgorithmen, Alarmgrenzen, Bedienlogik, Verriegelungsmechanismen, Warnhinweise, Kennzeichnungen und kritische Softwarefunktionen, die häufig in direkter Verbindung zu identifizierten Gefährdungen aus der Risikomanagementakte stehen.

Bedeutung von Akzeptanzkriterien

Ein zentraler Aspekt von Design Outputs ist die Verknüpfung mit messbaren Akzeptanzkriterien. Ein Output ist regulatorisch nur begrenzt nutzbar, wenn nicht definiert ist, wie seine Konformität bewertet wird – die Beschreibung „Display gut lesbar" reicht beispielsweise nicht aus. Stattdessen müssen objektive Kriterien wie Kontrastwerte, Zeichengrößen, Reaktionszeiten oder Betrachtungsabstände festgelegt werden. Ebenso sollten Design Inputs von Anfang an messbar formuliert sein: Allgemeine Aussagen wie „einfach bedienbar" oder „intuitive Benutzerführung" sind weder verifizierbar noch validierbar.

Typische Schwächen in der Praxis

In Entwicklungsprojekten werden Design Inputs häufig zu technisch formuliert und berücksichtigen Nutzeranforderungen erst nachgelagert. Bei Design Outputs treten regelmäßig folgende Defizite auf:

  • Fehlende Traceability zwischen Input und Output
  • Unvollständige User-Interface-Spezifikationen
  • Fehlende oder nicht messbare Akzeptanzkriterien
  • Nicht dokumentierte Designänderungen
  • Mangelnde Kennzeichnung sicherheitsrelevanter Outputs
  • Unzureichende Abstimmung zwischen Human Factors, Entwicklung und Risikomanagement

Besonders bei Software-Produkten wird oft festgestellt, dass Bedienoberflächen zwar implementiert, aber nicht ausreichend spezifiziert oder dokumentiert wurden.

Regulatorischer Bezug

IEC 62366-1 fordert die Erstellung einer Anwendungsspezifikation als Grundlage für usability-relevante Design Inputs sowie die Ableitung und Berücksichtigung von Hazard-related Use Scenarios und die Spezifikation der Benutzungsschnittstelle (User Interface Specification) als Design Output. ISO 14971 verlangt, dass Risikokontrollmaßnahmen als nachvollziehbare Design Inputs in die Entwicklung einfließen; die Traceability zwischen Risikoanalyse und Entwicklung ist regulatorisch relevant. Die FDA erwartet in ihrer Human-Factors-Guidance, dass Human-Factors-Anforderungen frühzeitig in die Produktentwicklung integriert und aus Nutzerforschung sowie risikobasierten Analysen abgeleitet werden. Nach US-amerikanischem Recht (21 CFR 820.30(d), FDA Design Controls / QMSR) müssen Design Outputs dokumentiert, angemessen bewertet und als Grundlage für die Verifikation gegen die Design Inputs verwendet werden; sicherheits- bzw. funktionskritische Outputs müssen identifiziert werden. ISO 13485 fordert entsprechend, dass Entwicklungsergebnisse die Entwicklungsanforderungen erfüllen, Informationen für Beschaffung, Produktion und Service bereitstellen sowie Akzeptanzkriterien und sicherheitsrelevante Produktmerkmale enthalten.

Häufige Fragen (FAQ)

Sind User Needs und Design Inputs dasselbe?

Nein. User Needs beschreiben Bedürfnisse oder Ziele der Anwender. Design Inputs übersetzen diese Bedürfnisse in konkrete, überprüfbare Entwicklungsanforderungen.

Was unterscheidet Design Input und Design Output?

Design Inputs beschreiben Anforderungen an das Produkt. Design Outputs beschreiben die konkrete technische Umsetzung dieser Anforderungen. Zwischen beiden sollte eine nachvollziehbare Traceability bestehen.

Ist eine Gebrauchsanweisung ein Design Output?

Ja. Die IFU ist ein dokumentiertes Entwicklungsergebnis und beschreibt sicherheits- und nutzungsrelevante Aspekte des Produkts. Sie gehört deshalb typischerweise zu den Design Outputs.

Müssen Design Inputs und Outputs messbar formuliert sein?

Idealerweise ja. Anforderungen und Ergebnisse sollten so formuliert sein, dass daraus Verifikation und gegebenenfalls Validierung möglich sind. Allgemeine Aussagen wie „benutzerfreundlich" sind dafür ungeeignet.

Kurz gesagt

Design Inputs definieren, was ein Produkt leisten muss; Design Outputs zeigen, wie das technisch umgesetzt wird. Ohne durchgängige Traceability zwischen beiden – über messbare Akzeptanzkriterien – lässt sich weder Verifikation noch Validierung regulatorisch belastbar nachweisen.

Sie möchten usability-relevante Design Inputs sauber aus Nutzungsrisikoanalyse und Kontextanalyse ableiten und nachvollziehbar in Ihre Design Outputs überführen? Wir unterstützen Sie im gesamten Usability-Engineering-Prozess nach IEC 62366-1.

Mehr zu unserem Usability Engineering

Verwandte Begriffe

← Zurück zum Wiki-Überblick