Da unsere Gruppe bei dem Termin nicht anwesend sein konnte, konnten wir die summative Evaluation und Analyse nicht durchführen.
(2) Project description
One image (1000x500 px, png), which shows your prototype
One image (200x200 px, png), which shows some unique part(s) of your project or prototype in a very detailed way (e.g., some logo or part of a screen)
Name of your project + tagline/sub-line
Go Walkies! – Have even more beautiful walkies
Name of all group members (with info of university, study program – just if you want!)
Aljoscha Peters, Master of Desaster
Ailis Oßwald, Master in Computer Science at Freie Universität Berlin
Johanna Charlotte Pfannschmidt, „Bachelor Informatik“
Project description text
We are united by our love of animals. We therefore decided to programme an application that would make everyday life with pets easier and, above all, more beautiful.
Motto:
We all have programming and project experience. Since Hanna and Aljoscha have already created websites, we decided to create a web application. And with Ailis being a trained project leader the group was organized.
The goal for the prototype is to be able to choose walking routes, reschedule them, connect with other dog owners and form a (social) network. The prototype offers a choice of different routes by duration. Furthermore, you should be able to save routes, see how often you have walked certain routes and add notes. Under the functionality „Buddies“ you can save your friends‘ data, see who is nearby and add private notes. Our web application is designed in such a way that you can access any feature in any view via the menu bar. The next step would be to implement a working route planning feature and add actual data.
3-5 additional images
We had to „warp“ the images because we were not sure which one were free to use and which not.
(this is non-public repo – because of non-public usable images, Alexa Schlegel is available to access the repo.)
(3) Reflexion
Wer hat welchen Beitrag geleistet?
Wir haben gemeinsam den Blogpost erstellt. Dabei haben wir uns gemeinsam für die Bilder entschieden und Aljoscha hat die Bilder ins passende Format gebracht.
Was habt ihr gelernt?
Wir haben gelernt, dass Cryptpad das Semester über etwas instabiler geworden ist.
Zudem haben wir gelernt, dass das Institut nicht die nötigen Tools für die Veranstaltung zur Verfügung stellt. Dadurch entstand teilweise erheblicher Mehraufwand.
Was lief gut?
Unsere Teamarbeit lief sehr gut.
Was möchtet ihr verbessern?
Da wir am Ende des Semesters sind, wollen wir uns ab jetzt nur noch auf die Klausur(vorbereitung) konzentrieren.
Wäre der Prototyp ein Projekt, welches weitergeführt werden sollte, müssten wir nochmal ein paar der gefundenen Probleme aus der heuristischen Evaluation lösen.
Insgesamt hätten wir uns gewünscht, einen größeren Überblick am Anfang des Semesters zu erhalten zum umzusetzenden Projekt. Beispielsweise ist es wichtig zu wissen, dass man Bilder hier (öffentlich) zur Verfügung stellen soll. So muss man dann auch beim Prototyping auf entsprechende Rechte achten, wenn man keine eigenen Bilder erstellen möchte.
Gruppe 2 hat bei uns 17-19 Makel festgestellt, die folgenden erschienen ihnen am Wichtigsten:
Link zur Startseite mit Logo (links oben) ist nicht offensichtlich, die User wussten nicht direkt, wie sie zurück zur Startseite gelangen.
wie vorgeschlagen, werden wir das Wort „Startseite“ hinzufügen
anschließend werden User erkennen, dass das Logo (und das Wort „Startseite“) im Kasten zur Homepage zurückführen
Bei den „Buddies in meiner Nähe“ war den Usern unklar, ob das noch „meine“ Buddies sind, oder ganz andere Leute. Das hat die Nutzenden sehr verwirrt.
um dieses Missverständnis zu klären, werden die Buddies auf dieser Seite nur „User“ genannt
die Änderung sollte helfen, dass unsere User wissen, sie müssen nicht mit den Usern auf dieser Seite befreundet sein, damit sie hier angezeigt werden
Top5-Buddies Seite ist nicht richtig verlinkt von der Startseite aus. Dieses ist nur ein kleiner Makel und typisch für einen Prototypen in diesem Stadium.
die Top5-Buddies Seite ist der Start der Buddiesseiten und sollte daher von der Startseite erreichbar sein, dieser Link wird einfach getauscht
anschließend sind die User nicht mehr verwirrt, wenn sie von beiden Menüs auf dieselbe „Startseite“ gelangen
Menüfarben vom Sidemenü passen nicht zu den Farben im Header. Das ist eine subjektive Meinung und hat keine maßgebende Severität.
dies werden wir vielleicht nicht ändern, da ein buntes Sidemenü doch sehr aufdringlich ist
Schriftfarben stimmen nicht auf allen Seiten überein, das soll aber nicht weiter schlimm sein. Das werden wir überprüfen und uns auf eine Schriftfarbe einigen, die überall benutzt wird
mit einheitlichen Schriftfarben sollte es zu keinen Unstimmigkeiten beim Anblick unseres UserInterfaces mehr kommen
Wir werden folgende dieser von der Gruppe 2 dargestellten Probleme in Angriff nehmen.
Link zur Startseite ist jetzt beschriftet mit „Startseite“
Verlinkungen auf der Homeseite sind für Buddy-Seiten da
einheitliche Überschriften auf jeder Seite
(2) Preparation for a summative evaluation
1. What are things you would like to do differently this time?
Wir haben nach den letzten Evaluationen festgestellt, dass unsere Aufgaben nicht sehr genau waren und sie gerne etwas mehr aufteilen wollen (siehe Assignment 6). Inzwischen können wir sogar noch Aufgaben hinzufügen, wie wir es für die Heuristic Evaluation (Assignment 8) getan haben. Mit unserer Aufteilung der Rollen für’s Usability Testen waren wir sehr zufrieden.
Testperson: Datum: Beginn / Startzeit: Ende / Endzeit: Max. Zeit:
(1) Einführung
Vorstellungsrunde + Aufgabenerklärung Wir testen die App – oder genauer, einen digitalen interaktiven Prototypen. Wir testen nicht dich! Wir nehmen zur nachträglichen Auswertung die digitale Testung auf. Die Aufzeichnung bleibt bei uns intern und wird direkt nach der Auswertung gelöscht. Es wird nur das Audio aufgenommen. Du selbst bist nicht zu sehen. Stelle gerne Fragen! Ich kann aber nicht versprechen, alle Fragen direkt zu beantworten!
(2) Kontext der Anwendung erklären
GoWalkies ist eine WebApp mit der es möglich sein soll, Gassirouten zu planen. GoWalkies bietet dazu an, vorgefertigte Routen auszuwählen und zu verändern. Im Rahmen dieses Usability Test möchten wir die Schnellroutenplanungs-Funktion (anhand unsere digitalen Papierprototypen) testen und Feedback dazu einholen.
(3) Szenario(s)
Du kommst nach einem langen Arbeitstag im Büro (vor dem Rechner und über Akten) nach Hause und hast wenig Zeit, denn deine zwei Kinder und dein/e Partner/in warten auf Dich und erwarten, dass Du am häuslichen Familienleben teilnimmst. Dein zweijähriger Schäferhund braucht aber auch Auslauf – und Abwechslung. Denn Du hast selbst höhere Ansprüche, wenn man sich ein Haustier anschafft. Deshalb willst Du eine halbe Stunde raus mit dem Hund und es soll nicht jedesmal die gleiche Route sein.
Da Deine Zeit so knapp bemessen ist, darf die Planung nicht länger als 15 Minuten dauern.
Du setzt dich also an den Essenstisch im Wohnzimmer,
öffnest deinen Laptop,
den Browser,
tippst die Adresse der Webseite von GoWalkies ein,
meldest Dich an und
legst los mit der Planung.
(4) Aufgaben
Aufgabe 1: Erstelle dir ein Konto (Daten werden nicht gepeichert, man kann sich aber durchklicken)
Aufgabe 2: Melde dich an
Aufgabe 3: Finde eine max. 30min lange Route
Aufgabe 4: Finde heraus, wie oft du bestimmte Routen bereits gelaufen bist.
Aufgabe 5: Finde heraus, wer die Hunde von Martin sind und was er über sich und seine Hunde schreibt.
Aufgabe 6: Melde dich ab
(5) Post evaluation skript
Questionnaire
Please answer the following questions. Tick the circles that best describes your answer. Please do not leave any question blank.
1. Do you have one or more dogs? O Yes O No
2. How would you rate yourself in the following domains?
novice
expert
Using digital devices
O
O
O
O
O
O
O
O
O
O
Using and navigating websites
O
O
O
O
O
O
O
O
O
O
For each word below, please indicate how well it describes the app.
Describes the app very poorly
Describes the app very well
Accurate
O
O
O
O
O
O
O
O
O
O
Annoying
O
O
O
O
O
O
O
O
O
O
Helpful
O
O
O
O
O
O
O
O
O
O
Interesting
O
O
O
O
O
O
O
O
O
O
Likable
O
O
O
O
O
O
O
O
O
O
Easy
O
O
O
O
O
O
O
O
O
O
Satifying
O
O
O
O
O
O
O
O
O
O
Frustrating
O
O
O
O
O
O
O
O
O
O
Good naming and labeling
O
O
O
O
O
O
O
O
O
O
Relevance of images
O
O
O
O
O
O
O
O
O
O
Good look and feel
O
O
O
O
O
O
O
O
O
O
(6) Abschluss
Hast Du weitere Fragen oder Anmerkungen? Vielen Dank für Deine Teilnahme! Du hast uns sehr geholfen.
Consent Form
Einwilligungserklärung
Einwilligungserklärung gemäß DSGVO in die Verarbeitung von Daten durch die Entwickler*innen von GoWalkies! Für unsere Erhebung erfolgt die Verarbeitung folgender personenbezogener Daten:
Pseudonymisierte Zuordnungen zwischen ID und Antwortbogen
Pseudonymisierte Antworten
Die oben genannten Daten werden zum Zweck einer Produktverbesserung erhoben und zudem auf den Servern von der TU Berlin gespeichert. Die Daten können nur von berechtigten Personen eingesehen und bearbeitet werden. Sollten weitere Daten benötigt werden, braucht es dafür separat wieder die Zustimmung des Nutzers. Eine (automatische) Löschung der erhobenen Daten erfolgt nach 2 Monaten.
Widerrufsrecht
Der Unterzeichnende hat das Recht, diese Einwilligung jederzeit ohne Angabe einer Begründung mit Wirkung für die Zukunft zu widerrufen. Hierfür genügt eine E-Mail an max@maxmustermann.de. Die Rechtmäßigkeit der aufgrund der Einwilligung bis zum Widerruf erfolgten Verarbeitung wird durch den Widerruf nicht berührt.
Folgen des Nicht-Unterzeichnens
Der Unterzeichnende hat das Recht, dieser Einwilligungserklärung nicht zuzustimmen – da unsere Evaluation jedoch auf die Erhebung und Verarbeitung der zu Anfang genannten Daten angewiesen ist, würde eine Nichtunterzeichnung eine Inanspruchnahme des Dienstes ausschließen.
Zustimmung durch den Betroffenen
Hiermit versichert der Unterzeichnende, der Erhebung und der Verarbeitung seiner Daten zum Zweck einer Produktverbesserung freiwillig zuzustimmen und über die Datenverarbeitung und seine Rechte belehrt worden zu sein:
(1) Continue to improve your high-fidelity prototype
Unser Prototyp ist bereits testbar und wir haben letzte Woche schon gut vorarbeiten können. Wir belassen unseren Prototypen daher so, wie er ist. Wie zuvor ist er unter folgendem Link zu finden und herunter zu laden.
Wir fügen lediglich noch die Funktion hinzu, Routen starten zu können (ans Handy senden/drucken)
Aufgabe 1: Erstelle dir ein Konto (Daten werden nicht gepeichert, man kann sich aber durchklicken)
Aufgabe 2: Melde dich an
Aufgabe 3: Finde eine max. 30 min lange Route
Aufgabe 4: Finde heraus, wie oft du bestimmte Routen bereits gelaufen bist.
Aufgabe 5: Finde heraus, wer die Hunde von Martin sind und was er über sich und seine Hunde schreibt.
Aufgabe 6: Melde dich ab
Please use an (online) form to collect the violations by each evaluator in a systematic way.
Wir haben und für das Goolge-Template entschieden. Die Skala und Auswahl der einzelnen Heuristiken von Nielsen finden wir passend und benutzen das so. Wir wählen die Methode außerdem, da sie bereits gut ausgetestet und bekannt ist.
anschließend den mit Rechtsklick über „Teilen“ den Link zum Bild kopieren und ins GoogleSheet einfügen ODER einen eindeutigen Dateinamen vergeben und ins GoogleSheet einfügen
Phase 2: Evaluate (Individual Inspection)
Documentandreflection
Zur Evaluation haben wir folgende Infos aus den Vorlesungen genutzt:
Hints for a „good“ evaluation
grounded in known usability guidelines
justify each problem by appealing to a heuristic and explain how it violates
list every problem separately
inspect the interface at least twice
Document Evaluation (Aljoscha)
Ich habe die Nr. 1 genommen als Evaluator-Nr.
Der von der Gruppe geschickte Link zum Prototyp auf Figma funktionierte nicht. Dadurch wurde ich zeitlich ausgebremst und muss nun wieder umplanen.
Die Gruppe nutzt Nielsens Heuristiken. Deshalb habe ich die Folie der Vorlesung als Grundlage genutzt.
Weiterhin habe ich die Tipps für eine „gute“ Evaluation herangezogen.
Die Eingabe habe ich über das bereitgestellte Google Formular erledigt.
Bei der Aufgabenbearbeitung ist aufgefallen, dass die Aufgaben teilweise unpräzise gestellt wurden, sodass ich ein wenig raten musste, was von mir gewollt wird. Die Aufgaben waren z. T. nicht der UI entsprechend gestellt.
Issues sind teilweise mehreren Heurstiken zuordnenbar.
Teilweise ist es schwierig, kurz und prägnant die Issues zu beschreiben – sonst wären es „Romane“ geworden.
Der Prototyp war in Teilen nicht fertig, um alle Heuristiken anwenden zu können (Favoriten adden, …).
Ich habe das Interface zwei Mal untersucht.
Ich habe nach 60 Minuten aufgehört.
DOcument our Evaluation (Hanna)
Da die Gruppe 2 ähnlich arbeitet, wie Unsere, war es sehr einfach, sich in der Aufgabe zu orientieren. Sie haben uns ein CryptDrive File-Link geschickt, in dem die Aufgaben standen und der Link zum Google Sheet.
Nielsens Heuristiken waren mir bereits bekannt, trotzdem war es nicht immer einfach, jedem Issue eine Heuristik zuzuordnen. Die Heuristiken sind schließlich sehr speziell und zum Beispiel eine Fehlplatzierung von Textfeldern passt zu keiner perfekt.
Die Screenshots haben wir alle erst bei uns gespeichert, da uns nicht gesagt wurde, welches zusätzliche Tool wir dafür benutzen sollten. Im Anschluss haben wir dann die Bilder alle in einen Ordner hochgeladen, die Gruppe muss dann die Bildernamen selber zuordnen.
Nachdem ich die gestelleten Aufgaben erledigt habe (wobei es zwischendurch ein Missverständnis gab, dass mir meine Gruppenmitglieder parallel erklärt haben), habe ich mir noch ein wenig den Prototypen allgemein angesehen. Mir fiel auf, dass man nicht von jeder Seite eigentlich erreichbare Seiten anklicken kann oder der Home-Button nicht immer klickbar ist. Das werde ich dann in Phase 3 (Discussion) ansprechen, es ist aber eben auch noch ein Prototyp.
Document Our evaluation (Ailis)
Auch diese Gruppe hat die Nielsens Heuristiken genutzt, was das Evaluieren einfacher gemacht hat, da ich bereits etwas vertraut war mit den Heuristiken.
Während des Lösens der Aufgaben habe ich das Interface untersucht und dabei evaluiert wie einleuchtend mir das Design dabei erscheint
Ich habe alle Aufgaben gelöst und dabei Screenshots gemacht und mit dem provideten Google Formular Issues gesammelt
jedes Issue habe ich einzeln gesammelt und erklärt, auch wenn es sich um denselben Button handelte
ich habe versucht möglichst konstrukives Feedback zu schreiben und dabei auch Sachen die mir gut gefallen haben hervorzuheben
Allerdings hat die Gruppe keine Möglichkeit bereitgestellt Screenshots hochzuladen, was das ganze etwas erschwert hat
(1) What framework or tools are you going to use? Why?
Wir haben uns auf das Framework Bootstrap geeinigt. Einen hi-fi Prototypen oder eine WebApp mit Bootstrap zu implementieren, ist geht relativ schnell. Zum einen ist es ein ausgereiftes Framework für das GUI, das sich leicht mit beliebigen Frameworks für den funktionalen Unterbau kombinieren lässt, zu nennen wären bspw. phalconphp oder Laravel, bzw. mit vielen für das Web gedachte Sprachen, wie bspw. Dart, Ruby on Rails oder Java. Weiterhin gibt es mit jQuery eine direkte Implementierung, um auf der Seite der Nutzer Funktionalitäten in JavaScript sicher und schneller umzusetzen. Die langfristige Etablierung des kostenfreien Frameworks Bootstrap am Markt sowie dessen Beliebtheit führen zu einer umfassenden Dokumentation – durch die Entwickler:innen selbst -, aber auch zu einer Vielzahl von Code-Schnipseln und How-tos für auftretende Probleme und deren Lösungen. Weiterhin gibt es dadurch für mögliche weitere zu nutzende Webtools (Karten, weitere Bibliotheken u.v.a.m.) auch Anleitungen zur Einbindung in Bootstrap selbst durch deren Entwickler:innen.
Für die Einbindung von interaktiven Karten schwanken wir zwischen openstreetmap (OSM) und Google Maps. Ein erster Test zur Einbindung mit OSM schlug fehl. Die Dokumentation ist veraltet; im Wiki wird auf Schaltflächen verwiesen, die es im UI nicht (mehr) gibt. Eine Einbindung zur Realisierung von Routenplanungen muss mit Web-Frameworks Dritter umgesetzt werden, die auf weitere Tools anderer Entwickler:innen aufsetzen. Trotz der Registrierung bei allen Anbietern konnte das „einfache Beispiel“ – so die Entwickler:innen – nicht zum Laufen gebracht werden.
Testperson: Datum: Beginn / Startzeit: Ende / Endzeit: Max. Zeit: 30minuten
(1) Einführung
Vorstellungsrunde + Aufgabenerklärung
Wir testen die App – oder genauer, einen digitalen interaktiven Prototypen. Wir testen nicht dich!
Wir nehmen zur nachträglichen Auswertung die digitale Testung auf. Die Aufzeichnung bleibt bei uns intern und wird direkt nach der Auswertung gelöscht. Es wird nur das Audio aufgenommen. Du selbst bist nicht zu sehen.
Stelle gerne Fragen! Ich kann aber nicht versprechen, alle Fragen direkt zu beantworten!
Bitte denke laut (Think aloud)
(2) Kontext der Anwendung erklären
GoWalkies ist eine WebApp mit der es möglich sein soll, Gassirouten zu planen. GoWalkies bietet dazu an, vorgefertigte Routen auszuwählen und zu verändern. Im Rahmen dieses Usability Test möchten wir die Schnellroutenplanungs-Funktion (anhand unsere digitalen Papierprototypen) testen und Feedback dazu einholen.
(3) Fragebogen
… Hast du einen Hund oder mehrere?
… Welche digitalen Geräte besitzt Du?
… Welche digitalen Geräte benutzt Du regelmäßig im Alltag? Wie bspw. Smartphone, Tablet, Laptop, Desktop-PC.
… Wie würdest Du Dich selbst im Umgang mit digitalen Geräten einschätzen? (Anfänger/in) 1-6 (Experte)
… Wie würdest Du Dich selbst im Umgang mit dem Internet und Webseiten einschätzen?(Anfänger/in) 1-6 (Experte)
Bevor es losgeht, eine letzte Frage: Mit welchem Gerät wirst Du den Usability Test jetzt durchführen?
(4) Szenario(s)
Du kommst nach einem langen Arbeitstag im Büro (vor dem Rechner und über Akten) nach Hause und hast wenig Zeit, denn deine zwei Kinder und dein/e Partner/in warten auf Dich und erwarten, dass Du am häuslichen Familienleben teilnimmst. Dein zweijähriger Schäferhund braucht aber auch Auslauf – und Abwechslung. Denn Du hast selbst höhere Ansprüche, wenn man sich ein Haustier anschafft. Deshalb willst Du eine halbe Stunde raus mit dem Hund und es soll nicht jedesmal die gleiche Route sein.
Da Deine Zeit so knapp bemessen ist, darf die Planung nicht länger als 15 Minuten dauern.
Du setzt dich also an den Essenstisch im Wohnzimmer,
öffnest deinen Laptop,
den Browser,
tippst die Adresse der Webseite von GoWalkies ein,
meldest Dich an und
legst los mit der Planung.
Für den Test bist Du Harry Hausen!
(5) Aufgaben
1. Mache Dich mit der Anwendung vertraut. Beschreibe, was Du siehst und Deinen ersten Eindruck.
2. Wie würdest Du nun, nachdem Du Dich an Deinen Rechner gesetzt hast, einen solchen kurzen Spaziergang planen?
(6) Abschließende Fragen
Welche Vor- und Nachteile siehst Du grundsätzliche bei der Schnellrouten-Funktion von GoWalkies? Stell Dir vor, Du könntest ein Feature bezogen auf die Routenplanung verbessern, was wäre das und wie würdest Du es verbessern? Warum?
(7) Abschluss
Hast Du weitere Fragen oder Anmerkungen? Vielen Dank für Deine Teilnahme! Du hast uns sehr geholfen.
(2.1) Document who is taking what role.
1. und 2. Usability Testing: Ailis und Hanna Mitschrift, Aljoscha Moderator
3. Usability Testing: Aljoscha abwesend (Uni-Seminar), Hanna: Mitschrift, Ailis: Moderator
1. Usability Test:
Familienangehörige, Hundebestitzerin eines Hundes, nutzt regelmäßig Smartphone & Laptop
schätzt sich als erfahren im Umgang mit Webseiten und digitalen Geräten ein
Dauer: 27 Minuten
2. Usability Test:
Wer ist das? Mitbewohner, Hundebesitzer eines Hundes, nutzt regelmäßig Smartphone, Laptop, Desktop PC und Tracker
schätzt sich als Experte im Umgang mit Webseiten und digitalen Geräten ein
Dauer: 27 Minuten
3. Usability Test:
Wer ist das? Freundin, Hundebesitzerin von zwei Hunden, nutzt regelmäßig Smartphone
schätzt sich als eher erfahren im Umgang mit Webseiten und digitalen Geräten ein
Dauer: 25 Minuten
Dokumentation:
1. Usability Test: Mitschrift durch Hanna und Ailis als nicht-standardisiertes Verlaufsprotokoll
2. Usability Test: Mitschrift durch Ailis als stichwortartiges, nicht-standardisiertes Verlaufsprotokoll
3. Usability Test: Mitschrift durch Hanna als nicht-standardisiertes Verlaufsprotokoll, Ailis als Moderatorin
Wir haben uns für eine reine Audioaufnahme entschieden, um – durch die reine Digitalität der Testungen – Ängste ggü. (dauerhafter) Bildspeicherungen auf Seiten der Tester:innen zu vermeiden. Damit wollten wir eine möglichst angstfreie und offene Umgebung schaffen, die zu einem produktiven Austausch und möglichst großer Offenheit führt. Weiterhin waren wir (meist) zu dritt, sodass wir eine protokollierende Person, eine moderierende Person und eine observierende Person während der Testungen hatten. So konnte mind. eine Person sich vollständig auf die Mausbewegungen und die Aussagen der Person konzentrieren, ohne parallel (inter-)agieren zu müssen.
Die Testpersonen waren alle vor Ort bei einem aus unserem Team (bei Hanna zwei und bei Ailis). Dadurch war der Mitschriftenführer auch immer bei der Testperson und konnte so einfacher jede Regung notieren.
Ein Screencast wäre wahrscheinlich sinnvoll gewesen, wäre der Prototyp insgesamt größer. Da er sich auf wenige Bildschirme beschränkt und „nur“ einen Weg/eine Aufgabe ermöglicht, wären Screencasts zur nachträglichen Auswertung ein zu großer Overhead. Außerdem konnten wir als Gruppe nach jeder Testung direkt ein Auswertungsgespräch führen und so die wichtigen Erkenntnisse direkt herausfiltern.
(3) Document and evaluate the results of your testing.
Gesammelte Notizen aus unseren Usability Tests – 1Gesammelte Notizen aus unseren Usability Tests – 2Gesammelte Notizen aus unseren Usability Tests – 3
Wir haben uns dazu entschieden, alle (analogen) Notizen im Miro-Board zusammenzutragen, um gemeinsam darauf zugreifen zu können. Anschließend haben wir die Notizen in ein Affinity Diagramm übersetzt. Mit Hilfe des Affinity Diagramms und Dot-Votings konnten wir die Ergebnisse und Einsichten gewichten und so entsprechend weitere wichtige Schritte für Änderungen und Ideen festhalten.
Gruppierte und gevotete Notizen
Bei der Erstellung des Affinity Diagramm trat wieder der Prozess der Kategorienaushandlung auf: Während der Sortierung der Notizzettel sind uns weitere Kategorien eingefallen, die zur Sortierung Sinn machen könnten. Dadurch haben wir nochmal neue Perspektiven zur Auswertung gewonnen. So hatten wir begonnen, die Notizzettel nach den einzelnen Ansichten (Pages) der Anwendung zu sortieren, dort jeweils nach „Aussehen“ und „Inhalt“. Dann haben wir aber die größeren Kategorien erweitert noch mit „Accessibility“/“Farben und Co.“ sowie „Usability“ und „Nice-to-have“.
Alle unser Erkenntnisse und next Steps aus unseren Usability Tests.
Die main takeaways und nächsten Schritte haben wir dann direkt im Miro-Board festgehalten – helle Post-its. So können wir die nächsten Schritte angehen und haben dadurch auch eine Priorisierung.
Der Klickdummy auf der Startseite ist zu eingeschränkt. Einige Tester:innen wollten direkt mit der Planung loslegen. Hier ist entweder der Klickdummy auf der Startseite zu erweitern oder das Szenario anzupassen.
Auch auf der Seite der Routenplanung hätte man den Filterdialog einbauen sollen – um die Aufgabe bzgl. der 30 Minuten zu erfüllen. Denn so gab es immer ein kurzes Stocken in dem Bildschirm bezogen auf die Aufgabenstellung/das Szenario.
Es kam zu etwas Verwirrung durch die Karte von Frankfurt, weil mit Charlottenburg in der Ansicht gestartet wurde. Hier muss detaillierter an den entsprechenden Inhalten, die den Testern präsentiert werden, gearbeitet werden – zu viel Zeitaufwand für das gesamte Modul, nicht leistbar im Rahmen des Moduls.
Insgesamt: Es sollte ggf. mehr als ein Weg durch die Anwendung im Klickdummy implementiert sein, um die gestellte Aufgabe durch eine Person erfüllen zu lassen, damit die Usability Testung dafür aussagekräftiger wird.
(1) Summarize the feedback you received regarding your storyboard.
Bei den Feedbacks war es besonders hilfreich, von den Kommilitonen mitgeteilt zu bekommen, dass im Storyboard die Filterfunktion fehlte. Diese müsste noch nachträglich eingebaut werden. Denn – hier bezogen auf das Problem Statement und das Ziel der Persona – geht es ja um das Finden einer Route, die 30 Minuten dauert. Die Filterfunktion haben wir in den Klickdummy nicht mit umgesetzt, nur die Schaltfläche hinzugefügt.
Wir haben außerdem Feedback zu unserem Problem Statement bekommen, was uns nützliche Tipps zur weiteren Nutzung am Problem Statement gibt.
Weiterhin haben wir den Tipp bekommen, dass man möglicherweise noch die Möglichkeit haben sollte sich die Route per Fax zuschicken zu lassen.
(2) Develop an interactive paper prototype.
Wir haben uns entschieden, uns stark an unserem Storyboard zu orientieren und alle Funktionen in den Papieprototyp einzubinden, die dort gezeigt und benötigt werden. Das bedeutet, dass man die im Storyboard dargestellten Funktionalitäten auch im Klickdummy ausprobieren kann. Wir haben die Anmelde-Funktion gewählt und den Schnellplaner, mit dem man eine Route planen kann.
Wir haben für die Umsetzung des Klickdummies das Programm Marvel benutzt, nachdem wir zuvor Adobe XD angeschaut haben und dabei keine Möglichkeit gefunden, den fertigen Prototypen später teilen zu können (ohne bezahlen zu müssen). Figma hat uns von den ganzen Funktionalitäten her etwas erschlagen, während Marvel uns einfacher, aber funktional passender erschien.
Die Screens und Module für unseren Prototypen (Klickdummy) haben wir mit PowerPoint oder direkt mit Marvel erstellt. Einige Modulteile, wie Scrollbalken haben wir per Google Search und Screenshots hinzugefügt. Aufgefallen ist uns, dass Marvel die Bilder stets leicht verwaschen darstellt im Bearbeitenmodus; beim Abspielen des Prototypen sind die Bilder schärfer.
Die Verlinkungen der einzelnen Seiten war mit Marvel einfach und ziemlich intuitv. Allerdings fehlt uns das Feature, eine Seite auch auf sich selber verlinken zu können, was aber nicht allzu wichtig ist.
Unser Klickdummy bildet nur den Use Case ab, angemeldet eine Route auszusuchen. Das entspricht unserem Problem Statement von letzter Woche, dem im Storyboard abgebildetem Szenario und teilweise unserem BPMN-Modell. Das BPMN-Modell wird nur teilweise von vom Klickdummy umgesetzt, da es dort möglich ist, auch unangemeldet eine Route auszuwählen – was im Klickdummy nicht möglich ist.
Unser aktuelles Design hat schon mehr Buttons als im Prototypen klickbar sind. Da der Prototyp die Aufgabe der schnellen Routenplanung (Problem Statement) lösen und zeigen soll, ist das im Moment ausreichend. Allerdings könnten die nicht klickbaren Buttons für einen möglichen Tester bzw. eine mögliche Testerin verwirrend sein. Marvel hilft hier bereits, indem mögliche Verlinkungen bei einem Klick ins „Nichts“ gehighlighted werden.
Es fehlt immer noch ein einheitliches Farbschema; wir haben aber Annäherungen zur Primärfarbe, die wir dann auch versucht haben, möglichst für die Primärfunktionen (Routen Planer) zu nutzen – soweit es Marvel zuließ.
Weiterhin werden noch nicht verschiedene Endgeräte und deren Designs berücksichtigt. Der Prototyp bildet nur den Desktop/Laptop ab und keine Smartphones. Außerdem erkennt man noch nicht die Designsprache sowie die Einschränkungen durch die Nutzung von möglichen Frameworks (GUI).
(1) Finish your hypothesis statement and document it.
Problem Statement
Harry Hausen (Bürokaufmann)
braucht eine Möglichkeit eine 30-min lange Gassiroute mit seinem 2-jährigen Schäferhund – innerhalb von 15 min – zu planen,
weil er zeitnah nach der Arbeit direkt los gehen will und vorher keine Zeit hatte, die Route zu planen.
Wir wissen, dass es erfüllt sein wird, wenn wir beobachten können, dass Harry nach dem Öffnen der App in spätestens 15 min mit seinem Hund Gassi geht und nach 30min frühestens zurückkommt.
Hypothesis
Wir glauben, dass wir durch die Vorschau von möglichen Routen mit sehenswerten Orten
für Harry
erreichen werden, dass Harry und sein Hund eine schöne und zeitlich passende Route gelaufen sind.
(2) Conceptual models for task analysis
Wir haben uns für das BPMN entschieden, da wir uns alle noch nicht damit auskennen und die Chance nutzen wollen, was Neues zu lernen! Und wir finden, dass BPMN für uns den Ablauf mit den verschiedenen Verzweigungen besser darstellen kann. Die Erstellung des BPMN Diagramms war allerdings etwas aufwändiger, da wir dabei auch die Abfolge der Aktionen diskutieren konnten. Zu Beginn hatten wir sehr verschiedene Vorstellungen, wie der Nutzer beim Erstellen der Gassiroute durch unsere Anwendung geführt wird. Zum Ende hin sind unsere Vorstellungen enger aneinander gerückt und wir haben viele Kompromisse gefunden.
BPMN der Aktion: Gassi planen
(3) Find inspirations, analogies, and create a moodboard.
derselbe Ausschnitt, nur sieht man hier Klebezettel mit den wichtigsten Punkten (Voting)Hier sind alle Sketches die wir mit aufnehmen wollen in den Prototypen auf einer Seite gesammelt.
Wir haben uns auf eine Startpage/Landingpage geeinigt, bei der man angemeldet ist und auch auf eine Menüleiste, die, egal wo man ist, immer zu sehen ist. Außerdem haben wir uns zwei Routenansichten ausgewählt: eine für eigene Routen und eine für die Schnellauswahl & das Planen von Routen. Jede dieser Liste an Routen soll man filtern können, wofür wir auch entsprechende Sketches ausgewählt haben. Wir haben außerdem bereits Iconentwürfe und eine mögliche Anmeldemaske. Lediglich das Farbschema haben wir in keinem der Sketches als gut genug befunden und haben uns noch für keines entschieden, aber beschlossen, dass wir die Webseite nach den Features colorcoden wollen.
(6)Condense your results from the previous step into a storyboard.
Harry kommt nachhause
Harry sitzt am Tisch und öffnet Edge
Harry öffnet GoWalkies
Harry klickt auf Anmelden
Harry meldet sich an
Harry kommt wieder zur Startseite (Erfolgsmeldung)
erste Sammlung aller NotizzettelGruppierungen erstmal nach den Unterteilungen des Interviews, der einzelnen Funktionen: Hundebuddies, Kosten, Reisen, Sehenswürdigkeiten, Gassiplaner, Rest: digitale Geräte, Situationsveränderungen, …Überkategorien: Aktivitäten & OrganisatorischesWir haben priorisiert nach für uns wichtigen Informationen. Anscheinend gibt es mehr Denkbedarf zum Reisefeature als gedacht.Hier sind die Antworten auf eine Frage in unserer Umfrage, die wir dann kategorisiert und ausgezählt haben. So haben wir später Priorisierungen für die Features, die wir zudem mit den Interviews korrelieren (Affinity Diagramm).
Insgesamt haben wir 12 Datenblätter.
2. Derive a primary persona from your data-gathering insights
Endlich ist Wochenende. Maria hat sich freigenommen, um viel Zeit mit ihrem Dalmatiner Rosa zu verbringen. Kaum ist sie am Samstagmorgen erwacht, wird ihr auch schon das Gesicht abgeschleckt. Die Sonne scheint, die erste warmen Tage werden im Radio angekündigt. Maria sitzt schon während der Hund sein Frühstück verputzt, in der Küche am Laptop und überlegt, wo sie heute ihren langen Spaziergang macht. Am Sonntag hat sie sich mit einer Freundin, die auch einen Hund besitzt verabredet, um zusammen an einem entlegeneren Ort, spazieren zu gehen. Heute jedoch, genießt sie die Zeit alleine mit Rosa. Sie kennt alle Spazierwege in der Umgebung und versucht, zu ahnen, wo und wann sie Rosas Hundefreunde am ehesten treffen könnte. Maria entscheidet sich am Vormittag eine kleine Runde zu drehen, wo sie oft Rosas beste Freunde trifft und am Nachmittag eine große Runde, mit Abstechern auf noch unbekannte Wege, um vielleicht auch neue Hunde und Menschen kennenzulernen.
Leider trifft sie auf dem kleinen Spaziergang nur Spaziergänger ohne Hunde. Aber am See am Nachmittag trifft sie zufällig verschiedene Hund(-besitzer) und Rosa kann spielen.
5. Model two Use Cases with UML
Im ersten Use Case kann man erkennen, dass ein Nutzer eine Reise planen möchte. Das zweite Diagramm zeigt, wie ein/e NutzerIn eine Gassiroute auswählen möchte, in der sich ein/e anderer/e NutzerIn befindet (und sich geshared hat). Eine Authentifizierung ist hierbei genauer gezeigt.
Wir wollen unsere Funktionen durch die Meinungen der NutzerInnen in der Priorität einordnen können. Es geht uns also vorallem darum, einschätzen zu können, welche Features am Wichtigsten oder am Hilfreichsten sind. Was sind die Must- und was sind die Nice to Haves. Außerdem wollen wir unsere NutzerInnen – mit den Funktionen im Hinterkopf – kennenlernen. Dabei kommen natürlich Fragen auf, was für Haustiere sie besitzen, ob diese Einschränkungen haben (für zusätzliche Funktionen zur Rücksichtnahme, vielleicht einer Abstufung an Schwierigkeitsgraden der Gassirouten) und auch allgemeine Fragen, die die Handhabung der App betreffen. Wie und wann würden die NutzerInnen sie benutzen?
Based on your goal, derive the kind of people you want to gather data from
Unsere Teilnehmer sind vorallem Hundebesitzer für das Interview und Haustierbesitzer für die Umfrage. Dabei interviewen wir mit den längeren Interviews Hannas Schwester, Lara und Ailis‘ Kollegin.
Decide on your data gathering method
Which methods are you using and why?
Wir werden größere Interviews mit Einzelpersonen durchführen. Desweiteren erstellen wir eine Umfrage mit einem Onlineformular. Ein Interview ist gut, um detaillierte Antworten zu bekommen, den Problemspace und die Fokusgruppe kennenzulernen & zu analysieren. Wir werden damit herausfinden, worauf die UserGruppe wert legt, lernen die Umgebung der user Gruppe kennen, und finden heraus, wie sie sich die App-Nutzung vorstellen und was sie sich von der App wünschen würden?
Mit einer Umfrage erreichen wir eine grobe Einschätzung der Prioritäten von Features und Bedürfnissen der Nutzer. Wichtige Gründe für eine solche Umfrage ist die schnellere/einfachere Datensammlung und Auswertung und ein gute Vergleichbarkeit.
What type of interview?
Wir planen ein semi-strukturiertes Interview zu machen, welches mehr strukturiert ist als unstrukturiert. Wir arbeiten mit vielen geschlossenen Fragen , haben aber für jeden Themen bzw. Feature Bereich mindestens eine offene Frage.
What kind of data do you want to gather?
Mit dem Interview wollen wir vor allem qualitative Daten sammeln. Mit der Umfrage wollen wir hauptsächlich quantitative Daten sammeln, aber auch qualitative.
Decide how you handle the topics pilot study & data recording.
Eine Pilotstudie werden wir aus zeitlichen Gründen nur für die Umfrage durchführen. Hierfür nehmen wir Personen aus dem Bekanntenkreis, nicht aus der Fokus-userGruppe. Dabei liegt der Fokus auf der Formulierung der Fragen und der Verständlichkeit für den Teilnehmer.
Data Recording
Interview: Notizen (schriftlich) – Das ist schöner für den Befragten und einfacher in der Auswertung.
Umfrage: Tabellen, Schriftliches, … was das Tool hergibt, das wir benutzen. Je nach Fragetyp wird das unterschiedlich ausführlich sein.
Our Usergroup includes everyone who has a pet (espacially dogs) and wants to interact with other petholders or track the everyday life of his pet. Maybe even peope who think about getting a pet. Other stakeholders could be: Vets, petshop owners, travel companies/organizations, appartment renters, pet trainers, nationalparks … – everybody who has any (business) connection with pets. As contact persons we have family members and friends in an offline community.
2. What is the exact problem?
For dog owners (e.g.) it can be difficult to meet other people with dogs – espacially now with Corona-rules – and to have a community for a dog walk or training. There are a few options, but not a perfect one with even other features alltogether, like a map with trips for people going walkies or a checklist for traveling with your pet.
3. Where is your user group interacting with your software?
They could be at home (Desktop, Laptop, Tablet, Smartphone, etc) or en route (Smartphone, etc).
4. When is the user group interacting with your software?
If a user wants to plan a (longer) trip with his pet or just a walkie, he needs our software to do it. Planning can be done everywhere (in front of the TV, on the toilet, waiting in a queue, …). For the tracking tools of our software applies the same, but it is used more often, perhaps on a daily basis (there might be a reminder for doing an entry).
5. Why do your users need this software?
The Planning part with a checklist for traveling with a pet is needed for just that. The users does not need to look in several sources for information, formulars and so on, because he has our software. But even more important (because it is happening more often), is the „finding a community“ part and getting variety in the daily walkies in nearer (?) environment and improve the social life of the users pet.
6. How do you want to solve the problem?
Using an open source map, the users can add routes, mark single locations (Highlights, pet locations, etc) for other people to see. One option is the location – feature, so that the users can find other users on his way.