Kategorie: Week #6

[A#6, P8] Paper prototyping and usability testing

Part I. Assignments

(1) Continue to develop (or start a new) paper prototype based on new insights or feedback from your peers.

We skip this subtask since we considered the feed back from peers was planned to gathered during last lab session on 25. May which didn’t happen (question asked and got confirmed in Mattermost).

(2) Conduct (at least) 3 formative usability tests.

1.Develop a script for your usability test.

(1) Hinweise für den User

Wir testen die Webapplikation, nicht dich! Fragen bitte gerne stellen, ich kann aber nicht versprechen, alle Fragen direkt zu beantworten! Bitte laut denken (Think aloud). (übernommen von Lab 07)

(2) Kontext der Anwendung erklären

Wir wollen eine Webapp entwickeln für online Spieleabende mit Freunden. Sie soll die remote Brettspielabende unkomplizierter und übersichtlicher machen. Neben der Kommunikationsformen, wie Audio-, Videochat, soll unsere Webapplikation eine Filterfunktion für Brettspiele haben, sowie die eigentlichen Brettspiele eingebettet haben. Wir haben einen ersten Prototypen gebaut und würden in diesem Test gerne die Verständlichkeit und Übersichtlichkeit testen. 

(3) Fragebogen

  • Wie heißt du?
  • Wie alt bist du?
  • Was machst du beruflich?
  • Spielst du gerne Gesellschaftsspiele in deiner Freizeit?
  • Hast du schon einmal einen remote Spieleabend gemacht?
  • Hast du schon einmal einen usability test (als Testperson) gemacht?

(4) Szenario(s) 

erste Szenario: per Link einladen

Du hast einen langen Tag der Arbeit beendet und würdest gerne mit deiner Freund_Innen ein Spielabend machen. Nach der Absprechung habt ihr entschieden, gemeinsam online ein Spielabend auf Social Play zu organisieren. Du würdest gerne erstens ein Account auf Social Play einlegen und deine Freund_Innen per link einladen. Du hast über Social Play einen Link per email an deindem/r Freund_In geschickt. Nachdem deindem/r Freund_In sich eingeloggt ist, habt ihr eingefangen in einem Treffen zusammen Spiel auszuwählen. 

zweites Szenario: Spiel aussuchen und filtern

Du triffst dich mit deiner Freund_Innen zusammen im online meeting Raum von Social Play. Ihr habt gestartet ein Spiel auszusuchen. Jenach euer gewünschte Filterkriterien (z.B. Spielzeitlänge, Spielart, geeignete Personenanzahl usw., die sollte Testperson selbst gegeben werden, um zu gucken, ob wir einige Kriterien vergessen haben) sollte eine Liste von Spiele ausgegeben werden. Dann du und deine Freund_Innen gucken solche Spiele durch und sucht ihr ein Spiel aus. Anschließend spielt ihr das Spiel zusammen.

(5) Aufgaben

Mache dich mit der Anwendung vertraut

  1. Beschreibe was du siehst und deinen ersten Eindruck.
  2. Was wären deine ersten Schritte, um in eine Gruppe mit deinen Freund_innen zu gelangen ?

Finde die Gruppe No board games, no gain.

Lerne die Gruppenmöglichkeiten kennen

  1. Wie würdest du einer Gruppe per Link beitreten?
  2. Wie würdest du eine Gruppe erstellen?

Erstelle ein Gruppe, bei welcher du deine Freund_innen hinzufügst.

Lerne die Filterfunktion kennen

  1. Wie würdest du ein Spiel finden?
  2. Wie würdest du das passende Spiel für euch auswählen?

Finde ein passendes Spiel für deine Gruppe und wähle es aus.

Lerne die Spielfunktion kennen

  1. Was würdest du machen, um mit deiner Gruppe zu spielen?
  2. Wie würdest du ein Spiel starten?

Spiele ein Spiel durch mit deiner Gruppe

(6) Abschließende Fragen

  1. Welche Vor- und Nachteile siehst du bei der Benutzung der WebApp?
  2. Was fehlt dir an der Social Gaming App?
  3. Hast du Schwierigkeiten (Wo hast du Schwierigkeiten) bei Nutzung des Apps? (z.B. eine bestimmte icon oder Funktion zu finden, verwirrende icon design oder Layout design usw.)

(7) Abschluss

  • Hast du weitere Fragen oder Anmerkungen?
  • Vielen Dank für deine Teilnahme! Du hast uns sehr geholfen.
  • (übernommen von LU 7)

2.Document who is taking what role

In the first and second usability tests Ina will be the Facilitator and in the third Brendan. Xin will be the Observer in all usability tests.

3.Decide if you want to record your test session and how you take notes during the test sessions.

We don’t want to record the test sessions as our users expressed uncomfort with the idea of being recorded. We will take notes on paper during the usability test, as we find it the easiest way to create “creative” and adaptable notes. We will later summarise these notes in a more structured way in a Google Doc. 

4.Document who you are inviting for a test session and how long the session lasted.

Table created in word document. We hide test perons‘ name for privacy reason.

(3) Document and evaluate the results of your testing.

Results Evaluation

We first wrote down notes on paper block and then tranformed them into structured notes in word documents (each document for one single test person). The document is structured as the usability test workflow. We take Affinity Diagram to evaluate our results of usability testing since we consider it as the best way to fulfill our „gather and then organize“ evaluation steps.

Since we most concentrate on the improvement suggestions and critics from our test persons, we organize only the „negative“ feedback from our test persons and didn’t write down „positive feedback“ in our affinity diagram (of course positive feedbacks are noted in our structured documents).

The affinity diagram is generated using online tool Flinga.

It is the first version of our affinity diagram which consists of all unorganized ideas from our test persons.
We then organized them into two sub categories: general suggestion (left) which doesn’t correspond to a single function/page and feature/design suggestions (right) which correlate to a single function or page design.
As the last step, we again subcategorized the Feature/Design suggestions(right) into four subgroups: social functions (left), interaction features (middle up), design defects (middle down), and gaming functions(right). Social functions are functions are regarding accout and group creations, where as gaming functions are regarding all functions correlated to games (including filter, in-play scree etc.).
Design defects is a subcategory which should not happen but we still have it based on our carelessness in first design.

Learning and Takeaways

We learned that all test persons liked our design idea behind our application. And they think our first design is not overwhelmed with non-necessary information, wo that the it is easy to follow the test process. However, some confusions can also be found in testing. Part of the confusions are based on the Marvelapp and partly is based on our design defects. There are also some functions we didn’t think of but proved to be important by testings. We think there are really lots of improvements to be done in further design iterations.

Part II Reflexion

(1) Team member contribution.

We first meet together in Discord and discussed the organisatorial stuff of how to organize the usability tests. Then we worked together on our script for further steps (Ina for contextual introduction and questionaire, Brendan for following-up questions, Xin for scenarios. However the separation is not 100% clear since we review and improved each other’s parts though).

The three usability tests are taken part separately over the weekends (responsible persons can be found in the table for task (2)). Notes are generated after the test and uploaded into our shared google folder.

We created the Affinity Diagram after gathering all three notes and evaluate the results.

(2) Learnings from assignment.

We learned how to formly conducted a usability test. It was an interesting experience because somehow the test person can get confused by some designs which we didn’t notice it at all. We are pleased to get constructive feedbacks from our test persons. We will take their feedback into serious considerations and think about how to improve our design.

(3) possitive/successful experience

We successfully found 3 different test persons to help us with the usability testings, which we really appreciate their kindness and helpfulness. All our test persons are so cooperative which make our test processes much more smoothly.

(4) What would you like to improve?

It seems that the assignment workload is not so evenly distributed throughout weeks, for example three usability tests over a weekend is somehow a little bit more. It is also not so easy to find and contact test persons, and then finish usability testings so shortly within a week (for example, some people may be really suitable for usability testing but due to their tough schedule they need to be contacted at least one week before for appointments). That would be so nice if we can see some assignments in advance and maybe prepare it in advance.

Another improvement lies in our previous assignments. In our assignment #2 we didn’t chose „Analyze existing software“ for data gathering. Based on our usability testing results, we found it essential to do that since some of our design defects can be easily resolved by viewing similar apps or apps offer similar functions. If we view similar app designs, we at least won’t forget registration function on the main page.

Additionally, we didn’t undertake probe testing on ourselves before formal usability testing. If we did so, some problems can also be detected earlier.

[A#6, P4] Paper prototyping and usability testing

(1) Continue to develop (or start a new) paper prototype based on new insights or feedback from your peers.

Da es im Seminar nicht zu einer Gruppenarbeit kam, wurde auch kein Feedback erhalten. Somit wurden auch keine Änderungen am Prototypen unternommen.

(2) Conduct (at least) 3 formative usability tests.

Script:

(1) Hinweise für den User

Wir testen die Anwendung, nicht dich! Fragen bitte gerne stellen, ich kann aber nicht versprechen, alle Fragen direkt zu beantworten! Bitte laut denken.

(2) Kontext der Anwendung

JuurMate ist eine Desktop Anwendung und für Jura Studierende. JuurMate wurde entwickelt, um die Rechtsprüfung einer Rechtsfrage zu unterstützen. JuurMate bietet dazu eine dynamische Erstellung von Schemata zur Prüfung solcher Rechtsfragen an. Im Rahmen dieses Nutzertests möchten wir eine Funktion testen und Feedback einholen. Das Feature soll das anlegen eines neuen Schemas sein.

(3) Fragebogen

Um unsere Ergebnisse besser einordnen zu können, würden wir gerne noch ein paar persönliche Informationen von dir haben. Ist das okay?

Wie alt bist du?

Wenn du möchtest, kannst du uns dein Geschlecht verraten?

Was ist dein Beruf (wenn Student: Welcher Studiengang + Semester)?

(4) Szenario

Du musst als Hausaufgabe einen Rechtsfall prüfen. Aktuell bist du auf dem Weg nach Hause und möchtest schon mal damit beginnen. Also öffnest du die JuurMate Anwendung auf deinem Notebook. Nach dem öffnen erscheint ein Auswahlbildschirm, bei dem du dich entscheiden kannst, ob du die geleitete Variante der Anwendung oder die ungeleitete Variante benutzen möchtest. Mit der geleiteten Variante kannst du nun ganz einfach in der Bahn auf dem Nachhauseweg ein einziges Schema dynamisch generieren lassen, dass dir dabei hilft deine Hausaufgabe zu Hause schneller zu beenden.

(5) Aufgaben

Mache dich mit der Anwendung vertraut:
– Beschreibe was du siehst und deinen ersten Eindruck der Anwendung.
– Was fällt dir als erstes auf?
– Wohin hast du als erstes geschaut?
– Hast du nach etwas bestimmten dabei gesucht?
– Worauf würdest du am liebsten zuerst klicken?

Fertige mithilfe der Anwendung ein Prüfungsschema zum Prüfen einer Rechtsfrage zu Mord an und denke bitte daran, alle Überlegungen laut zu formulieren.

Öffne ein altes Schema, das im Vorhinein abgespeichert wurde. Denke auch hier bitte weiterhin daran, alle deine Gedanken hierzu auszusprechen.

(6) Abschließende Fragen

Welche Vor- und Nachteile siehst du grundsätzliche bei der Schema-Gestalten-Funktion der Anwendung?

Stell dir vor du könntest ein Feature bezogen auf die Schema-Gestalten-Funktion 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.

Roles

Tobias übernimmt die Rolle des Moderators. Da wir mit einem digitalen Prototypen arbeiten, werden sowohl Anil als auch Simon beobachten und Notizen anfertigen. Dabei achtet Simon vor Allem auf die Äußerungen und Anil beobachtet die Mausbewegungen auf dem Bildschirm und schaut, ob es dort irgendwelche Abweichungen gibt oder ob unsere Probanden direkt die richtigen Flächen anklicken.

Recording

Wie oben beschrieben, werden die Notizen von zwei Personen aufgenommen. Da wir somit eine gute Abdeckung sowohl der Äußerungen als auch des Verhaltens der Testpersonen haben, haben wir uns gegen eine Aufnahme entschieden. Dies soll dazu führen, dass sich die Testperson weniger beobachtet fühlt uns es eine angenehmere Atmosphäre kreiert.

Who and How Long?

Tade, 20 J., Jurastudent im 2. Semester, 20 Min.
Erik, 19 J., Jurastudent im 2. Semester, 16 Min.
Timon, 21 J., Jurastudent im 2. Semester, 14 Min.

(3) Document and evaluate the results of your testing.

Evaluation Method

Wir haben die Ergebnisse nicht über Affinity Diagramming ausgewertet, da wir hierfür in diesem Fall keinen Mehrwert erwartet haben. Wir haben stattdessen die einzelnen Notizen direkt in Kritik, Positive Anmerkungen, Verbesserungsvorschläge/Wünsche und Unerwartetes Verhalten/Sonstiges eingeordnet und den jeweiligen Screens des Prototypen zugeordnet. Da die komplette Darstellung sehr unübersichtlich ist, haben wir hier exemplarisch ein Ausschnitt eines Screens (für den es die meisten Anmerkungen gab) beigefügt.

Takeaways

Wir haben gelernt, gesehen, dass wir im Grund auf dem richtigen Weg sind. Die Anwendung und die Bedienung an sich wurde von allen Probanden als positiv empfunden. Allerdings sind viele Kleinigkeiten aufgefallen, die Fehlen (z.B. Zurück-Button, deutlich sichtbare Speicherfunktion). Diese scheinen uns bei der Planung unbeachtet geblieben zu sein.

Darüber hinaus haben wir viele spannende Wünsche und Anregungen bekommen. Als die Probanden den Prototypen gesehen haben und ein Gefühl dafür bekommen haben, wie die Anwendung später einmal funktionieren wird, sind viele neue Ideen gekommen. Diese haben wir zu Kenntnis genommen und werden uns damit befassen, ob und wie wir diese Wünsche miteinarbeiten wollen.

Seiten: Seite 1, Seite 2

Die Sakkade

Mit der Sakkade ist das Hin- und Herspringen zwischen fixen Punkten gemeint. Dabei benötigt das Auge nur 30 – 120 Millisekunden.

Quelle: https://git.imp.fu-berlin.de/hcc/hci1-sose-2020/-/wikis/lecture/05-1_HCI_Considering_Human_Capabilities_and_Behavior.pdf

Die Sakkade ist wichtig für die Gestaltung von grafischen Benutzeroberflächen, da der Benutzer meist zwischen bestimmten Punkten hin- und herspringt, die seiner Angewohnheit, z. B. von anderen Benutzeroberflächen, entspricht. Wählt man für seine Applikation dann einen anderen Aufbau, kann dies zur Verwirrung bei dem Benutzer führen.

Quelle: HCI-05-01 Considering Human Capabilities and Behaviour, https://blogs.fu-berlin.de/hci1-sose2021/lu05-considering-human-capabilities-and-behavior/, abgerufen 22.05.2021 um 12:00 Uhr

[A#5, P4] First interactive low-fidelity prototype

(1) Summarize the feedback you received regarding your storyboard.

Our group has received two major feedback points. One was about the platform we develop for and the other was about looking up definitions about certain words. We previously had in mind to develop an app for a phone since this is the most accessible platform for every student. But the feedback showed us that using PDF’s on phones is not very enjoyable and our persona allows a more expensive device. That’s why we started a discussion about the platform. We used the gIBIS technique in task 3 to get a better answer to this question. The other feedback was about looking up definitions. We haven’t really thought about that in our storyboard. That’s why we also discussed how we want to show definitions with the gIBIS technique.

(2) Develop an interactive paper prototype.

We had a look on our sketches and the storyboard and transfered our ideas to our low-fidelity prototype. Therefore, the prototype looks quite similar to our storyboard, except that it’s designed for desktop now.

The prototype fulfills the use case of creating a dynamic scheme by answering several questions about the legal case. We did not made a prototype for the other use case of creating this scheme manually without guidance. We think that the important feature of our application is the guided scheme creation because this solution would save the student the most time.

We used figma since it is easy to use, free and does its job quite well. The strength of our prototype is that it fits our imagination of the application quite well. However, we did not think about exception handling within our prototype for the case that the user input is different of what we expect.

Link to our prototype: https://www.figma.com/proto/xNynXhTPlGvthxMG2es7nC/JuurMate?node-id=19%3A4&scaling=scale-down&page-id=0%3A1

(3) Design rationales

As already explained in task 1, we used the gIBIS technique to answer our two questions. We think using the gIBIS technique it’s easy to think about a questions which seperates in sub questions and which has distinctive advantages and disadvantages.

Refelxion

Who made what contribution?

Anil summirized the feedback we got for task 1. Tobias made the low-fidelity prototype for task 2. We all together did task 3 and talked about the low-fidelity prototype. I did the blog post in the end.

What did you learn?

We had a look onto the different tools for low-fidelity prototyping. Additionally, we reviewed QOS and gIBIS model for answering our questions we had after the feedback. We were surprised that pen and paper prototyping as we did for the storyboard is quite helpful to create a low-fidelity prototype afterwards.

What went well?

Everything went quite well. Nothing to complain about.

What would you like to improve?

There is nothing specifically we could improve currently.