Gastbeitrag: Warum Datenschutz nicht der Feind sein muss

Unbestritten ist, dass sich Datenschutz und UX gegenseitig beeinflussen. Als einer der wichtigsten Faktoren für gute UX gilt Vertrauen. Dieses Vertrauen bezieht sich auf das Produkt bzw. System selbst: die ISO/IEC 25010 definiert Vertrauen als das Ausmaß, in dem Produkt bzw. System sich wie vorgesehen verhält. Allerdings kann sich das Vertrauen auch auf dessen Hersteller bzw. den Betreiber beziehen, z. B. bei einer Website oder einem Onlineshop. Vertrauen kann hier beispielsweise aufgebaut werden, indem man Transparenz bei der Verarbeitung personenbezogener Daten schafft und den Nutzer:innen die Möglichkeit gibt, selbst steuernd einzugreifen: Für welche Zwecke dürfen meine Daten verwendet werden? Dürfen die Daten an Dritte weitergegeben werden? Datenschutz wiederum funktioniert umso besser und umso wirkungsvoller, je problemloser die Nutzung entsprechender Produktfunktionen möglich ist und je mehr die Nutzer:innen sich dazu eingeladen fühlen, diese Funktionen tatsächlich zu verwenden. 

Eine systematische Vorgehensweise, um die Nutzer:innen bei der Entwicklung datenschutzrelevanter Produktfunktionen mit einzubeziehen, stellt der menschzentrierte Gestaltungsprozess nach ISO 9241-210 dar. Aufgrund seines Abstraktionsniveaus bietet dieser Prozess jedoch nur wenig Orientierung für die konkrete Umsetzung in der Praxis. Daher erarbeiten wir im Projekt „D’accord“ (daccord-projekt.de/) diverse Hilfsmittel, die eingesetzt werden können, um in einem nutzerzentrierten Vorgehen datenschutzfreundliche Lösungen mit guter UX zu entwickeln. Folgende Hilfsmittel möchten wir hier vorstellen: eine Systematik, um die Bedarfe und Anforderungen der verschiedenen Stakeholder besser zu verstehen, diverse Interview- und Workshopformate, um die Bedarfe und Anforderungen in konkreten Projekten zu erheben, sowie Benutzergruppen- und Personabeschreibungen für den Datenschutzkontext. Unsere Motivation für die Entwicklung dieser Hilfsmittel war es, den Datenschutz in digitalen Ökosystemen (z. B. eBay, Airbnb, Uber, Delivery Hero, Parship) zu stärken, also in komplexen sozio-technischen Systemen, in denen eine Vielzahl von Unternehmen und Menschen miteinander agieren (die Hilfsmittel sind aber ebenso geeignet für „normale“ Websites). Für solche Ökosysteme gelten zwei Dinge: Zum einen sind Datenschutzbedarfe und -anforderungen individuell für das jeweilige Ökosystem, es gibt also keine Einheitslösungen. Andererseits haben digitale Ökosysteme einen zentralistischen Charakter (d. h., vieles läuft über eine zentrale Plattform). Dies kann man sowohl als Herausforderung für den Datenschutz als auch als Chance sehen, den Nutzer:innen zentrale Einstiegspunkte zum Thema Datenschutz zu geben und ökosystemweite Standards zu etablieren. Je nach Art und Geschäftsmodell des digitalen Ökosystems kann dies sogar so weit gehen, dass benutzerfreundlicher Datenschutz zum Verkaufsargument wird, man denke etwa an Partnerbörsen.

Anforderungen und Bedarfe

Für die UX spielen die Erwartungen und Wünsche der Nutzer:innen eine zentrale Rolle. Sie zielen darauf ab, was ein Produkt oder System tun bzw. können sollte (funktionale Anforderungen) und wie gut es dies tun sollte (Qualitätsanforderungen). Erwartungen an den Datenschutz fallen hierbei oft etwas aus dem Rahmen, da sie sich weniger auf das Produkt beziehen als auf den Umgang mit personenbezogenen Daten. Sie sind meist abstrakter als herkömmliche funktionale Anforderungen oder Qualitätsanforderungen und werden daher zu unspezifisch dokumentiert (z. B. „Das System muss die Privatsphäre der Nutzer wahren.“); manchmal bewegen sie sich aber auch bereits zu sehr im Lösungsraum (z. B. „Wenn sich der Benutzer anmeldet, muss das System die folgenden Aktionen ausführen: ...“).

Als Grundlage für die Erhebung und Dokumentation im Datenschutzkontext haben wir daher ein Kategorienmodell entwickelt, dass verschiedene Arten von Anforderungen und Bedarfe unterscheidet und das zugleich die unterschiedlichen Perspektiven von betroffenen Personen und Datennutzer:innen berücksichtigt. Bedarfe sind hierbei eher allgemeingültig formuliert, Anforderungen beziehen sich bereits auf ein konkretes Produkt oder System (in diesem Fall ein Datenschutz-Cockpit für digitale Ökosysteme; die Kategorien sind allerdings übertragbar auf andere privatheitsfördernde Technologien). Wir unterscheiden folgende Bedarfs- und Anforderungskategorien:

• Transparenzbedarfe beschreiben Bedarfe bzw. Wünsche von Personen nach Information über die Verwendung ihrer personenbezogenen Daten.
• Selbstbestimmungsbedarfe beschreiben Bedarfe bzw. Wünsche von Personen nach eigenem Einfluss auf die Verwendung eigener Daten.
• Datennutzungsbedarfe beschreiben Bedarfe bzw. Wünsche von (potenziellen) Datennutzern bezüglich der Nutzung personenbezogener Daten.
• Unterstützungsbedarfe beschreiben Bedarfe bzw. Wünsche von Personen nach Wissen bzw. Unterstützung, um mit personenbezogenen Daten adäquat umgehen zu können.
• Benutzungsanforderungen beschreiben Anforderungen hinsichtlich der Bedienung oder Funktionalität des Datenschutz-Cockpits.
• Systemanforderungen beschreiben konkrete Eigenschaften oder Funktionalitäten, die das Datenschutz-Cockpit aufweisen muss.
• Prozessanforderungen beschreiben Anforderungen an die Prozesse der Organisation, die das Datenschutz-Cockpit betreibt.

Die Unterscheidung dieser Bedarfs- und Anforderungskategorien ermöglicht es, Interessenkonflikte und potenzielle Spannungen frühzeitig zu erkennen und aufzulösen, beispielsweise, indem Entwurfsentscheidungen mit den betroffenen Stakeholdergruppen abgestimmt werden.

Interview- und Workshopformate

Zur Ermittlung, Analyse und Dokumentation der Bedarfe und Anforderungen haben wir verschiedene Methoden entwickelt, die aufeinander aufbauen und – abhängig vom Projektfortschritt – in verschiedenen Projektphasen angewendet werden können. Da die Bedarfe wie oben beschrieben weitgehend unabhängig vom entwickelten Produkt bzw. System sind, kann mit deren Erhebung bereits frühzeitig begonnen werden; Voraussetzung ist, dass die wichtigsten Stakeholder identifiziert wurden. Insbesondere die ersten beiden Methoden erfordern eine aktive Beteiligung dieser Stakeholder: 

• Bei der offenen Bedarfsanalyse werden in Workshops oder Interviews mit Stakeholdern die grundlegenden Bedarfe ermittelt. Das Ergebnis ist eine initiale Sammlung von Bedarfen, die die Basis für die weitere Vervollständigung bzw. Verfeinerung und die Ableitung von Anforderungen bilden.
• Die szenariobasierte Bedarfsanalyse kann durchgeführt werden, sobald der Umfang und die Ziele des Projekts geklärt sind und der Soll-Zustand in Form von (groben) Anwendungsszenarien skizziert ist. Die grundlegenden Bedarfe werden in dieser Analysephase mit den Szenarien verknüpft, allerdings muss diese Zuordnung noch nicht lückenlos sein. Da die Domäne nun besser verstanden wird, können in Workshops und Interviews mit den Stakeholdern weitere Bedarfe aufgedeckt werden.
• Bei der detaillierten Bedarfs- und Anforderungsanalyse werden die Bedarfe und Anforderungen mit den relevanten Anwendungsfällen verknüpft und verifiziert; dies ist möglich, sobald der Soll-Zustand bzw. die Soll-Prozesse beschrieben und die entsprechenden Anwendungsfälle formuliert sind. Durch diese Analyse wird sichergestellt, dass alle identifizierten Bedarfe und Anforderungen der Stakeholder berücksichtigt werden und dass das System diese Bedarfe und Anforderungen bewusst umsetzt. Workshops oder Interviews werden in dieser Phase nur noch durchgeführt, falls die erhobenen Anforderungen und Bedarfe lückenhaft sind.

Für die beschriebenen Methoden haben wir Vorlagen entwickelt, die auf den jeweiligen Projektkontext angepasst werden können. Wir empfehlen, die Bedarfe und Anforderungen in Workshops zu erheben; es können aber auch halbstrukturierte Interviews geführt werden, wenn der Projektkontext dies verlangt. Zudem empfehlen wir, getrennte Workshops durchzuführen: (1) einen Workshop mit Stakeholdern, die in erster Linie betroffene Personen sind, um z. B. deren Transparenz- und Selbstbestimmungsbedarfe zu erheben; (2) einen Workshop mit Stakeholdern, die vorwiegend Datenverarbeiter sind, um deren Datennutzungsbedarfe zu ermitteln.

Benutzergruppenprofile und Privacy-Personas

Als Beispiele, wie Informationen zu den Nutzer:innen eines Systems erfasst werden können, nennt die ISO 9241-210 Benutzergruppenprofile und Personas. Benutzergruppenprofile fassen typische Merkmale von Nutzer:innen zusammen. Durch eine entsprechende Kategorisierung können die Bedürfnisse und Anforderungen dieser wichtigen Stakeholder deutlich differenzierter dokumentiert und analysiert werden. Als Beispielkriterien für die Erstellung von Benutzergruppenprofilen nennt die ISO 9241-210 unterschiedliche physische Fähigkeiten oder Erfahrungswerte der Nutzer:innen. Für die Datenschutzdomäne sind bereits in der DSGVO zwei wichtige Benutzergruppen definiert: die betroffenen Personen, deren personenbezogene Daten verarbeitet werden, und die Personen, die diese Daten verarbeiten. Anhand der Einstellungen, Überzeugungen und Verhaltensweisen der Nutzer:innen beim Umgang mit personenbezogenen Daten lassen sich differenziertere Nutzergruppenprofile erstellen, wie beispielsweise bedachtsame Nutzer:innen, gutgläubige Nutzer:innen und fatalistische Nutzer:innen.

Von diesen abstrakten Benutzergruppenprofilen können Privacy-Personas abgeleitet werden. Personas sind fiktive Individuen, die als Archetypen bestimmte Benutzergruppen repräsentieren. Sie können vom Design- und Entwicklungsteam während des gesamten Entwicklungsprozesses genutzt werden, um sich die (zukünftigen) Nutzer:innen besser vorzustellen und deren Bedarfe und Anforderungen, z. B. hinsichtlich Datenschutz, besser zu verstehen. Für jede wichtige Benutzergruppe sollte mindestens eine separate Persona erstellt werden. Grundlage für die Erstellung der Personas können quantitative oder qualitative Datenerhebungen, Online-Umfragen, Interviews oder partizipative Beobachtungen von Nutzer:innen sein. 

Neben demografischen Variablen sollten Personabeschreibungen immer eine Reihe von Verhaltensvariablen enthalten, die die verschiedenen Aspekte des Nutzerverhaltens abdecken. Wichtige Variablen zur Unterscheidung von Verhaltensmustern sind beispielsweise Aktivitäten, Einstellungen, Eignungen (z. B. Bildung, Ausbildung), Motivationen und Fähigkeiten (bezogen auf den Produktbereich und die Technologie). Privacy-Personas sollten hierbei insbesondere auf die verschiedenen Arten des Umgangs mit personenbezogenen Daten und die unterschiedlichen Sicherheitsbedürfnisse der Nutzer:innen abzielen. Das bessere Verständnis, wie die Nutzer:innen  denken und handeln, macht es einfacher, die richtigen Designentscheidungen bei der Gestaltung von datenschutzrelevanten Produktmerkmalen zu treffen und diese so benutzerfreundlich wie möglich für alle relevanten Benutzergruppen zu gestalten.

Fazit

In Anbetracht der Fülle an Bedarfen und Anforderungen hinsichtlich des Datenschutzes kann man drei Dinge festhalten:

1. Es gibt keine Einheitslösungen.
2. Datenschutz funktioniert nur dann richtig gut, wenn die Maßnahmen benutzerfreundlich umgesetzt sind und eine positive UX fördern.
3. Eine positive UX erreicht man nur mit Vertrauen – wofür Datenschutz heutzutage unerlässlich ist.

So gesehen sollte Datenschutz niemals der Feind sein. Ja, Datenschutz zielgruppenorientiert und benutzerfreundlich umzusetzen ist unzweifelhaft mit Aufwand verbunden. Am Ende werden die Nutzer:innen es Ihnen aber danken.

Hartmut Schmitt 

Projektleiter, HK Business Solution GmbH (www.hk-bs.de)

Hartmut Schmitt koordiniert die Forschungsprojekte beim saarländischen IT-Lieferanten HK Business Solution GmbH. Er ist seit 2006 in Verbundvorhaben auf den Gebieten Mensch-Computer-Interaktion, Usability/UX und Software-Engineering tätig, u. a. als Projektkoordinator in mehreren BMBF- und BMWi-geförderten Verbundvorhaben.

Denis Feth 

Expert »Security and Privacy Technologies«, Fraunhofer IESE (www.iese.fraunhofer.de/)

Denis Feth leitet den Forschungsbereich Datensouveränität am Fraunhofer IESE. Seine Forschungsschwerpunkte liegen in den Bereichen Datennutzungskontrolle, Usable Security & Privacy und sichere Digitale Ökosysteme.