Der Broken Windows Effekt ist eine Theorie aus der Psychologie. Sie besagt, dass sichtbare Anzeichen von Unordnung und Fehlverhalten zu mehr Unordnung und Fehlverhalten führen. Die Theorie entstammt einem Erklärungsversuch, wie alte Gebäude verfallen. So ist oft zu sehen, dass verlassene Gebäude lange Zeit noch sehr intakt aussehen, bis das erste Fenster eingeworfen wird. Sobald das passiert ist, werden häufig weitere Fenster eingeschlagen. Daher stammt auch der Name der Theorie. Sie wird aber ebenfalls auf das Arbeitsumfeld und die Erziehung angewendet.
Was ist der Broken Windows Effekt?
Die Theorie wurde zuerst 1982 von den Sozialwissenschaftlern James Wilson und George Kelling entwickelt (einen Link zur Veröffentlichung gibt es unten). Die beiden Wissenschaftler erklären, dass ein zersprungenes Fenster in einer Nachbarschaft schnell zu weiteren zerstörten Fenstern führen wird. Dieses Phänomen ist dabei völlig unabhängig davon, wie reich oder arm die Nachbarschaft ist. Sie argumentieren, dass ein zerstörtes Fenster symbolisiert, die Menschen würden sich nicht dafür interessieren. Und deshalb führe die Zerstörung weiterer Fenster nicht zu Ärger.
Broken Windows sind dabei allerdings lediglich als Metapher zu verstehen. Wilson und Kelling geht es um jegliche sichtbaren Zeichen von Unordung. Das können Anzeichen von Kleinverbrechen oder Vandalismus sein, aber auch einfach nur herumliegender Müll und vieles mehr.
Broken Windows Effekt in der Softwareentwicklung
In der Softwareentwicklung passiert genau dasselbe. Aufgrund von äußeren Einflüssen, wie z.B. hohem Zeitdruck, oder aufgrund von fehlenden Wissens werden schnelle, aber unsaubere Lösungen entwickelt. Das ist nur menschlich und im Projektalltag normal.
Manchmal sind solche unsauberen Lösungen nicht allen bekannt, gerade wenn die oder der Entwickelnde dieser Codestelle sich des “Fehlers” nicht bewusst ist. In anderen Fällen geraten sie in Vergessenheit oder werden aufgrund mangelnden Budgets nicht behoben.
Das Resultat ist in jedem Fall dasselbe: Der Fehler wird nicht behoben.
Die äußeren Einflüsse (s.o.) bleiben gleich. Nun ändert sich allerdings für die Entwickler*innen, dass im Code ja bereits unsaubere Lösungen vorzufinden sind. Also ist die Hemmschwelle deutlich niedriger, selbst auch einen “Quick-Win” zu landen und ein Feature schnell, aber womöglich unsauber zu entwickeln.
Dieser Prozess verstärkt sich immer weiter. Sind erst einmal einige solcher Unsauberheiten im Code zu finden, bedarf großer Anstrengung, diese Problemstellen zu identifizieren und zu korrigieren.
Der Broken Windows Effekt besteht also und stellt eine tatsächliche “Gefahr” für die Codequalität dar. Hier gibt es dann immer wieder Versuche, z.B. mit statischer Codeanalyse, Code-Reviews oder ähnlichem. Diese Ansätze haben alle ihre Berechtigung, müssen aber immer vom Team getragen werden. Es ist selten hilfreich, hier eine Firmenrichtlinie einzuführen und statische Codeanalyse für alle einzuführen und hierbei keinen Gestaltungsspielraum bei der Parametrisierung der Analysetools zu erlauben. Doch bevor ich hier zu sehr ins Detail gehe (vielleicht ist das ja ein Thema für einen eigenen Beitrag?), kommen wir zurück zum eigentlichen Thema.
Broken Windows Effekt in der Frontendentwicklung
Ich habe bereits gezeigt, dass der Broken Windows Effekt in der Softwareentwicklung besteht. Nun steht allerdings immer noch die Frage im Raum, ob er auch im Bereich der Frontendentwicklung und vor allem auch im Bereich des Frontend-Designs eine Rolle spielt.
Die kurze Antwort auf diese Frage ist, dass ich keine nennenswerten Publikationen zu diesem Thema gefunden habe.
Daher präsentiere ich im Folgenden nur meine Gedanken zu dieser Thematik. In der Implementierung des Frontends spielt der Broken Window Effekt natürlich eine vergleichbar große Rolle wie in der Softwareentwicklung im Allgemeinen. Der Unterschied hier ist jedoch, dass Unsauberkeiten sofort für die Nutzer*innen spürbar wird, sei es durch Performance-Verlust oder sonstiges “Fehlverhalten”. So sinkt die Usability sehr schnell. Das kann – und das wissen wir alle – dazu führen, dass die Applikation nicht mehr akzeptiert wird, mit allen negativen Nebenwirkungen.
Besonders spannend ist nun, ob der Broken Windows Effekt bereits während des Designs eines Frontends zu Buche schlägt. Wichtig ist wieder, wie bereits bei der Softwareentwicklung, dass ein “erstes Fenster zerbricht”. Im Bereich des Designs können das unpassend gewählte Icons sein, ein unbeabsichtigter Verstoß gegen die Gestaltgesetze oder auch ein fehlender Fokus auf die Erfordernisse der Benutzer*innen.
Der weitere Verlauf ist komplett deckungsgleich zu dem bereits beschriebenen. Es werden weitere Unsauberheiten entwickelt und ins Design mit eingearbeitet, bis schließlich ein Design besteht, das nicht mehr an den Nutzer*innen ausgerichtet ist und nur mit viel Mühe wieder korrigiert werden kann.
Doch auch hier gibt es einfache Gegenmaßnahmen, die bereits im benutzerzentrierten Design berücksichtigt sind: regelmäßige Iterationen, d.h. Feedback-Schleifen mit den Kunden und Tests. Wird ein Design regelmäßig mit den echten Nutzer*innen getestet, fallen solche Unsauberheiten oder Fehler (“kaputte Fenster”) sofort auf und können behoben werden.
Fazit
Der Broken Windows Effekt ist ein reales Phänomen. Er tritt in der Softwareentwicklung, aber auch im -design auf. Dies schließt das Frontend-Design selbstverständlich mit ein.
Doch es gibt Gegenmittel, die einfach und kostengünstig dabei helfen können, “zerbrochene Fenster” schnell wieder zu reparieren und den Effekt somit nachhaltig aufhalten.
Schreiben Sie einen Kommentar