Zusammenfassung des Projektes

Im Laufe der Projektarbeit hat sich unser Fokus teilweise etwas verschoben, was aber immer mit den eigentlich Zielen des Projektes einherging.

Am Anfang war die ePA. Wir haben uns die verschiedenen Anwendungen angeschaut und uns in erster Linie Fragen zur Nutzbarkeit und Einfachheit der Nutzung gestellt. Darüber haben wir uns zur Überprüfung der Barrierefreiheit bewegt und sind über die kontinuierliche Verfeinerung des Scopes bei unserer letztendlichen Zielsetzung und Zielgruppe angelangt.

1. Ziele
   • Verbesserung der digitalen Barrierefreiheit der elektronischen Patientenakte für sehbehinderte und blinde Personen
   • Entwicklung eines Prototypen für die Erkennung und Analyse von Schwachstellen in der Barrierefreiheit von Anwendungen
2. Kontext
   • Durch die Vielzahl der verschiedenen Krankenkassen und die dadurch sehr individuelle und vielfältige Umsetzung der ePA durch jede einzelne Krankenkasse erschien uns die generelle Verbesserung der Usability als schwierig. Dementsprechend war die Fokussierung auf lediglich eine Anwendung nicht mit unserer Zielsetzung vereinbar.
   • Durch das bei uns als Entwicklern fehlende Verständnis und Wissen sowie das nicht vorhandene Bewusstsein beim Umsetzen einer Software, dass diese auch von Personen genutzt wird, die diese nicht visuell wahrnehmen, wurde uns eine neue Ebene des Problems bewusst.
   • Dadurch wurde der Fokus des Projektes auf die Entwicklung eines Prototypen verschoben, der Awareness bei Entwicklern schaffen soll und gleichzeitig eine Unterstützung bei der Arbeit ist.
3. Stakeholder
   • Zunächst bildeten blinde und sehbehinderte Personen unsere primären, direkten Stakeholder ab, jedoch wurde die Gruppe durch die Umorientierung des Projektes zu indirekten Stakeholdern. Diese Gruppe betrachten wir aber trotzdem als die wichtigste, da sich die Zielsetzung des Projektes ganzheitlich um sie dreht.
   • Direkte Stakeholder sind nun die Entwickler und Designer von Softwareanwendungen, im Speziellen den Anwendungen zur elektronischen Patientenakte.
   • Dadurch kommen noch viele weitere Stakeholder ins Spiel, wie beispielsweise die Krankenkassen, die ePA Anwendungen veröffentlichen und die Entwickler beschäftigen, oder auch die Anbieter der verschiedenen Screenreader und anderen Hilfsmitteln. Diese Gruppen liegen aber nicht im Fokus des Projektes.

Testergebnisse

Die Ergebnisse der Usability Tests belaufen sich auf zwei verschiedene Arten von Ergebnissen, den durch den Beobachter festgestellten Bedingungen und Reaktionen auf die Anwendung und den durch die Testpersonen selbst ausgefüllten User Experience Questionnaires.

Beobachtungen

Um die Beobachtungen während des Tests auszuwerten, haben wir die verschiedenen Informationen und Äußerungen der Testpersonen nach der jeweiligen Art geclustert.

Rohform der Daten

Durch die Art der Erhebung lagen die Daten zunächst gruppiert nach der jeweiligen Aufgabe im Test vor. Dementsprechend gab es vier Kategorien, drei für die jeweiligen Testaufgaben und eine mit allgemeinem Feedback.

Bei den drei Aufgaben handelte es sich um die folgenden Anweisungen:

1. Nutzen Sie die Funktion „Detailuntersuchung“ der Anwendung. Ermitteln Sie damit, wie ein konkretes Problem eines UI-Elements der ePA-Anwendung behoben werden kann.
2. Nutzen Sie die Funktion „Strukturübersicht“ der Anwendung. Ermitteln Sie, wie viele Unterelemente das UI-Element „2021“ in Summe besitzt.
3. Nutzen Sie die Funktion „Komplettüberprüfung“ der Anwendung. Ermitteln Sie damit, wie viele Probleme in der ePA-Anwendung insgesamt festgestellt werden können.

Dadurch waren die Daten für die einzelnen Aufgaben schon lose den drei Hauptfunktionen der Anwendung zugeordnet.

Erste Aufarbeitung

Bei der ersten Gruppierung der Daten wurden diese in die folgenden Kategorien unterteilt:

• Format und Durchführung des Usability Test
• Interaktionsmöglichkeiten
• Layout der Anwendung
• Wording der Anwendung
• Konzept der Anwendung
• Rechtschreibung und visuelle Gestaltung
• Feature Requests
• Positive Rückmeldungen

Diese Kategorien konnten nachfolgend bereinigt und auf die wesentlichen Punkte mit Handlungsbedarf reduziert werden.

Finale AufarbeitunG

Format und Durchführung des Tests

Die durchaus berechtigten Kritikpunkte am Format und der Durchführung des Usability Test sind für die weitere Entwicklung und Evaluation nicht von Bedeutung, müssen jedoch für zukünftige Tests bedacht und verbessert werden.

So waren die Einverständniserklärung und das Skript nicht vollständig ausgereift und einige Mappings im Figma-Prototypen waren nicht korrekt implementiert. Auch die Verwendung des User Experience Questionnaires warf fragen auf, jedoch dazu später mehr.

Interaktionsmöglichkeiten

Bei verschiedenen Ansichten und Funktionen der Anwendung wurde die fehlende Sichtbarkeit von Interaktionsmöglichkeiten bemängelt. Die Testpersonen wussten in manchen Situationen dadurch nicht, wie mit der Anwendung gearbeitet werden sollte.

Dies sollte definitiv verbessert werden und hat eine hohe Priorität.

Layout der Anwendung

Das Layout der Anwendung scheint nicht optimal umgesetzt zu sein, da es unter anderem bei der Detailuntersuchung als „überfordernd“ eingestuft wurde. Zusätzlich dazu fehlen einige visuelle Brücken, um Informationen im Overlay mit den dazugehörigen problematischen Elementen der zu untersuchenden Anwendung zu verknüpfen.

Außerdem wurde vorgeschlagen, das Layout der Applikation mehr in Richtung der Entwicklerkonsole von Browsern auszurichten, um Verwirrung vorzubeugen.

Die aufgeführten Punkte zeigen die Notwendigkeit auf, das Layout der Applikation zu überdenken und Verfeinerungen und Verbesserungen zu konzipieren.

Wording der Anwendung

Insbesondere in der „Strukturübersicht“ der Anwendung hat sich das momentane Wording als problematisch herausgestellt. Die Betitelung der einzelnen „Elemente“ und „Ebenen“ hat zu Verwirrung unter den Testpersonen geführt und wurde mehrfach kritisiert.

Dementsprechend müssen für diese Funktion bessere Bezeichnungen und ein klareres Format für die Untersuchung gefunden werden, da das Ziel der Funktion sonst nicht erfüllt werden kann.

Diese Problematik hat eine sehr hohe Priorität, da sie in direktem Konflikt mit den Zielen der Anwendung hinsichtlich der Einfachheit der Nutzung und der Verständlichkeit steht.

Konzept der Anwendung

Einige Probleme im Konzept der Anwendung wurden ebenfalls aufgedeckt.

So ist das mehrfache Auswählen der zu untersuchenden Anwendung störend und sollte lediglich einmal am Anfang erfolgen, da Nutzende voraussichtlich nicht mitten in der Evaluation ihrer Anwendung zu einer anderen wechseln wollen.

Zusätzlich wurde in Frage gestellt, ob Elemente in einer Anwendung, die keine Probleme aufweisen, tatsächlich angezeigt werden müssen. Dies würde die Übersichtlichkeit trüben und nicht notwendig sein.

Beiden Punkte sind durchaus berechtigt und sollten in einer nächsten Version dringend umgesetzt werden, da diese ebenfalls die direkten Ziele der Anwendung betreffen.

Rechtschreibung und visuelle Gestaltung

In der Anwendung befinden sich einige Fehler hinsichtlich Rechtschreibung und Gestaltung. Beispielsweise sollten für die Detailuntersuchung der einzelnen Elemente Überschriften eingefügt werden, um den momentanen Ort in der Anwendung zu verdeutlichen.

Diese Probleme sind wichtig, lassen sich jedoch schnell und unkompliziert beheben.

Feature Requests

Im Rahmen vom allgemeinen Feedback und aufkommenden Fragen während der Tests sind einige mögliche Funktionen oder gewünschte Features aufgekommen. Diese werden von uns als sinnvoll und nützlich angesehen und sollten in der Weiterentwicklung der Anwendung auf jeden Fall erwogen werden:

• Einfügen von Beispielen für Metadaten – Aufzeigen von beispielhaften HTML-Elementen
• Bewertung der durch die Anwendung erkannten Probleme hinsichtlich ihrer Schwere („Severity“)
• Ergänzung von Tooltips und Hover-Informationen für die einzelnen Bedienelemente der Anwendung und Funktionalitäten
• Zusätzlicher Bereich der Anwendung für die Bereitstellung von Ressourcen und Informationen zu den gesetzlichen Rahmenbedingungen für digitale Barrierefreiheit

Positive Rückmeldungen

Einige Elemente der Anwendung wurden während der Tests gelobt und als ansprechend hervorgehoben. Während diese Rückmeldungen natürlich einen angenehmen und motivierenden Effekt haben, sind die Verbesserungsvorschläge von größerer Bedeutung.

User Experience Questionnaire

Die durch das UEQ erhobenen Daten machen auf uns keinen besonders aussagekräftigen Eindruck.

Anhand der Einschätzungen der Testpersonen wird eine generelle Übersicht über den Umgang mit der Anwendung gewonnen und es kann abgelesen werden, ob man sich bei der Entwicklung gerade völlig auf dem Holzweg befindet.

Wir haben für die einzelnen Punkte des UEQ die jeweiligen Durchschnittswerte ermittelt und stellen diese nachfolgend dar.

Bei dem verwendeten UEQ handelt es sich um eine bipolare Likert-Skala. Die einander gegenübergestellten Adjektive können bei vollständiger Zustimmung mittels Ankreuzen der 1 oder der 7 ausgewählt werden. Dementsprechend stellt die 4 die Mitte der Skala dar.

• behindernd <-> unterstützend -> 5
• kompliziert <-> einfach -> 4,3
• ineffizient <-> effizient -> 5,6
• verwirrend <-> übersichtlich -> 5,6
• langweilig <-> spannend -> 4,3
• uninteressant <-> interessant -> 5
• konventionell <-> originell -> 4,3
• herkömmlich <-> neuartig -> 5

Abschließend lässt dich zum UEQ sagen, dass wir die Ergebnisse aufgrund der Anzahl der Testpersonen als nicht repräsentativ ansehen und auch nicht mit dem generellen Aufbau zufrieden sind, da die einzelnen Punkte nicht klar voneinander differenziert sind und teilweise die Bedeutung nicht vollständig erfasst werden kann.

Abgleich der Ergebnisse und Ziele

Schlussfolgernd kann aus den Ergebnissen abgeleitet werden, dass ein erster Schritt in Richtung der Projektziele getan wurde.

Viele Kritikpunkte und Verbesserungsvorschläge sind aufgekommen, die den aktuellen Prototypen in eine bessere Richtung steuern und bestehende Probleme aufzeigen. Dadurch werden aber auch Lösungsmöglichkeiten für ebendiese Probleme aufgezeigt.

Das sehr groß gesteckte Projektziel, zur digitalen Barrierefreiheit der elektronischen Patientenakte einen wesentlichen Beitrag zu leisten, konnte nicht erfüllt werden. Jedoch wurde eine erste Lösung in Form eines Prototypen entwickelt, der in ferner Zukunft ebendieses Ziel umsetzen könnte.

Dementsprechend bleibt das erste Ziel unerfüllt, aber das zweite und neuere Ziel kann als erfüllt betrachtet werden.

Die durch den Prototyp vorgestellten Funktionen rufen gemischte Reaktionen hervor. Die Gesamtüberprüfung scheint dadurch eine vielversprechende Funktion zu sein, die im aktuellen Stand der Umsetzung schon gut funktioniert. Die Struktur- und Detailansichten scheinen jedoch noch nicht sehr ausgereift zu sein und benötigen eindeutig noch sehr viel mehr Arbeit.

Ausblick

Für die weitere Umsetzung des Projektes sind einige Handlungsmöglichkeiten denkbar:

1. Suche nach Sponsoren/Partnern
   • Die Umsetzung einer qualitativ hochwertigen Softwarelösung erfordert zeitlichen und finanziellen Aufwand. Für die Deckung der dadurch entstehenden Kosten ist die Suche nach einem Sponsoren oder einer Organisation, mit der kooperiert werden kann, sinnvoll.
2. Aufstellen eines Projektteams
   • Die Umsetzung einer funktionierenden Anwendung, die unseren Vorstellungen und Zielen entspricht, ist im Alleingang oder auch zu zweit unrealistisch. Dementsprechend ist die Zusammenstellung eines Projektteams mit Programmierern und UI-Designern naheliegend.
3. Entwicklung einer funktionsfähigen Version
   • Anschließend an die vorherigen Punkte kann agil eine erste Version entwickelt werden. Die Grundbausteine der Anwendung werden rudimentär umgesetzt, um erste Tests zu ermöglichen.
   • Dabei sollten die in den Usability-Tests erhobenen Verbesserungsvorschläge, Anmerkungen und Feature-Requests dringend verarbeitet werden.
4. Validierung der Anwendung und Sinnhaftigkeit
   • Neben der konkreten Umsetzung der Anwendung ist es notwendig, das die Anwendung im späteren Verlauf überhaupt verwendet wird. Dementsprechend sollten mögliche Nutzer und Nutzerinnen gesucht werden, die die verschiedenen Versionen der Software evaluieren können und sie für ihre Arbeit als sinnvoll und nützlich erachten.
5. Messung des konkreten Nutzens der Anwendung
   • Als letzter Punkt ist das Ermitteln des konkreten Nutzens der Anwendung interessant. Werden Softwareprodukte durch die Verwendung der Anwendung im Entwicklungsprojekt für blinde und sehbehinderte Personen ansprechender gestaltet und dadurch einfacher zu nutzen?
     Kann der durch die Anwendung gewünschte Effekt tatsächlich belegt werden?

In diesem Post wollen wir noch einmal die Durchführung der Interviews und die Ergebnisse aufarbeiten, die bisher nur intern bei uns vorlagen.

Rahmenbedingungen

In Summe wurden drei Interviews mit verschiedenen Personen durchgeführt, die der Zielgruppe der blinden und sehbehinderten Personen angehören. Von allen Teilnehmern wurde das Einverständnis für die Aufzeichnung des Interviews und der gesammelten Daten eingeholt.

Die Transkription der Interviews wurde durch den dafür zur Verfügung gestellten Service der Universitätsbibliothek der Freien Universität Berlin auf Basis von Whisper durchgeführt.

Die Interviews erfolgten über Webex und Zoom am 26.05., 29.05. und am 07.07. durchgeführt.

Die befragten Personen wiesen unterschiedliche Affinitäten zur Nutzung von digitalen Inhalten auf, sowohl im beruflichen als auch im privaten Kontext.

Ergebnisse

In allen Interviews wurde die Wichtigkeit der Kompatibilität von Apps und Programmen mit Screenreadern betont. Die befragten Personen nutzen alle den Dienst JAWS („Job Access with Speech“) sowie verschiedene andere Programme zur Spracheingabe und -ausgabe ihrer Geräte.

Die wesentlichen Probleme in der Nutzung digitaler Angebote belaufen sich dabei laut den Befragten auf die unterschiedliche Qualität in der Umsetzung. In vielen Fällen sind Elemente in Anwendungen nicht korrekt oder gar nicht beschriftet, wodurch die Funktion der Elemente nicht durch einen Screenreader ausgegeben werden kann.

Dadurch können die Anwendungen nur eingeschränkt oder auch gar nicht verwendet werden.

Das Problem wird von den befragten Personen dabei deutlich beschrieben und auf Seiten der direkten Anwendungen und Webseiten verortet. Das Angebot und die Funktionsweise von Mobilgeräten oder Betriebssystemen sei im Allgemeinen zufriedenstellend, da einige gut funktionierende Möglichkeiten und Dienste bereitgestellt werden. Vor Allem die Funktionalitäten von iOS (VoiceOver) werden mehrfach gelobt.

Learnings

Alles in Allem hat die Durchführung der Interviews einen tiefen und lehrreichen Einblick in die Materie gewährt, der für den Aufbau eines grundliegenden Verständnisses für die Domäne genutzt werden konnte.

Mit den gewonnenen Einsichten konnte im weiteren Verlauf des Projektes zielführend weitergearbeitet werden, auch wenn der Fokus der Arbeit noch einmal verschoben werden musste, um ein sinnvolles Ergebnis erzielen zu können.

Dokumentation

Für die Durchführung der Usability-Tests benötigen wir die folgenden Dokumente:
– Skript
– Einverständniserklärung
– Aufgabenformular
– Fragebogen (Post-Test)

Um die Zufriedenheit (satisfaction) der Testpersonen zu erheben, wollen wir eine Post-Test-Befragung durchführen. Dazu verwenden wir einen standardisierten Fragebogen in seiner verkürzten Form, um die Testpersonen nicht zu überfordern und den gegebenen Rahmen nicht zu sprengen.
Wir haben uns deswegen für den User Experience Questionnaire entschieden.

Außerdem haben wir unseren Prototyp weiterhin verbessert und dazu das Feedback der anderen Projektgruppe einfließen lassen. Dementsprechend hat sich das Layout des Entwurfs verändert und die Interaktionsmöglichkeiten wurden angepasst.

Prototyp

Link zum neuen Prototype

Skript

Herzlich Willkommen und vielen Dank, dass Sie sich die Zeit für diesen Test mit uns nehmen.
In diesem Usability-Test geht es um den Prototypen, den wir im Rahmen des Moduls Human-Computer-Interaction entwickelt haben. Das Thema in diesem Semester sind dabei die elektronische Patientenakte und digitale Gesundheitsanwendungen.
Dazu haben wir die verschiedenen existierenden Anwendungen der Krankenkassen für die Patientenakte untersucht und mehrere Interviews geführt. Unsere Ergebnisse zeigen, dass Verbesserungsbedarf in der digitalen Barrierefreiheit besteht und zu diesem Thema haben wir weiterführend gearbeitet.
Unser Prototyp stellt ein Analyse-Tool für Desktop-Anwendungen dar. Es soll diese Anwendungen auf ihre digitale Barrierefreiheit prüfen und Lösungsansätze für bestehende Probleme anbieten.
Damit wir die Daten aus dem heutigen Test auch verwenden können, benötigen wir von Ihnen Ihr Einverständnis. Dazu haben wir dieses Dokument vorbereitet.
Im Anschluss an den Test haben wir noch einen Fragebogen vorbereitet, in dem Sie einmal Ihre generellen Erfahrungen und Eindrücke mit dem Prototypen einschätzen sollen.

Falls Sie bereit sind, können wir gleich mit dem Test starten.
Dabei ist es wichtig, noch einmal zu erwähnen, dass wir den Prototypen testen. Sie können keine Fehler beim Test machen, Sie weisen uns gegebenenfalls nur auf unvorteilhafte Designs oder Umsetzungen hin.
Im Folgenden werden wir Ihnen einige Aufgaben stellen, die Sie in der Verwendung des Prototyps umsetzen sollen. Bitte teilen Sie uns währenddessen Ihre Gedanken mit und erklären Sie Ihr Vorgehen.

—– Prototyp-Erklärung —–

—– Aufgabenbearbeitung —–

Vielen Dank, damit kommen wir schon zum Ende des Tests. Wir bedanken uns bei Ihnen für Ihre Hilfe und Ihre Mitarbeit und wir hoffen, mit den erhobenen Daten unser Projekt verbessern zu können.
Wir möchten Sie nun noch darum bitten, wie besprochen den kurzen Fragebogen auszufüllen.

Aufgaben

1. Nutzen Sie die Funktion „Detailuntersuchung“ der Anwendung. Ermitteln Sie damit, wie ein konkretes Problem eines UI-Elements der ePA-Anwendung behoben werden kann.
2. Nutzen Sie die Funktion „Strukturübersicht“ der Anwendung. Ermitteln Sie, wie viele Unterelemente das UI-Element „2021“ in Summe besitzt.
3. Nutzen Sie die Funktion „Komplettüberprüfung“ der Anwendung. Ermitteln Sie damit, wie viele Probleme in der ePA-Anwendung insgesamt festgestellt werden können.

Dokumente

Zusammenfassung der Rückmeldungen in der Heuristischen Evaluation

• Probleme und Fehler beim Mapping der verschiedenen Ansichten und Schaltflächen in Figma
• Prototyp noch sehr rudimentär mit wenigen verschiedenen Interaktionsmöglichkeiten, wenige „Quality of Life“ Funktionen (zu vorheriger Ansicht zurückkehren etc.)
• Sehr „leere“ Anwendung -> viel verschenkter und freier Platz, Anwendung könnte wesentlich kompakter sein
• Nummerierung der einzelnen Elemente und Probleme unklar
• Ersetzung des momentanen überlappenden Layout durch Anwendung mit Overlay-Charakter vielleicht zielführender
• Ziel und Funktion der Anwendung unklar

Link zum Prototype auf Figma

Problem und Hypothese

Problemstellung und Akzeptanzkriterium

Marius braucht eine Möglichkeit, Software auf einfache Art und Weise auf ihre Barrierefreiheit untersuchen zu können, ohne großen Aufwand in Einarbeitung und Erlernen der Funktionalitäten stecken zu müssen.

Wir wissen, dass dies erfüllt ist, wenn jemand mit keinem ausgeprägten Know-How zu digitaler Barrierefreiheit die Oberfläche des geplanten Tools versteht und benutzen kann.

Hypothese

Wir glauben, dass wir durch die Gestaltung einer intuitiven und einfachen Benutzeroberfläche für die Barrierefreiheitssoftware für Marius einen simpleren Workflow für seine Arbeit und damit einen höheren Umfang von digitaler Barrierefreiheit in Software erreichen werden.

Sketches

Storyboard

Alte Inhalte

Eliana needs a way to seamlessly and efficiently interact with her digital devices and the (health) application on them despite her visual limitations.

We will know this to be true when we see a: clear and conclusive guideline on how to develop software in a manner that allows the use of and complete implementation of software assisted accessibility-functions.

Alter Sketch im Drive

Beschreibung zum Sketch:
Resultierend aus den geführten Interviews sind den Beteiligten bei der Nutzung von Screenreadern, welches das meistgenutzte und gängigste Hilfsmittel ist, folgende Problematiken herausgestochen.

1. Bezeichnung der Elemente nicht eindeutig
2. Die Reihenfolge der vorgesehenen Elemente ist irreführend.
   Das Layout bzw. die Zugehörigkeit der einzelnen Elemente ist nicht nachvollziehbar
3. Das Layout ist überfüllt mit zu vielen Elementen, sodass die Navigation und das Vorlesen der einzelnen Elemente schwierig ist.

Wir haben uns bei unserem Sketch an dem Layout der Desktop-Anwendung unserer Krankenkasse orientiert.
Das Layout besteht aus drei Hauptfragmenten, die gegebenenfalls in weitere Fragmente unterteilt sind.

1. Die Titelleiste am oberen Teil d. Layouts
2. Die Obermenü-Leiste am linken Rand
3. Die Detailansicht der einzelnen Menüpunkte auf der rechten Seite
   • Dieses ist wiederum in zwei weitere Fragmente unterteilt.

Unsere Idee ist, die Fragmentierung erstmals in Ebenen zu unterteilen, um die Navigation mit Screenreadern nicht unnötig lang zu machen. Es werden erstmals die Fragmente der ersten Ebene über ihre Titel beschrieben. Sobald mit einem Fragment interagiert, so wird in dieses navigiert und die unterliegenden Elemente bzw. bei weiterer Fragmentierung die Fragmente vorgelesen.

Research

Designing for users of screen readers

https://www.w3.org/WAI/tips/designing/#ensure-that-interactive-elements-are-easy-to-identify

https://m2.material.io/design/usability/accessibility.html

https://medium.com/salesforce-ux/7-things-every-designer-needs-to-know-about-accessibility-64f105f0881b

1. Erstellen einer Persona

Name: Marius Lederer

Alter: 36

Beruf : Informatiker / Selbstständig (Freelancer)

Ausbildung : Fachinformatiker für Anwendungsentwicklung

Biographie: 

Marius Lederer ist ein 36-jähriger Informatiker und Selbstständiger, der als Freelancer arbeitet. Nachdem er seine Ausbildung zum Fachinformatiker für Anwendungsentwicklung absolviert hatte, entschied er sich, sich auf die Qualitätssicherung von Software zu spezialisieren. Er erhält regelmäßig Aufträge über eine Vermittlungsfirma, bei denen er Software im Hinblick auf Usability und allgemeine Stabilität testet. Marius zeichnet seine gründliche Arbeitsweise und sein ausgeprägtes Verständnis für die Bedürfnisse der Benutzer aus. Mit Hilfe seiner Fachkenntnisse und Erfahrungen unterstützt er Unternehmen, Software mit hohen Qualitätsstandards zu entwickeln.

2. Beschreiben eines Szenarios

Marius Lederer sitzt in seinem Büro und bearbeitet seine E-Mails, als er eine Nachricht von seiner Vermittlungsfirma erhält. Die Firma schlägt ihm einen neuen Auftrag vor, bei dem er die digitale Barrierefreiheit einer Anwendung eines Unternehmens überprüfen soll. Marius freut sich über den Auftrag, wird sich aber bewusst, dass er bisher wenig Erfahrung mit diesem speziellen Thema hat.

Um sich optimal auf den Auftrag vorzubereiten, beschließt Marius, gründlich zu recherchieren und nach passenden Tools und Ressourcen zu suchen. Ihm ist bekannt, dass er sich umfassend über aktuelle Standards für Barrierefreiheit und -richtlinien informieren muss, um eine fundierte Überprüfung durchführen zu können.

Während seiner Recherche stößt Marius auf unser Projekt zur digitalen Barrierefreiheit. Es handelt sich um eine Plattform, die Entwicklern dabei helfen soll, die Barrierefreiheit von Anwendungen zu überprüfen und zu verbessern. Die Plattform bietet einige Tools und Ressourcen, darunter automatisierte Prüfungen und liefert gleichzeitig recht ausführliche Berichte.

Marius bewertet die von uns entwickelte Plattform als wertvolle Unterstützung bei der Durchführung seiner Aufgabe. Er beschließt, das Tool zu nutzen, um die Barrierefreiheit der Anwendung zu überprüfen, die er im Auftrag des Technologieunternehmens analysieren soll.

Er ist überzeugt davon, dass er mit den Tools und Ressourcen des Projekts die digitale Barrierefreiheit der Anwendung umfassend bewerten und konkrete Empfehlungen zur Verbesserung geben kann.

Dank seiner gründlichen Recherche und der Nutzung der von uns entwickelten Plattform ist Marius gut vorbereitet, um den Auftrag erfolgreich auszuführen. Er freut sich darauf, seine Expertise in der digitalen Barrierefreiheit einzusetzen und dazu beizutragen, dass die Anwendung für alle Benutzer zugänglich und nutzbar wird.

Ergänzung

In der Arbeit mit der zu überprüfenden Anwendung der Unternehmens verwendet Marius die von uns implementierte Lösung.

Dabei wird die Anwendung auf mögliche Schwachstellen untersucht und gibt ebendiese für Marius aus. Er kann die Probleme sammeln und die vorgeschlagenen Lösungsmöglichkeiten hinsichtlich ihrer Machbarkeit evaluieren.

Anschließend kann Marius je nach Art seines Auftrags, die durch die Software festgestellten Probleme an seinen Kunden rückmelden oder auch an der Behebung der Probleme arbeiten.

Erster (ehemaliger) Entwurf

Anlaufstellen für Teilnehmer

• Deutscher Blinden- und Sehbehindertenverband e.V. (DBSV e.V.)
  • Allgemeiner Blinden- und Sehbehindertenverein Berlin gegr. 1874 e.V. (ABSV e.V.)
    • Telefonnummer: 030/8 95 88-0
    • info@absv.de
• Bundesverband staatlich anerkannter Blindenwerkstätten e.V. (BsaB e.V.)
  • Kontaktformular auf Website
• Sozialheld*innen
  • beratung@sozialhelden.de

Text für Anfrage

Liebe *Kontaktpersonen*,

im Rahmen des Moduls Human-Computer-Interaction des Fachgebiets Informatik an der Freien Universität Berlin forschen wir in diesem Semester zu den Themen der elektronischen Patientenakte und Digitalen Gesundheitsanwendungen.

Unser Projekt beschäftigt sich dabei insbesondere mit digitaler Barrierefreiheit. Zu diesem Thema möchten wir Interviews mit direkt von fehlender Barrierefreiheit betroffenen Personen führen, um Wünsche und Anforderungen zu erfassen und verstehen zu können. Dabei suchen wir vor Allem den Kontakt zu sehbehinderten Menschen, da digitale Anwendungen in Ihrer Konzeption zumeist auf visuellen Aspekten aufgebaut werden.

Zu diesem Zweck wenden wir uns an Sie mit dem Wunsch um Vermittlung von Ansprechpartner:innen in diesem Gebiet oder möglicherweise auch Teilnehmer:innen für die Interviews.

Wir freuen uns darauf, von Ihnen zu hören.

Mit freundlichen Grüßen

i.A. *Absender*

To-Do

• Vorbereitung des Consent Form -> Barrierefreiheit?
• (Abschließende Überarbeitung der Interviewfragen)

Fortschritt für Interviews

ABSV e.V.

• Termin vereinbart (26.05.23 – 10 Uhr)
• Termin bestätigt und Informationsblatt für Datenschutz verschickt

Sozialheld*innen

• Kontaktanfrage abgeschickt – Antwort: „Leider haben wir gerade keine Kapazität pro bono Leute zu vermitteln.“

BsaB e.V.

• Kontaktanfrage abgeschickt

Private Kontakte

• Telefonnummer für eine Person vorhanden – auf AB gesprochen – Rückmeldung ausstehend
• E-Mail an weitere Person versendet – Rückmeldung ausstehend

Überarbeitetes Interview

Einleitung

Willkommen zu diesem Interview. Als Erstes möchten wir Ihnen dafür danken, dass Sie sich die Zeit nehmen, mit uns zu sprechen und somit einen wesentlichen Beitrag zu unserer Forschung zu leisten.

Wir möchten gern noch einmal mündlich in der Aufnahme bestätigen, dass sie der Durchführung dieses Interviews sowie der Aufzeichnung und Verarbeitung der erhobenen Daten gemäß der Einverständniserklärung zustimmen. Sie haben die Einverständniserklärung gelesen und unterzeichnet?

…

Dann können wir fortfahren.

Im Folgenden werden wir Ihnen einige Fragen stellen, die uns dabei helfen sollen, Ihren Umgang mit digitalen Anwendungen im Rahmen Ihrer Sehbehinderung einordnen zu können. Dadurch erhoffen wir uns wertvolle Einblicke und ein besseres Verständnis für Ihre Wünsche und Bedürfnisse in dieser Angelegenheit.

Wir möchten direkt vorweg nehmen, dass wir uns erst seit kurzem mit diesem Thema beschäftigen und bitten dahingehend um ihr Verständnis. Uns ist der respektvolle und sensible Umgang mit Ihnen und Ihrer Sehbehinderung wichtig und wir möchten dahingehend gern auf Ihre Wünsche eingehen.

Dafür möchten wir gern als Erstes von Ihnen erfahren, welche Begriffe im Verlauf des Interviews verwendet werden sollen.

…

Vielen Dank für die Spezifizierung, wir werden das im Folgenden beachten.

Kommen wir nun also zur ersten Frage des Interviews, auf der wir anschließend aufbauen wollen.

Fragen

1. Wie beschreiben Sie die Art und Ausprägung Ihrer Sehbeeinträchtigung?
2. Welche digitalen Anwendungen nutzen Sie in Ihrem Alltag? Damit meinen wir Applikationen, Programme, Internetdienste und Ähnliches.
   • Welche Geräte nutzen Sie für die Nutzung dieser Anwendungen?
   • Welche Betriebssysteme sind damit verbunden?
   • Würden sie gern mehr digitale Anwendungen in Ihr Leben integrieren?
   • Welche technischen Hürden fallen Ihnen dahingehend auf?
   • Haben Sie ein besonders positives Beispiel für eine für Sie sehr gute Umsetzung digitaler Barrierefreiheit für uns? Kennen Sie auch ein Negativ-Beispiel?
3. Welche Hilfsmittel im Umgang mit digitalen Anwendungen wie Apps oder Websites verwenden Sie?
   • Als wie hilfreich bewerten Sie diese Hilfsmittel?
   • Wie verbreitet sind diese Hilfsmittel Ihrer Erfahrung nach?
4. Welche Erfahrungen haben Sie bisher mit digitalen Angeboten im Gesundheitswesen gemacht?
   • Wie bewerten Sie den Einsatz digitaler Angebote im Gesundheitswesen auf Basis Ihrer Erfahrungen?
   • Wie zufrieden sind Sie mit der Barrierefreiheit dieser Angebote?
   • Haben Sie bereits von der elektronischen Patientenakte gehört?
   • Welche Gedanken oder Eindrücke verbinden Sie damit?

Elektronische Patientenakte: Digitale Sammlung der Patientendaten zur individuellen Abfrage und dem Teilen mit Ärzten. Im Januar 2021 eingeführt, im März 2023 Entwurf zum Wechsel von Opt-In zu Opt-Out vorgelegt. Dementsprechend ein Wechsel der Strategie von ausdrücklicher Anmeldung für die Nutzung der Dienste zum gegenteiligen ausdrücklichen Widersprechen zur nicht-Nutzung der Dienste.

Schlussteil

Damit kommen wir zum Ende des Interviews.
Sofern Sie dem in der Einverständniserklärung ausdrücklich zugestimmt haben, behalten wir uns vor, Sie gegebenenfalls zukünftig noch mit weiterführenden Fragen zu kontaktieren.
Bei Interesse können wir Sie außerdem gern über die Ergebnisse unserer Forschung auf dem Laufenden halten.
Vielen Dank für Ihre Zeit und Mitarbeit.

Offene Fragen

1. Consent Form -> Barrierefreiheit
2. Tool für Online-Treffen -> Barrierefreiheit von Webex? Unterstützung von anderen Systemen FU-seitig
3. Respektabler Umgang mit Sehbehinderungen
4. Ansprechen von Anlaufstellen -> Welche Stellen eignen sich? Offizielle Netzwerke oder Arbeitgeber für Sehbehinderte?
5. Spezifizierung der Anwendung? -> iOS/Android/Windows/Linux/Mac

Antworten oder Anmerkungen

1. Consent Form wird von Mitarbeiterin aufgesetzt
2. Zoom bei digitalem Treffen verwenden?
3. Bestätigung
4. Zugang schwierig, verschiedene Richtungen gut, Kooperationspartner von Sozialhelden
5. Vermutlich auf ein OS festlegen

Anforderungen für Anwendungen im Gesundheitswesen (rechtliche Bestimmungen)

Definieren Sie die Ziele Ihrer Data Collection Session.

Im Zuge unserer Datenerhebung möchten wir Erkenntnisse über die Verwendung der ePA und digitalen Angeboten durch Personen mit körperlichen Einschränkungen gewinnen. Dabei interessieren wir uns insbesondere für die Art und Weise der Verwendung dieser Angebote und die Notwendigkeit verschiedener Hilfsmittel dafür.
Ein zentrales Problem bei der Entwicklung von Software ist in diesem Kontext die Gestaltung von Benutzeroberflächen dahingehend, dass diese meist darauf ausgelegt sind, dass Nutzende diese sehen können. Benutzeroberflächen werden nicht explizit für Nutzende gestaltet, die schlecht oder gar nicht sehen können.

Wir möchten deswegen ein Verständnis dafür aufbauen, wie digitale Anwendungen gestaltet werden müssen, um diesen Personen einen angenehmen oder sogar für sie optimalen Umgang damit zu ermöglichen. Dafür möchten wir herausfinden, wie und mit welchen Medien diese Zielgruppe interagiert und ob oder wie sie bereits mit Angeboten wie der ePA in Kontakt getreten sind.

Anschließend möchten wir die Erfahrungen, die im Zusammenhang mit der ePA gemacht wurden, zusammenführen und erhoffen uns vor allem mit dem vorangegangenen Schritt, Konflikte in der Anwendung besser nachvollziehen zu können.

Als nächstes möchten wir erarbeiten, welche Schritte notwendig sind bzw. inwiefern die vorhandenen Funktionalitäten angepasst werden können, um die Benutzung der Anwendung zugänglicher für die Zielgruppe zu gestalten.

Leiten Sie anhand Ihres Ziels die Stakeholder ab, von denen Sie Daten sammeln möchten.

Die primären Stakeholder unseres Projektes sind Menschen mit Sehbehinderungen. Das private Ansprechen einzelner Personen dieser Gruppe trägt nicht zur Erfüllung unserer Ziele bei und wirkt gegebenenfalls abschreckend. Wir befürchten außerdem eine nicht breit aufgestellte Bereitschaft der Zielgruppe für unsere Forschung, da sie möglicherweise als unerwünschte Aufmerksamkeit oder gar als Art der Ausgrenzung ausgelegt werden kann.

Dementsprechend liegt für uns das Kontaktieren übergeordneter Verbände, Vereine oder sonstiger Ansprechpartner nahe, da dort Personen anzutreffen sind, die für uns Kontakte mit bereitwilligen Mitgliedern unserer Zielgruppe herstellen können.

(Weitere) Stakeholder:

Primär:

• Sehbehinderte
• Verbände
• Vereine
• Blindenwerkstätten

Sekundär:

• Krankenkasse
• Ärzte
• Entwickler
• Hersteller von Medizinprodukten

Beginnen Sie mit dem Sammeln von Informationen, ohne Ihre Stakeholder anzusprechen.

Recherchen zu existierenden Bestimmungen zum Thema der Barrierefreiheit digitaler Produkte:

“Europäischer Rechtsakt zur Barrierefreiheit”

“Behindertengleichstellungsgesetz” – Gesetz zur Gleichstellung behinderter Menschen (BGG)

“Barrierefreie Informationstechnik-Verordnung 2.0” – Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (BITV 2.0)

Die Techniker-Krankenkasse veröffentlicht auf ihrer Website eine Selbsteinschätzung ihrer App und bewertet dort die Barrierefreiheit (01/2023).

Der Krankenkasse scheint dementsprechend viel an Barrierefreiheit zu liegen, da regelmäßig Verbesserungen vorgenommen werden und der Umgang damit transparent und öffentlich kommuniziert wird.

Laut Gesetzeslage sind Körperschaften des öffentlichen Rechtes, zu denen auch Krankenkassen gehören, dazu verpflichtet, die Barrierefreiheit ihrer Angebote auch im digitalen Raum zu gewährleisten. Lediglich der Rahmen oder das Ausmaß dieser Barrierefreiheit ist nicht näher definiert.
Eine Unterscheidung von Nutzbarkeit und Nutzerfreundlichkeit ist hier vermutlich notwendig.

Krankenkassen sind zwar wirtschaftlich orientiert arbeitende Organisationen, üben jedoch eine Aufgabe der Daseinsvorsorge aus, nehmen also eine im Allgemeininteresse liegende Aufgabe wahr. Außerdem werden sie vom Staat gesteuert und können als zum öffentlichen Dienst zugeordnet werden.

Für eine weitere Exploration der rechtlichen Rahmenbedingungen von Krankenkassen und Barrierefreiheit ist die Konsultation eines Experten wie beispielsweise eines Anwalts für Medien- und Digitales Recht notwendig.

Recherche zu Vereinigungen von Menschen mit Sehbehinderungen

„Deutscher Blinden- und Sehbehindertenverband e.V. (DBSV)“ ist die nationale Vereinigung in Deutschland. Auf der Website wird auf verschiedene Landesverbände und Organisationen verwiesen.

Allgemeiner Blinden- und Sehbehindertenverein Berlin gegr. 1874 e. V.
Auerbachstr. 7
14193 Berlin
Nähe S-Bahnhof Grunewald

Recherche zu Hilfsmitteln für Menschen mit Sehbehinderungen

Liste mit verschiedenen Hilfsmitteln mit Erklärungen

Analoge Hilfsmittel/Hardware:

• Brailledrucker
• Braillezeilen
• Vorlesesysteme
• Großschrifttastaturen

Digitale Hilfsmittel/Software:

• Screenreader
• Modi für diverse Farbblindheiten
• Modi für hohen Schriftkontrast
• Vergrößerungssoftware
• Sprachausgabe
• Spracherkennungssoftware
• Apps
• Potenzial für DiGa vorhanden, aber bisher keine umgesetzt

Verschiedene Anbieter stellen diese Hilfsmittel zur Verfügung:

Übersicht verschiedener Anbieter von Hilfsmitteln

Bereiten Sie eine Interviewstudie mit Ihren primären Stakeholdern vor.

Stakeholder

Wir möchten für unsere Studie Menschen mit Sehbehinderungen befragen, da sie für die Entwicklung einer barrierefreien Anwendung zur Nutzung der ePA wertvolle Informationen beitragen können, über welche wir ohne ihre Hilfe nicht verfügen.
Um mögliche Kandidat:innen für unser Interview zu finden, möchten wir Verbände von blinden und sehbehinderten Menschen ansprechen, damit wir mit Kontaktpersonen oder Ansprechpartner:innen, die sich dediziert mit dieser Öffentlichkeitsarbeit beschäftigen, zusammenarbeiten können.

Art des Interviews

Wir wissen noch wenig über das Thema und die Verwendung digitaler Produkte durch Menschen mit Sehbehinderung. Um einen möglichst hohen Informationsgehalt und -fluss zu gewährleisten und individuell auf die Antworten der Befragten eingehen zu können, möchten wir die unstrukturierte Form des Interviews einsetzen.

Introduction Session

Willkommen zu diesem Interview. Als Erstes möchten wir Ihnen dafür danken, dass Sie sich die Zeit nehmen, mit uns zu sprechen und somit einen wesentlichen Beitrag zu unserer Forschung zu leisten.
Im Folgenden werden wir Ihnen einige Fragen stellen, die uns dabei helfen sollen, Ihren Umgang mit digitalen Produkten im Rahmen Ihrer Sehbehinderung einordnen zu können. Dadurch erhoffen wir uns wertvolle Einblicke und ein besseres Verständnis für Ihre Wünsche und Bedürfnisse in dieser Angelegenheit.

Fragen und mögliche weiterführende Fragen

1. Wie beschreiben Sie die Art und Ausprägung Ihrer Sehbeeinträchtigung?
2. Welche digitalen Anwendungen nutzen Sie in Ihrem Alltag? Damit meinen wir Applikationen, Geräte mit Bildschirmen, Internetdienste und Ähnliches.
   • Welche Geräte nutzen Sie für die Nutzung dieser Anwendungen?
3. Welche Hilfsmittel im Umgang mit digitalen Anwendungen wie Apps oder Websites verwenden Sie?
   • Als wie hilfreich bewerten Sie diese Hilfsmittel?
   • Wie verbreitet sind diese Hilfsmittel Ihrer Erfahrung nach?
4. Welche Erfahrungen haben Sie bisher mit digitalen Angeboten im Gesundheitswesen gemacht?
   • Wie bewerten Sie den Einsatz digitaler Angebote im Gesundheitswesen auf Basis Ihrer Erfahrungen?
   • Wie zufrieden sind Sie mit der Barrierefreiheit dieser Angebote?

Closing Session

Damit kommen wir zum Ende des Interviews.
Sofern Sie dem in der Einverständniserklärung ausdrücklich zugestimmt haben, behalten wir uns vor, Sie gegebenenfalls zukünftig mit weiterführenden Fragen zu kontaktieren.
Bei Interesse können wir Sie außerdem gern über die Ergebnisse unserer Forschung auf dem Laufenden halten.
Vielen Dank für Ihre Zeit und Mitarbeit.

Einwilligungserklärung

Wir müssen bei der Erstellung unserer Einwilligungserklärung besonders umsichtig vorsehen, da die Interaktion mit unserer Zielgruppe und die Art der für uns interessanten Daten eine Erfassung und Speicherung von Gesundheitsdaten erfordert. Diese Daten fallen in die Kategorie personenbezogener Daten besonderer Art, die einen erhöhten Schutzbedarf aufweisen. Dementsprechend müssen wir stärker darüber nachdenken, wie wir die gesammelten Daten am besten anonymisieren können.

Mögliches anderes Muster für die Einwilligungserklärung:

Art und Weise des Interviews

Wir möchten während des Interviews Tonaufnahmen mitschneiden, um die gesammelten Informationen im Nachgang besser auswerten zu können.

Für die Fragen und die Kommunikation mit den Befragten wird Luis Günther zuständig sein, während Cüneyt Bebek Notizen anfertigen wird.

Planmäßig sollen bei den Notizen die essentiellen Inhalte der Antworten parallel aufgezeichnet werden, jedoch können etwaige Lücken durch die Tonaufnahmen anschließend aufgefüllt werden.

Die Form der Notizen ist noch nicht festgelegt, voraussichtlich werden sie jedoch digital angefertigt, um den Prozess der Auswertung zu vereinfachen.

Insights

---

Humanity-Centered-Design

Humanity-Centered-Design ist ein Ansatz, der die Perspektive im Erschaffen von Software auf eine höher angeordnete Ebene hebt. Hierbei besteht der Anspruch der Designer darin, Probleme im Kontext der Systeme, in denen sie entstehen, zu erkennen und daran zu arbeiten, den Umgang der Menschen damit zu verbessern. Dementsprechend wird der Blick von den bloßen Nutzenden der Anwendung erweitert auf die Gesamtheit der Personen, die von der Software betroffen sein können.

Dabei ist es wichtig, sich der verschiedenen Verzerrungen der eigenen Perspektive bewusst zu werden, die unter anderem durch die eigene politische, wirtschaftliche, geographische und soziale Situation maßgeblich beeinflusst wird.

Wichtige Grundsätze dieses Ansatzes sind hierbei das Fokussieren auf die Gesellschaft als Ganzes, das Erkennen von Kernproblemen, lang anhaltenden statt sofortigen Erfolgen, kontinuierlichem Verbessern und Testen sowie aktives Arbeiten mit den letztendlich Betroffenen.

Unser Projekt wird sich voraussichtlich mit Personen beschäftigen, die gewisse Einschränkungen der visuellen Wahrnehmung aufweisen. Durch den Ansatz des Humanity-Centered-Design ergibt sich dabei für uns im Speziellen, dass wir mit direkt Betroffenen der ePA und unseres Projektes arbeiten. Somit können wir die Wünsche und Bedürfnisse unserer Zielgruppe direkt im Arbeitsprozess einbinden und validieren unsere Arbeit nicht erst im Nachhinein.

Dafür möchten wir zum Beispiel Kontakt mit Blinden- oder Sehbehinderten-Verbänden aufnehmen, um mit unserer Zielgruppe in Verbindung zu treten.

---

Insights

Our project will likely deal with individuals who have certain visual perception limitations. Through the Humanity-Centered-Design approach, the following learnings arise for us:

1. Working with people affected by the ePA and our project and for this purpose, i.e. contacting associations for the blind or visually impaired

What is the challenge you would like to tackle?

The registration and activation of the ePA applications is difficult and sometimes not working at all. There are multiple steps to follow for creating an account and signing up for using the ePA. One of these steps included installing a separate app by a different company to authenticate via a government ID. If one has not went through that process before the ID will need some further configuration.

Additionally, at least one application of a major health insurance company is not working on an „old“ device with Android 8.

We are considering to use the desktop version of one specific ePA application for our project, but maybe we can find another mobile application, that we can use.

Why do you expect your engagement to be useful?
Why is that an interesting problem?

We want to create an easier process for activating the ePA. The current applications seem to be segregating non tech-savvy users. Especially elderly people could be overwhelmed by the process. This group of users can be considered as an integral part of the presumably targeted user group by ePA applications, considering Germany’s demography.

Furthermore, this segregation could be intensified by the application, which is only being able to run on the newest operating systems.

We did not find studies connecting higher age and older android versions, but the relative percentage of android users peaks in the older user groups.

Android devices generally have shorter update and maintenance coverage timespans. Therefore depending on newer OS versions for functional applications either forces users to own the newest devices or not be able to use the applications at all.

https://de.statista.com/statistik/studie/id/71707/dokument/smartphone-nutzung-in-deutschland/

Who are your intended stakeholders?
And who might be the indirect stakeholders?

Given the challenges, the stakeholders benefiting the most would be the direct users, especially with non tech-savvy backgrounds. Elderly people can be considered a significant part of this group.

Indirect stakeholders for our goals would be the people benefiting by a better acceptance of the application and a wider use. This group consists of all stakeholders with the health of users in mind like hospital staff, physicists and emergency service employees.

We do not fully know how the data of the different ePA applications is used for „science“. There could be other parties benefiting from a wider use of the applications as well, like pharmaceutical companies, that want to use the gathered data to earn more money.

Where is your user group interacting with your software?

The main user group we would like to focus on will use the software either on their mobile devices, which can be used in all locations imaginable, or on stationary computers.

When is the user group interacting with your software?

The situations for interacting with the software is the day-to-day process of having health issues. Direct users are expected to access their ePA for managing their digital receipts, documents for and from physicians and paperwork regarding health in general.

The expected time of using the applications is probably during the day, but in fact the users can try to access them anytime.

Reflexion

We did some initial individual research and gathered our findings. We then came together again for writing this blogpost and deciding on how to continue with the project.

We learned that the ePA system holds a high potential of failure or impracticality by the way it is implemented. The decentral and self-sufficient approach results in an ununiform spectrum of usability and performance of the different systems.

In addition, we read of problems with hacking at „Bitmarck“, one service provider of health insurance companies, which is at least one explanation for currently not functional service and ePA applications.

We are not quite sure about our one specific project goal and need to work on that in the future.

There are various possibilities we could concentrate on: the registration process, the availability on different operating systems and their versions or the focus on one specific user/stakeholder group and its needs or wishes.