Alexander Bier

…und die Illusion einfacher Entscheidungen in komplexen Systemen

“The time it takes to make a decision increases logarithmically with the number of available choices.”

$$T = a + b \cdot \log_2(n)$$

• T = Reaktionszeit / Entscheidungszeit
• n = Anzahl der Auswahlmöglichkeiten
• a, b = empirisch bestimmte Konstanten
  • a = Grundzeit (z. B. reine Wahrnehmungs- und Reaktionszeit, selbst wenn nur eine Option vorhanden ist)
  • b = Skalierungsfaktor (gibt an, wie stark die Reaktionszeit mit zunehmender Informationsmenge bzw. Anzahl der Optionen steigt)

Warum mehr Optionen oft zu schlechteren Entscheidungen führen und was das für Software und Leadership bedeutet

In der Kognitionswissenschaft gibt es ein scheinbar einfaches Gesetz, das tiefgreifende Auswirkungen auf digitale Systeme und Teamstrukturen hat. Hick’s Law beschreibt den Zusammenhang zwischen der Anzahl von Optionen und der Zeit, die ein Mensch benötigt, um eine Entscheidung zu treffen.

Die Grundidee stammt aus Experimenten zur menschlichen Reaktionszeit. Dabei wurde beobachtet, dass Entscheidungszeit nicht linear wächst, sondern mit zunehmender Anzahl an Optionen immer langsamer steigt. Je mehr Möglichkeiten vorhanden sind, desto mehr kognitive Last entsteht.

Das wissenschaftliche Prinzip hinter Hick’s Law

Hick’s Law lässt sich vereinfacht so beschreiben: Jede zusätzliche Option erhöht die Informationsmenge, die verarbeitet werden muss, bevor eine Entscheidung getroffen werden kann.

Statt einer einfachen Auswahl zwischen zwei Möglichkeiten entsteht ein Entscheidungsraum, der immer komplexer wird. Der Mensch muss vergleichen, filtern und bewerten.

Mathematisch wird dieser Zusammenhang oft als logarithmisches Wachstum beschrieben. Das bedeutet, dass die Entscheidungszeit zwar nicht linear explodiert, aber dennoch deutlich zunimmt, sobald die Anzahl der Optionen steigt.

Warum Entscheidungen in Software-Systemen davon betroffen sind

In der Softwareentwicklung wird Hick’s Law oft unterschätzt. Entwickler denken in technischen Möglichkeiten, nicht in kognitiven Belastungen.

Ein API Design mit vielen ähnlichen Endpunkten, ein Framework mit zahlreichen Konfigurationsoptionen oder ein System mit unklaren Verantwortlichkeiten erhöht die Entscheidungszeit erheblich.

Das Problem entsteht nicht im Code selbst, sondern im Kopf der Personen, die das System nutzen oder weiterentwickeln müssen.

Jede zusätzliche Option bedeutet eine weitere potenzielle Fehlentscheidung, eine weitere Abhängigkeit und eine weitere mentale Abwägung.

Komplexität ist nicht nur ein technisches Problem

Komplexität wird oft als reine Codeeigenschaft betrachtet. In Realität ist sie jedoch ein Zusammenspiel aus Technik, Organisation und menschlicher Wahrnehmung.

Ein System mit vielen Konfigurationsmöglichkeiten kann technisch flexibel wirken, erzeugt jedoch gleichzeitig Unsicherheit und Entscheidungsstress.

Diese Unsicherheit führt häufig dazu, dass Entscheidungen verzögert oder inkonsistent getroffen werden.

Hick’s Law im Kontext von Architektur

In der Softwarearchitektur zeigt sich Hick’s Law besonders deutlich bei der Gestaltung von Schnittstellen.

Ein gut gestaltetes System reduziert nicht nur technische Komplexität, sondern auch die Anzahl der Entscheidungen, die ein Entwickler treffen muss.

Ein Beispiel ist die Reduktion von API Optionen. Statt viele ähnliche Varianten anzubieten, wird eine klare und konsistente Struktur bevorzugt.

Dadurch sinkt die kognitive Last und die Geschwindigkeit, mit der Entscheidungen getroffen werden können, steigt.

Der Einfluss auf Teams und Leadership

In Teams wirkt Hick’s Law nicht nur auf technische Entscheidungen, sondern auch auf organisatorische Strukturen.

Je mehr Wege es gibt, ein Problem zu lösen, desto mehr Abstimmungen sind notwendig. Je mehr Entscheidungsfreiheit ohne klare Leitplanken existiert, desto langsamer werden Teams.

Leadership bedeutet in diesem Kontext nicht, mehr Optionen zu schaffen, sondern den Entscheidungsraum bewusst zu gestalten.

Ein gutes Teamdesign reduziert unnötige Entscheidungszweige und schafft klare Verantwortlichkeiten.

Warum weniger Optionen oft bessere Systeme erzeugen

Ein häufiges Missverständnis in der Softwareentwicklung ist, dass mehr Flexibilität automatisch bessere Systeme erzeugt.

In der Praxis ist oft das Gegenteil der Fall. Systeme mit weniger, aber klar definierten Optionen sind einfacher zu verstehen, zu warten und zu skalieren.

Reduktion bedeutet hier nicht Einschränkung, sondern Fokus. Fokus reduziert Entscheidungszeit und erhöht die Konsistenz in der Nutzung eines Systems.

Hick’s Law in modernen digitalen Plattformen

Viele erfolgreiche Plattformen reduzieren bewusst die Anzahl an Entscheidungen, die Nutzer treffen müssen.

Standardisierte Prozesse, klare Defaults und eingeschränkte Konfigurationsmöglichkeiten sind kein Zufall, sondern eine direkte Anwendung dieses Prinzips.

Das Ziel ist nicht maximale Freiheit, sondern minimale kognitive Reibung bei gleichbleibender Funktionalität.

Übertragung auf technische Führung

In technischen Führungsrollen wird Hick’s Law zu einem strategischen Werkzeug.

Die wichtigste Aufgabe besteht darin, Komplexität so zu strukturieren, dass Entscheidungen schneller und konsistenter getroffen werden können.

Das betrifft Architekturentscheidungen ebenso wie Teamstrukturen, Kommunikationswege und technische Standards.

Gute Systeme entstehen nicht durch eine Vielzahl von Möglichkeiten, sondern durch bewusst reduzierte und klar definierte Entscheidungsräume.