10 Feminist Heuristics for Digital Design

Satirisches Bild mit gestapelten "Critical notification"-Pop-ups, die "10 Feminist Heuristics For Digital Design" ankündigen - nervige UI-Patterns fordern besseres Design

Nielsen’s Usability Heuristiken stammen aus einer Zeit, in der Software vor allem Tools waren: Desktop-Anwendungen für einzelne Nutzer*innen, die Aufgaben effizient erledigen wollten. Effizienz war zentral. Kontext spielte kaum eine Rolle. Machtverhältnisse irgendwie auch nicht.

Heute ist das alle etwas anders. Digitale Systeme schaffen und strukturieren soziale Realitäten, Algorithmen, Plattformen und KI beeinflussen, was wir sehen, wem und was wir glauben, wer Zugang zu Chancen bekommt … und wer eben nicht

Der Check auf Usability allein reicht dafür eigentlich nicht mehr. Was wir brauchen, ist ein erweitertes Verständnis von Design: nicht nur funktional, sondern auch gerecht.

Hier ist also mein Vorschlag für 10 feministische Heuristiken für digitales Design – inspiriert von Shaowen Bardzell (Feminist HCI), D’Ignazio & Klein (Data Feminism) und Tech-Feministinnen wie Donna Haraway. Anwendbar auf Interfaces, Plattformen und algorithmische Systeme.

Enjoy! ✊

1. Sichtbarkeit von Machtverhältnissen

Digitale Systeme sind nie neutral. (Donna Haraway lässt grüßen!) Macht also transparent, wessen Interessen ein System dient, wer Entscheidungen trifft und wer von den Daten profitiert.

Ideen für die Praxis:

  • Rankings und Empfehlungen werden verständlich erklärt . Zum Beispiel: „Wir zeigen dir das, weil du ähnliche Inhalte geliked hast“ vs. „Wir zeigen dir das, weil ein Werbekunde dafür bezahlt hat.“
  • Kommerzielle Interessen sind klar gekennzeichnet: Werbung, Sponsoring, bezahlte Platzierungen sind als solche erkennbar.
  • Es ist sichtbar, wer am System beteiligt ist (z.B nicht nur die Plattform selbst, sondern auch Werbekunden, Datenbroker, Drittanbieter)

Methoden für Teams:

  • Wichtige Nutzungswege durchgehen und prüfen: Wo sind Machtverhältnisse versteckt? Wo ist unklar, wer profitiert?
  • Im Designprozess fragen: Wem nützt das? Wer könnte dadurch benachteiligt werden?
  • Interfaces systematisch auf manipulative Muster prüfen z.B  auf versteckte Kosten, verschleierte Werbung, irreführende Defaults.

2. Pluralismus statt One-Size-Fits-it-All

Es gibt nicht DEN Standard-User. Gestaltet für unterschiedliche Lebensrealitäten, Körper und Perspektiven –  auch wenn diese sich widersprechen.

Ideen für die Praxis:

  • Wichtige Prozesse funktionieren für verschiedene Menschen. Zum Beispiel: Formulare mit mehr als zwei Geschlechtsoptionen, Interfaces die mit Screenreadern UND ohne Maus bedienbar sind.
  • Es gibt keine unnötigen Ausschlüsse durch Standardannahmen  etwa dass alle eine Kreditkarte haben, einen festen Wohnsitz, oder ein bestimmtes Namensformat.
  • Seltene Fälle (sog. “Edge Cases“) werden ernst genommen, nicht nur nebenbei “on top” als nice to have toleriert, weil für die betroffenen Menschen sind das keine Edge Cases, sondern einfach Alltag.

Methoden für Teams:

  • User Research mit diversen Menschen: nicht nur „typische Nutzer*innen“, sondern bewusst unterschiedliche Menschen und somit Lebensrealitäten einbeziehen.
  • Barrierefreiheit weiter denken als WCAG – auch kognitive, soziale, ökonomische Barrieren berücksichtigen

3. Individuelle Kontrolle und kollektive Verantwortung

Menschen brauchen Handlungsspielraum –  aber ihre Entscheidungen betreffen oft auch andere. Design sollte beides berücksichtigen: Kontrolle für Einzelne UND Schutz für die Gemeinschaft.

Ideen für die Praxis:

  • Menschen können selbst entscheiden: Welche Daten teile ich? Wer sieht was? Wie wird mein Profil personalisiert?
  • Risiken für andere werden sichtbar gemacht oder aktiv verhindert . Zum Beispiel: Wenn ich ein Foto teile, auf dem andere zu sehen sind, werde ich darauf hingewiesen.
  • Es gibt Schutzmechanismen für Betroffene, nicht nur für aktive Nutzer*innen  , viell. etwa die Möglichkeit, auch ohne Account Inhalte melden zu können.

Methoden für Teams 

  • Zustimmungsprozesse prüfen: Sind sie verständlich? Können Menschen wirklich differenziert entscheiden?
  • Durchdenken: Wer ist indirekt betroffen? (Beispiel: Sharing-Funktionen → Wer ist auf dem Foto? Fake News → Wer wird durch Desinformation geschädigt?)
  • Missbrauchsszenarien durchspielen: Wie könnte diese Funktion für Doxxing, Belästigung oder Manipulation genutzt werden?

4. Konsistenz – aber bitte kontextsensitiv

Konsistenz ist wichtig – aber der Kontext auch. Ein „Like“ unter einem Trauerpost bedeutet etwas anderes als unter einem Katzenvideo. Systeme sollten solche Unterschiede berücksichtigen.

Ideen für die Praxis:

  • Gleiche Buttons oder Funktionen werden je nach Situation unterschiedlich interpretiert oder ergänzt. Zum Beispiel könnte ein „Gefällt mir“ bei sensiblen Themen zu „Solidarität zeigen“ werden.
  • Wichtige Interaktionen sollten situativ bewertet werden, nicht nur automatisch nach festen Regeln – was allerdings menschliche Moderation oder sehr differenzierte Systeme erfordert, den nansonsten sind wir et voila, bei paternalistischen Systemen, die glauben zu wissen was ich will .

Methoden für Teams:

  • Reale Nutzungssituationen durchgehen und verstehen, wie sich Bedeutung je nach Kontext ändert.
  • Qualitative Forschung: Was bedeutet diese Aktion für Menschen in verschiedenen Situationen? (z. B. „Was drückt ein Like hier eigentlich aus?“)

5. Fehlertoleranz und Wiederherstellbarkeit

Fehler passieren, sowohl Menschen als auch Systemen. Entscheidend ist, wie gut sich Fehler korrigieren lassen, statt permanente Konsequenzen zu erzeugen.

Ideen für die Praxis:

  • Menschen können Aktionen bequem rückgängig machen oder korrigieren.  Zum Beispiel einen Post löschen, eine Bewertung ändern, eine Einstellung zurücksetzen.
  • Systeme „verzeihen“ einzelne Klicks, sie leiten nicht aus einem versehentlichen Like oder einer einzigen Suchanfrage ab, was ich „wirklich will“, und bombardieren mich dann monatelang damit.
  • Es gibt klare Wege, um Entscheidungen von Systemen anzufechten z.B wenn ein Post fälschlicherweise (for no reason) gelöscht wurde oder ein Account gesperrt wurde.

Methoden für Teams:

  • Prüfen: Wo können Menschen ihre Aktionen rückgängig machen? Wo fehlt diese Möglichkeit?
  • Identifizieren: An welchen Stellen gibt es kein Zurück mehr Ist das wirklich nötig?
  • Testen: Funktionieren Beschwerde- und Korrekturprozesse? Und auch: Wie verständlich und einfach und zugänglich sind sie?

6. Einfachheit ohne Verschleierung

Reduktion ist gut, aber nicht, wenn wichtige Informationen dabei verschwinden. Entscheidungen sollten immer nachvollziehbar bleiben, besonders wenn Daten oder Algorithmen im Spiel sind.

Ideen für die Praxis:

  • Wichtige Entscheidungen sind erklärbar, ohne dass Menschen tief graben müssen.
  • Vereinfachung blendet keine kritischen Informationen aus (etwa warum mir diese Werbung gezeigt wird oder wie eine Empfehlung zustande kam)
  • Menschen können bei Bedarf und einfach ohne viel Mühe mehr Details einsehen..

Methoden für Teams:

  • Informationen in Layern anbieten: Kurze Erklärung ist z.B sofort sichtbar, die Details auf Wunsch verfügbar ( aber ohne viel AUfwand!)
  • Testen, ob Menschen Systementscheidungen nachvollziehen können nicht nur ob sie das Interface bedienen können (war das für sie klar, wieso Sie dies oder das gesehen haben aber  das andere nicht?) 
  • Erklärungen verständlich und einfach schreiben, also keine Jura-Sprache, keine technischen Formeln.

7. Auswirkungen für Nutzer*innen sichtbar machen

Design sollte nicht nur zeigen, was sofort passiert, sondern auch, welche weiterreichenden Konsequenzen eine Aktion hat.

Ideen für die Praxis:

  • Aktionen zeigen ihre möglichen Folgen. Zum Beispiel: Ich kommentiere etwas – Wie viele Menschen sehen das? Was passiert, wenn ich jemanden melde? Welche Konsequenzen hat ein Post für andere?
  • Was nach einer Aktion passiert, ist klar nachvollziehbar und kein Mysterium.
  • Unsicherheit wird ehrlich kommuniziert, zum Beispiel: „Wir prüfen das, aber es kann 3-5 Tage dauern“ statt einfach gar keine Kommunikation  über die Dauer (Erwartbarkeit & Vertrauen!).

Methoden für Teams:

  • Nicht nur den Moment des Klicks betrachten, sondern auch was danach kommt, also was löst diese Aktion für Fragen aus?
  • Konkret durchspielen: „Was passiert nach Klick X?“ und diese Infos für Nutzer*innen sichtbar machen. 
  • Co -Design bzw Partizipation für realistische Fragestellungen 
  • Texte schreiben, die realistische Erwartungen setzen (z. B. bei Meldefunktionen oder Beschwerden)
  • Organisationale Prozesse anregen die das adressieren

8. Hilfe, die wirklich hilft und auch erreichbar ist

Standardisierte Hilfetexte reichen oft nicht aus. Gerade bei sensiblen Entscheidungen brauchen Menschen nachvollziehbare Erklärungen und erreichbaren Support.

Ideen für die Praxis:

  • Entscheidungen werden konkret begründet –  also nicht nur „verstößt gegen Community-Richtlinien“, sondern welche genau und warum.
  • Echte Unterstützung ist erreichbar, nicht nur FAQs oder automatisierte Antworten.
  • Besonders vulnerable Situationen sind berücksichtigt  z.B  wenn jemand Belästigung melden will und nicht weiß, was danach passiert.

Methoden für Teams:

  • Support-Prozesse testen: Wie leicht erreiche ich echte Hilfe? Wie verständlich sind die Antworten?
  • Nicht nur erfolgreiche Durchläufe testen, sondern gezielt Problemfälle und Fehlersituationen.
  • Menschen, die tatsächlich betroffen sind, in die Gestaltung einbeziehen (z. B. Personen, die Belästigung erlebt haben, bei der Gestaltung von Meldefunktionen).

9. Aktive statt passive / nachträgliche Schadensvermeidung

Plattformen tragen Verantwortung für vorhersehbare negative Effekte ihrer Systeme.

Design sollte Risiken wie Belästigung, Diskriminierung oder Eskalation aktiv reduzieren.

Ideen für die Praxis:

  • Bekannte Risikomechaniken werden adressiert  z.B  Pile-ons (koordinierte Attacken auf einzelne Personen durch Sharing- oder Quote-Funktionen) oder algorithmische Eskalation (wenn Empfehlungssysteme kontroverse oder extreme Inhalte bevorzugen, weil sie mehr Engagement erzeugen)
  • Es gibt präventive Maßnahmen, nicht nur reaktive Moderation.
  • Risiken werden kontinuierlich gemessen und überprüft.

Methoden für Teams:

  • Risiko-Assessments durchführen.
  • Systematisches Durchspielen von Missbrauchsszenarien, idealerweise partizipativ, um blinde Flecken zu vermeiden und um möglichst viele Perspektiven abzudecken. 
  • Kontinuierliches Monitoring von Schäden: Wie häufig werden bestimmte Features für Belästigung genutzt? Werden manche Gruppen disproportional oft gemeldet oder geblockt? Solche Metriken zeigen, wo Design Schaden verursacht.

10. Verzerrungen erkennen statt Neutralität vortäuschen

Systeme sollten nicht nur funktionieren, sondern gesellschaftliche Ungleichheiten berücksichtigen und diese nicht reproduzieren und so immer weiter manifestieren

Ideen für die Praxis:

  • Daten und Algorithmen werden auf Verzerrungen geprüft – zum Beispiel: Bevorzugt das System bestimmte Gruppen?
  • Ergebnisse werden für unterschiedliche Gruppen getrennt ausgewertet, um Ungleichbehandlung zu erkennen.
  • Die Begriffe „Neutralität“ und „Objektivität“ werden kritisch hinterfragt weil „neutral“ oft nur heißt: für die Mehrheit gemacht.

Methoden für Teams:

  • Daten und Ergebnisse auf Verzerrungen prüfen (Bias Audits).
  • Auswirkungen für verschiedene Gruppen separat betrachten (z. B.: Funktioniert das für alle Geschlechter gleich gut? Für verschiedene Altersgruppen?).
  • Unterschiedliche Perspektiven einbeziehen z.B aus Recht, Ethik, Politik und betroffenen Communities.

Und warum ist das jetzt feministisch?

Warum nenne ich diese Heuristiken „feministisch“ und nicht einfach „inklusiv“ oder „ethisch“? Weil feministisches Design mehr ist als Inklusion.

Inklusion fragt: „Wie können wir mehr Menschen einbeziehen?“ Das ist superwichtig, aber es hinterfragt eben nicht grundsätzlich, wer das System gestaltet, wessen Werte es kodiert, und wer von seinen Strukturen profitiert.

Feministisches Design fragt danach, wer hier Macht hat, wessen Perspektiven fehlen,  und welche Strukturen, Hierarchien und Biases wir reproduzieren. Es geht also nicht nur darum, mehr Menschen Zugang zu geben, sondern darum, Machtverhältnisse sichtbar zu machen und diese zu verändern.

Feminismus ist eine analytische perspektive, die nach Macht, Hierarchien und struktureller Ungerechtigkeit fragt,  und nicht nur nach Gender, sondern intersektional: entlang von Geschlecht, Race, Klasse, Alter, Ability, und anderen Aspekten von Privilegierung und Marginalisierung.

Diese Heuristiken sind also feministisch zu sehen, weil sie Machtkritik ins Zentrum stellen. Sie fragen danach für wen das überhaupt gemacht ist/wurde  und auf wessen Kosten. 

Ein System kann gleichzeitig super effizient und sehr gut benutzbar sein aber  dennoch ungerecht.

Feministische Heuristiken sollen den Blick also von der puren  Usability zum kritischen Hinterfragen erweitern. Durch konkrete Checks und Methoden werden sie zu einem Tool, das Teams im Alltag wirklich einsetzen können. Mir ist klar, das das nicht alles reibungslos  1:1 umzusetzen ist, aber  das ist auch nicht der Zweck, sondern diese Nielsen-Style Heuristiken  sind als Anregung und zur Sensibilisierung des Themas zu verstehen. 

Literatur:  

Bardzell, S. (2010). Feminist HCI: Taking stock and outlining an agenda for design. CHI 2010.

D’Ignazio, C. & Klein, L. F. (2020). Data Feminism. MIT Press.

GDPR Cookie Consent mit Real Cookie Banner