Testimonials¶
Nachfolgend finden sie einige lesenwerte und erkenntnisreiche Reflexionen früherer HCI-Gruppen.
Viel Spass beim Durchlesen :
Abschließendes Fazit zu HCI und Lessons Learned — SoSe 2026
Das Modul Human Computer Interaction hat uns gezeigt, dass das Entwickeln einer App keine einfache einmalige Programmieraufgabe ist. Vielmehr hat uns das Modul gezeigt, wie viel mehr zu einem solchen Entwicklungsprozess gehört und dass es sich nicht einfach auf das Programmieren und die technische Exzellenz beschränkt.
Ein weiteres Learning, welches uns in so gut wie jedem der 5 Meilensteine vor Augen geführt wurde, war, dass das eigene mentale Modell nicht immer mit dem der Nutzer übereinstimmt. Besonders gilt es dabei, aus eigenen Annahmen nicht auf die der Nutzenden zu schließen. Einige der von uns implementierten Funktionen schienen unserer Gruppe zunächst sehr logisch und schlüssig, stellten sich aber nach dem Test mit Nutzern als missverständlich oder unnötig heraus.
Im User Research wurden unsere Hypothesen, die wir persönlich bejaht hätten, durch das teilstandardisierte Interview widerlegt. Auch bei dem UI-Test wurden Elemente nicht so genutzt, wie wir es erwartet hätten. Dies könnte man dem Papierprototypen zuschreiben, allerdings zeigt auch der Usability-Test mit einem echten Prototypen, dass die App aktuell noch einige Stellen mit Verbesserungspotenzial hat.
Eine weitere Schwierigkeit, vor allem beim User Research, bestand darin, unvoreingenommen und neutral an die Erforschung von Fragestellungen zu gehen. Oft hatte jedes Gruppenmitglied eigene Antworten auf die Fragestellungen. Diese galt es aber in der Vorbereitung zurückzustellen, um neutrale Ergebnisse zu erhalten.
Eine weitere Lesson besteht darin, dass man vor allem nach den Usability-Tests merkt, dass der Entwicklungsprozess iterativ ist. Diese Aussage nimmt man in einer Vorlesung zwar gerne einfach als Fakt hin, aber selbst zu erfahren, dass es immer wieder Probleme gibt und neue Thesen, die es zu prüfen gilt, machen dieses Learning nochmal deutlicher.
Generell lässt sich sagen, dass wir einen anderen Blick auf den Gesamtaufwand eines solchen Projekts bekommen haben. Besonders die Bereiche User Research und Usability-Test waren dabei neu für unsere Gruppe. Trotzdem war es spannend, einen solchen teils anstrengenden und aus vielen Iterationen bestehenden Prozess als Gruppe mitzuerleben und selbst und mit allen Freiheiten und Entscheidungsmöglichkeiten umsetzen zu dürfen.
Abschließend lässt sich sagen, dass es zwar eine anstrengende und anspruchsvolle Zeit gewesen ist, der Lerneffekt dafür aber entsprechend groß war und uns langfristig bereichern wird.
Außerdem hätten wir zu Beginn offener sein können. Es bestand immer eine subtile Angst davor, dass Thesen widerlegt werden oder Features, von denen wir dachten, sie seien wertvoll, es dann doch nicht waren. Aber im Endeffekt hat jede widerlegte These zu einer Erkenntnis beigetragen, mit der die App für Nutzer besser gestaltet werden kann. Auch die Erkenntnisse aus den Usability Tests werden dafür sorgen, dass sich die App sich in weiteren Iterationen noch mehr verbessert.
Allgemeine Lessons Learned zu MS5 — SoSe 2026
Tunnelblick als Entwicklungsrisiko
Über die Dauer des Projekts haben wir als Gruppe eine zentrale Erfahrung gemacht: Je länger man an einer App arbeitet, desto selbstverständlicher wirken die eigenen Entscheidungen. Funktionen, die wir intern als intuitiv und logisch empfanden, wurden von den Testpersonen teilweise gar nicht so wahrgenommen. Was für uns offensichtlich war, musste für Außenstehende erst erschlossen werden.
Dieser Tunnelblick entsteht schleichend. Man kennt die App in- und auswendig, weiß welcher Button wohin führt, versteht den Zweck jeder Funktion und hat die Designentscheidungen selbst getroffen. Dadurch fällt es schwer, die App mit den Augen einer Person zu sehen, die zum ersten Mal damit in Berührung kommt.
Was der externe Blick aufgedeckt hat
Erst durch die Usability Tests wurde sichtbar, wo diese Lücke zwischen unserer Innenperspektive und der tatsächlichen Nutzungserfahrung liegt. Konkrete Beispiele aus unserem Projekt:
Die Sichtbarkeit des Jederzeitfeedbacks für alle Teammitglieder in der Gesprächsagenda war für uns eine bewusste Designentscheidung für Transparenz. Für beide Testpersonen war sie eine unangenehme Überraschung nach dem Absenden. Wir hatten nie in Frage gestellt, ob dieser Mechanismus kommuniziert werden muss; für uns war er selbstverständlich.
Der Pulse-Check wirkte auf uns als klares und nützliches Feature. Für die Testpersonen war unklar, warum er wichtig ist und was das System mit den Eingaben macht. Der Zweck, der für uns im Entwicklungskontext evident war, fehlte für Außenstehende vollständig.
Die bemängelte Informationsdichte insbesondere im Onboarding ist uns nicht bewusst geworden, da wir ja alle Informationen kannten und keine Erfordernis bestand, auf die gebotenen Informationen zuzugreifen. Ferner empfanden wir das Onboarding als geführt und strukturiert. Die Testpersonen dagegen vermissten eine Fortschrittsanzeige und wussten zwischendrin nicht, wie weit sie noch vom Abschluss entfernt waren.
Diese Punkte wären ohne externen Blick nicht aufgefallen. Nicht weil wir sie übersehen hätten, sondern weil sie aus unserer Perspektive kein Problem darstellten.
Usability Test, Usability Inspection und Design Review als kombinierter Effekt
Der Usability Test lieferte qualitative Tiefe: echte Reaktionen, spontane Kommentare und Nutzungsverhalten, das man nicht vorhersehen kann. Die Testpersonen haben Dinge gesagt und getan, die keine interne Diskussion hätte hervorbringen können; gerade weil sie unvoreingenommen an die App herangegangen sind.
Die Usability Inspection und der Design Review durch die Peer-Gruppe ergänzt diesen Blick um eine strukturierte, heuristische Perspektive. Während Testpersonen aus ihrer natürlichen Nutzungserfahrung heraus reagieren, analysiert die Peer-Gruppe systematisch anhand etablierter Kriterien. Beide Perspektiven zusammen decken mehr auf als jede einzeln.
Entscheidend ist dabei, dass die Peer-Gruppe ebenfalls Außenstehende sind; sie kennen unsere Designentscheidungen nicht, haben keine Vorannahmen über den Zweck einzelner Funktionen und beurteilen die App so, wie sie ist und nicht wie wir sie gemeint haben.
Fazit
Usability-Evaluation ist kein Qualitätsstempel am Ende eines Projekts, sondern ein notwendiges Korrektiv gegen den unvermeidlichen Tunnelblick, der sich im Entwicklungsprozess aufbaut. Wir haben gelernt, dass eine App, die sich intern logisch und durchdacht anfühlt, für Außenstehende an entscheidenden Stellen unklar sein kann; und dass man das nur herausfinden kann, indem man echte Nutzer und unabhängige Prüfer einbezieht. Dieses Wissen wird unsere Herangehensweise an zukünftige Projekte grundlegend prägen.