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.

(1) Summarize the project goals, context, and stakeholders

We decided to look at the Flytta app to get a broad overview of it and find areas that could be improved upon. The app in its then state had poor usability. The diary functions were inconsistent and cumbersome to use. It was easy to slip and make errors and too hard to correct them afterwards. Some of the app’s functions were hard to find.
We decided to focus on the diary aspect of the app. Logging things is boring and can be tedious, but provides better insights when done regularly. As a result a diary needs to be easy, intuitive and simple, to allow for users to form a habit of using it.
We used data from Flytta as a starting point, but in the course of the project we shifted our focus from an app for people with Parkinson’s disease, to a more general aid for people who need to take medication regularly and keep a diary for certain things like water or exercise.
In this context we formulated the following problem and hypothesis statements:

Problem Statement:
Gunther needs a way to track his daily symptoms and risk factors as well as medication and daily water intake, because they can give him new insights into the nature of his disease. We will know this to be true when we see regular high quality data recorded in the app.

Hypothesis Statement:
We believe that by giving Gunter an easy to use diary app that builds a use habit, we will achieve high quality data which can be used to give him better and more helpful insights.

The direct stakeholders are people who benefit from logging their risk factors and medication. There are many indirect stakeholders of a diary function: health insurers, doctors, care workers, relatives, politicians, etc..
On the basis of our statements and user research we created a persona and scenario and the requirements for the app.
We used those for a storyboard, sketches, lo-fi, and finally hi-fi prototyping, refining the functionality and deciding on which requirements to implement based on testing after each stage.
Finally we prepared and executed usability testing, with outsiders to the project to gain new insight and a different perspective.

(2) Summarize your test results.

The testers were asked to think aloud as they work on the tasks, and we documented those thoughts and their feedback.
We timed each task but the values were influenced more by the thinking aloud process and commenting on the design than the actual task execution times, so we didn’t evaluate the measurements any further.
We used a single ease question answered after each finished task to measure satisfaction.

We chose to evaluate the following five tasks:

Task 1 – Please add a glass of water.
SEQ Average: 7
Feedback:

• Glass Sizes not clear
• Info Icon not interactive, one extra step required -> might be unnecessary 
• People could associate log with maths

Task 2 – Please log a medication you have taken.
SEQ Average: 6,3
Feedback: 

• Design not consistent with the Calendar
• The display of the time is misleading 

Task 3 – Please view your water consumption statistics.
SEQ Average: 6,7
Feedback:

• Water Intake not Consumption 
• Multiple ways to access was appreciated 

Task 4 – Please view your medication statistics.
SEQ Average: 5
Feedback:

• Difficult to find 
• Overview not clear and confusing
• No real value of the graphic
• Confused over headlines (change the word diary)
• Connection on the front page was requested

Task 5 – Please check your medication schedule for today and tomorrow.
SEQ Average: 5
Feedback:

• The calendar had no information on the first page
• Not easy to find
• Time for the medication not visible 
• Confusion about the amount of pills that should be taken
• Takes 3 steps to really see your medication plan -> should be less

The prototype still a many smaller errors and issues to consider like for example:

• Water Intake instead of Water Consumption
• Changing the word diary in the medication overview
• Changing logging because of the resemblance to maths

The medication schedule and the medication logging function are very similar in many ways, but not quite the same. They need to be more consistent and either integrated into one function or two more clearly different functions.
The graphs we have for evaluating the different logs, especially the medication log, need more consideration, as they offer little information at the moment.
The calendar is hard to find and is only integrated into the medication part of the diary and not with the other functions, which is quite inconsistent and needs work.

(3) Compare your results with the defined problem (problem statement) you wanted to solve.

We have made significant progress toward our goals from where we started. The diary functions for tracking water or medication and finding the visualisation of past records worked well in the evaluations. 
Our visualisations are fairly basic both in terms of method and amount of factors visualised. The insights that can be gained from them are limited and not sufficient enough for understanding the nature of an underlying disease. 
Without longer term testing we can’t evaluate how regular the data recording would be, or whether the user would form a habit of recording things. We haven’t implemented any mechanisms to directly promote habit building, other than making the diary as easy to use as possible and notifying the user about due medication.

Our next step would be to implement our takeaways from usability testing: resolving errors that were found in the design, designing a new, possibly unified, medication schedule and logging page and increasing calendar functionality.
To continue this project we would need to do more research on how to visualise the data, to allow insights and how to help users build a habit of using the app.
We would need a first implementation of the app to be able to evaluate habit building and use over time.

(1) Summarize the project goals, context, and stakeholders

Wir hatten uns als Ziel gesetzt, eine App zu erstellen, mit der es möglich ist, Krankenkassen hinsichtlich ihrer angebotenen ePa zu vergleichen. Die Handhabung der App sollte dabei auf dem “Swiping” Prinzip von Datingapps wie Tinder basieren. Es sollen also verschiedene Thesen präsentiert werden, denen die nutzende Person zustimmen, sie ablehnen oder sich enthalten kann. Beim finalen Namen haben wir uns für “MediMatch” entschieden.
Auf das Thema sind wir gestoßen, da sich der Kurs in diesem Semester mit der elektronischen Patientenakte (ePA) sowie Digitalen Gesundheitsapps (DiGas) beschäftigt hat. Zur Auswahl der Projekte standen dann ebendiese beiden Hauptthemen. Nachdem wir uns zunächst darüber informiert hatten, welche ePA Anbieter es gibt um uns eine davon auszusuchen, bekamen wir die Idee, diesen Vergleichsprozess in einer sinnvollen Art unterzubringen. Von der ursprünglichen Aufgabe eine bestehende Oberfläche zu vergleichen kamen wir somit etwas ab, was nach Rücksprache aber kein Problem darstellte.
Stakeholder sind bei uns neben den Designer*innen und Entwickler*innen insbesondere Nutzende, die gerade ihr 25. Lebensjahr abgeschlossen haben und damit aus der Familienversicherung ihrer Krankenkasse rutschen. Im weiteren Sinne sind Stakeholder bei uns außerdem die Krankenkassen selbst, da es natürlich in deren Interesse ist, Mitglieder zu halten oder zu gewinnen, und deren Angebot sich in der App widerspiegelt.
Als weitere, indirekte, Stakeholder haben wir beispielsweise die Datenschutzbeauftragte, oder Werbetreibende, welche mit den Krankenkassen zusammenarbeiten.

(2) Summarize your test results.

• What method(s) did you use to evaluate the results of your usability tests?
  Wir haben uns für ein “User Experience Questionaire” (UEQ) entschieden, um Feedback festzuhalten. Dieses haben wir ausfüllen lassen, nachdem der*die Tester*in unsere fünf Tasks durchgearbeitet hat:
  
  1. Tutorial
  2. Start der ePA Suche
  3. Infotaste
  4. Zurücktaste
  5. Test bis zum Ende
  
  Währenddessen haben wir mündlich gegebenes Feedback mitgeschrieben.
  Insgesamt hatten wir vier Tester*innen.

• How did you evaluate the results?
  Für das Auswerten betrachten wir erst die Zeit und das gegebene Feedback pro Task und am Ende den Durchschnitt des UEQs.
  
  
  • Task 1: Absolviere das Tutorial von MediMatch
    • Durchschnittliche Zeit: 2.25 Minuten
    • Mündliches Feedback:
      • “deine” groß schreiben
      • Beispieltext besser schreiben
      • Buttons schrittweise oder alles?
      • Nach dem ersten Drücken gemerkt wie es geht
      • Nach dem ersten Drücken erst verstanden
      • “Weiter Button” im Tutorial
        
        
  • Task 2: Starte die ePA Suche
    • Durchschnittliche Zeit: < 1 Minute
    • Mündliches Feedback: /
      
      
  • Task 3: Verwende die Informationstaste für zusätzliche Informationen zur Frage
    • Durchschnittliche Zeit: < 1 Minute
    • Mündliches Feedback: /
      
      
  • Task 4: Verwende die Zurück-Taste um deine Antwort zu überarbeiten
    • Durchschnittliche Zeit: 1 Minute
    • Mündliches Feedback:
      • Beim Neustarten wieder auf die Landing Page
      • Man sieht nicht, was man ausgewählt hat
      • Bei letzter Frage geht es nicht mehr zurück
        
        
  • Task 5: Führe den Test bis zum Ende durch um dein Ergebnis zu erfahren
    • Durchschnittliche Zeit: 3.75 Minuten
    • Mündliches Feedback:
      • Infobuttons
      • Mediplaner besser erklären
      • Proaktivere Fragen
      • Informationshintergründe und Datenschutz besser darstellen
        
        
  • UEQ:
    • behindernd 1  5.50   7   unterstützend
    • kompliziert 1 6.75   7   einfach
    • ineffizient 1 5.25   7   effizient
    • verwirrend 1 6.75   7   übersichtlich
    • langweilig 1 3.75   7   spannend
    • uninteressant 1 5.25   7   interessant
    • koventionell 1 4.00   7   originell
    • herkömmlich 1 4.75   7   neuartig

• What did you learn from the testing? What are your main takeaways? Please list these takeaways.
  Wir haben vor allem gelernt, dass wir das Design noch anpassen können. Es wird auch nach der Anpassung nicht originell, aber das war zu erwarten. Der main Takeaway hier ist, dass wir im Tutorial klarer machen sollten, wie das gesamte Layout funktioniert statt Knöpfe nacheinander einzuführen. Die Fragen/Thesen und ihre Beschreibung bedarfen auch Überarbeitung.
  Was uns gut gelungen ist, ist eine einfache und übersichtliche Oberfläche zu schaffen, wie die Ergebnisse des UEQs zeigen (jeweils 6.75 von 7 möglichen Punkten).
  Dass es dabei langweilig ist (3.75 Punkte) haben wir in Kauf genommen, um es simpel und minimalistisch zu halten.

(3) Compare your results with the defined problem (problem statement) you wanted to solve.

• To what extent have you been able to meet your goals? Discuss it.
  Unser Ziel haben wir nur teilweise erreicht. Aufgrund der Einschränkungen von Penpot (fehlende Logik, hohe Redundanz der Screens) ist ein tatsächlicher Vergleich aktuell nicht möglich. Außerdem fehlen tatsächliche Infos der Krankenkassen sowie Links zu weiterführenden Quellen wie den Websites der KK.
  Was wir aber geschafft haben, ist ein Prototyp für ein sinnvollen Design, bei dem noch leichte Änderungen erfolgen müssen. Die Idee sowie die aktuelle Umsetzung wurde den den Testenden positiv aufgenommen, wir sind also auf dem richtigen Weg.

• What would be your next steps? How would you proceed with this project?
  Unsere nächsten Schritte wären es, den Prototypen anhand des gesammelten Feedbacks zu verbessern. Im Anschluss würden wir eine neue Testrunde starten, und das neue Feedback wieder einfließen lassen. Dabei würden wir einen tatsächlich funktionierenden Prototypen bauen. Das bedeutet für uns, dass wir weg von Penpot hin zu Code wechseln. Hauptgrund ist, dass es bei Penpot aktuell nicht möglich ist, Logik einzubauen. Allerdings brauchen wir auch irgendwann ein Produkt, dass deployed werden kann.
  Sobald dieser neue Prototyp steht, sollten wir uns Gedanken über die Finanzierung machen und ggf. Werbepartner finden. Dabei schließen wir Krankenkassen als Sponsoren aus, um unabhängig zu bleiben. Möglicherweise können wir mit Geldern vom Bund gesponsort werden.
  Gleichzeitig brauchen wir Kontakte zu den Krankenkassen, um rechtliche Sachen wie Urheberrechte, aber auch inhaltliche Fragen, wie Antworten auf die Thesen zu klären.

(1) Summarize the project goals, context, and stakeholders

The German government introduced the ePA (electronic health record) in order to digitise the health system. This could lead to more control of the patients over their data, better communication between doctors and patients, avoid doing tests and diagnosis again and again. Overall, the hope is to make the health system more efficient and transparent.

The ePA is to be implemented by all health insurances individually. Since all three of us are insured at the Techniker Krankenkasse (TK), we chose to improve the usability of the ePA of the TK, from now on referred to as the TK-ePA.

During the first weeks of the course we evaluated the TK-ePA by inspecting it under different conditions. We found especially worrying that it did neither handled large text well nor provided a mode/UI that’s simpler and more accessible.

We decided to design a UI for the TK-ePA that is more accessible without compromising in functionality. It was planned as a mode that can be turned on and off because its design will most likely be very simplistic and not meet design expectations of other users.

The TK-ePA is an app that is potentiality used by every TK insured person in Germany. It will also be used in many different contexts, environments, devices and situations.

The stakeholders of our accessibility mode are people who struggle to use the standard UI due to vision or motor impairments. A common problem is the awareness of such modes. This might be overcome by the device checking for specific usage patterns and then suggesting to use the accessibility mode.

(2) Summarize your test results.

As we iteratively designed the TK-ePA we also repeatedly evaluated the UI.

We started developing a variety of lofi prototypes/storyboards (https://blogs.fu-berlin.de/hci2023/2023/06/06/a6-t4-developing-first-prototypes/ ). Feedback from the tutorial session helped us to decide on one of the storyboards and turn it into the first interactive prototype (https://blogs.fu-berlin.de/hci2023/2023/06/13/a7-t4-low-fidelity-prototype/ ).

Two task flows were evaluated using heuristic evaluation in the tutorial session:
1. Share a document to a doctor and 2. finding ones a specific vaccination.

The feedback we received was mostly concerned about the level of detail of the sharing flow. In this first prototype it was not possible to select with whom one shares a document. But the most important feedback was that the hierarchy of documents in our screen navigation did not make much sense to the evaluators.

The third and last evaluation was done by members of the HCI research group. We improved our document hierarchy and added more detail and a third task flow to the test. Also we decided to use the NASA-TLX to capture the users experience.

During the test it so happened that after the very formal introduction, we switched back and forth between the formal evaluation and an informal feedback conversation. This was very helpful due to the depth and detail of the informal feedback.

Dump of Informal feedback:

• Gender consistently
• List why Doctor needs the document
• Document preview when sharing
• Sharing Icon suggests that it is already shared ( a bit unclear)
• NASA-TLX only once after all 3 tasks (tasks very quick)
• NASA-TLX not the best questionnaire here
• Design of search field (shadow to the inside not outside)
• Document type as a dropdown instead of many different buttons
• higher contrast
• more 3d-like buttons
• emergency profile: Blutgruppe on first Level

Evaluation of NASA-TLX:

After we changed the strategy regarding NASA-TLX, where test subjects now filled the form after finishing all tasks, we were able to draw the following feedback from the form inputs:

• Low levels of mental stress
• Low levels of physical activity
• Not a lot of time needed for completion
• Subjects were happy with their performances
• They felt confident within the task process

One has to keep in mind, that as already mentioned in the informal feedback, that the tasks themselves, where somewhat short.
As such test subjects felt that the tasks might not be challenging enough to require the type of scales that NASA-TLX provides.
As such our main takeaway for the Evaluation is that NASA-TLX has not been very useful to gather better insights.

(3) Compare your results with the defined problem (problem statement) you wanted to solve.

Unfortunately, we did not conduct an A/B test comparing the original vs our UI with testers that are actually in need of such a simplified interface. Thus, we cannot really state that our interface is indeed easier to use for people with visual or motor impairments.

But during the tests it became clear that the tasks were (maybe a little too) easy to fulfil. We did not measure the time it took to complete the given tasks, an oversight on out part.

The task completion rate is looking quite good: All tasks were completed without help.

The informal feedback was more helpful for us: Many things in our interface, like the navigation hierarchy and the choice of icons and labels, are still not clear. The test setup was also not optimal especially because the tasks were very easy and the NASA-TLX was used to often and took to long.