[A#10, P4] Evaluation of the test results and final project description

1. Evaluate your test results

What method(s) did you use to evaluate the results of your usability test? How did you evaluate the results?

Wir haben darüber nachgedacht, die Ergebnisse systematisch über Affinity Diagramming oder wie bei der letzten Evaluation über eine graphische Verdeutlichung direkt am Prototypen auszuwerten. Allerdings waren die Ergebnisse nicht dafür geeignet. Dies liegt vor allem daran, dass die Testsessions überwiegend damit verbracht werden mussten, den Probanden zu erklären, was überhaupt ein Schema ist und warum Jurastudenten diese Schemata brauchen und wofür sie diese verwenden. Aufgrund des bereits klar strukturierten Feedbacks wurde sich also dafür entschieden, die qualitativen Ergebnisse durch eine einfache erneute Durchsicht der Mitschriften zu evaluieren. Die quantitativen Ergebnisse (Messung der Satisfaction und der Effectiveness) wurden zwar tabellarisch ausgewertet (siehe unten) allerdings nicht weiter beachtet, da diese Werte keine Aussagekraft für uns geliefert haben, da die Satisfaction und die Effectiveness stark davon abhängen, ob die getestete Person fachkundig oder Novize in Jura ist.

What did you learn from the testing? What are your main takeaways?

Am Ende haben sich in den qualitativen Ergebnissen (Notizen während des Testens) drei Anmerkungen von allen Probanden herausgestellt:

Hierarchisierung während der geleiteten Schemaerstellung verdeutlichen,
Quellenangaben bei Definitionen und Meinungenstreiten hinzufügen und
Während der geleiteten Schemaerstellung Informationen zum gerade abgefragten Punkt bereitstellen (z.B. Definition) – beispielsweise über einen Tooltip.

Der letzte Punkt ist jedoch an dieser Stelle nicht repräsentativ, da es sich bei den Probanden nicht um Juristen oder Jurastudenten handelte und somit nicht klar ist, ob diese tatsächlich solche Hinweise benötigen oder wünschen.

Satisfaction:

Proband	Einschätzung	Kommentar
1	keine Angabe	Nicht möglich zu sagen. Kommt auf das Wissen der Student*innen an. Bedienung an sich sehr leicht, aber dies kommt von Abstrahierung, welche es dann in der eigentlichen Benutzung sehr schwer machen kann.
2	leicht (5)	für mittelgute Studenten (für Novizen allerdings sehr schwer, für Experten sehr leicht)
3	sehr leicht (7)

Quantitative Ergebnisse auf die Frage: Wie einfach oder schwer war die Aufgabe insgesamt zu bewältigen? – Skala vorgegeben

Effectiveness:

Test: geleitete Schemaerstellung
Completion: Alle Probanden konnten die Aufgabe komplett abschließen

Proband	Benötigte Zeit
1	12 min
2	14 min
3	8 min

Quantitative Ergebnisse durch mitstoppen der Zeit.

Durchschnittliche Zeit: ~11 min.
Anmerkungen: Es wurden während der Bearbeitung viele fachliche Fragen gestellt, welche die Bearbeitung teilweise immens verzögerten.

2. Project description

Image 1: 1000x500px – Overview of the main menu

Detail of „Aktenkoffer“ – JuurMates version of saved data. We hereby try to match the title and icon to what the User already knows in his/her daily use.

Name: JuurMate – Your Mate for Law-Studies

Name of all group members: Anil, Simon, Tobias

Project description Text: Studying law is very learning-intensive. Because of the massive amount of content it is very easy to lose track of things. When checking a legal issue (which is a very common task throughout university) you have to proceed in a structured way. To do so, there are standardized test schemes. Those test schemes are highly variable and nested. In certain cases some points are more important than others, some also may be irrelevant at all, some have to be expanded and so on. The problem with the present system (e.g. many different documents) is that those are not dynamic at all. This can lead to the usage of 10 or more different schemes to complete one assignment for university.
JuurMate is a desktop application that was specifically designed to dynamically create those schemes and thereby combine all necessary subschemes into one. This leads to a much more clearer overview about what has to be done to complete the given task for the student. JuurMate is a real live(time)-saver!

Additional Images:

Example of Overview of the created scheme

Example of additional information that is shown next to the overview of the created scheme

JuurMate – Text-based Logo

Link to prototype: Click here (may not be online after completion of studies)

Seiten: 12

[A#9, P4] – Preparation of a summative evaluation

(1) Improve your high-fidelity prototype

1: Da wird immer noch keine weiteren Reaktionen oder Informationen von Gruppe 8 bekommen haben, haben wir aus ihrem letzten Blogpost versucht die Probleme herauszulesen. Leider war dort nur von einem fehlenden Back-Button die Rede.

Wir wissen daher leider auch nicht, ob dies das größte Problem für unsere User war.

Wir werden es lösen, indem wir einen „Back to Menu“-Button hinzufügen. Ein normaler Back-Button wäre hier nicht sinnvoll, da wir dann wieder zurück in die Schema-Gestaltung kommen. Das Schema ist allerdings zu diesem Zeitpunkt schon fertig erstellt wurden. Es kann darüber nachgedacht werden, ob eine „Schema bearbeiten“-Funktion hinzugefügt werden soll. Dies ist allerdings aktuell noch nicht geplant. Dafür wird vor dem abschließenden Erstellen des Schemas ein „Sind Sie sicher [….]“-Bildschirm eingefügt werden.

Wir erwarten, dass User dann in dieser letzten Überprüfung nochmal sicherstellen, dass das Schema alles enthält, was gebraucht wird.

2: Es gibt keine weiteren Usability-Issues die wir im Prototypen ändern möchten. Was nun am Prototypen noch verbessert werden kann ist die Implementierung weiterer Funktionen. Da diese sich allerdings vom Design und der Bedienung nicht von den bisher Erstellten unterscheiden, wird dies nicht mehr im Rahmen dieses Projektes umgesetzt. Was nun noch umgesetzt wird ist die endgültige Ansicht und das Einfügen der Finalen Icons und das Erweitern der Fragen im implementierten Beispiel. Auch würden wir gerne die Anregungen von Gruppe 8 einarbeiten, sofern wir diese noch erhalten sollten und wir diese auch als relevant ansehen.

(2) Preparation for a summative evaluation

Wir möchten dieses mal ein etwas umfassenderen Test durchführen. Die letzten Tests waren sehr kurz. Leider gibt der Umfang unseres Prototypen nicht viel mehr her, allerdings möchten wir dies dadurch abfangen, dass wir die Aufgaben offener Stellen und deutlich weniger „eingreifen“ als beim letzten Mal. Dies ist auch zur Messung der effectiveness wichtig und hillfreich.
Wir werden dieses mal keine Audio oder Videoaufnahme machen. Wir haben beim letzten Test (auch im Vergleich zum ersten Interview) gemerkt, dass sich die Probanden doch deutlich entspannter gezeigt haben, wenn keine Aufnahme mitlief. Wir möchten dieses entspannte Umfeld behalten. Ebenfalls werden wir bei den Tests zu dritt sein. Da wir hierdurch die Rollen auf 1 Moderator und 2 Protokollanten aufteilen können wird eine gesonderte Aufnahme auch nicht zwingend notwendig sein.
Das PDF wird übernommen.
Um die Zufriedenheit zu messen, ziehen wir den “Single Ease Question (SEQ)” Fragebogen heran. Er passt zu unseren Use-Cases am besten. Einige der anderen Fragebögen messen unter Anderem die wahrgenommene Zeit, die eine Aufgabe in Anspruch nimmt. Diese Fragebögen kommen für uns nicht in Frage, da unsere Anwendung sich auf Juristen als Zielgruppe konzentriert. Somit kann es mehr Zeit beanspruchen dieselben Aufgaben zu erledigen, wenn sich der Nutzer mit Jura nicht auskennt. Mit dem SEQ vermeiden wir dieses Problem und können auch bessere Rückschlüsse auf die richtige Zielgruppe treffen. Sobald sich Laien gut zurecht finden, können wir davon ausgehen, dass sich Experten ebenfalls zurecht finden werden. (https://measuringu.com/seq10/)
Hiermit getan. Das Script zum Testen sowie die Aufgabenstellungen werden von A#6 übernommen. Ebenfalls ist die Rollenverteilung die selbe.

Seiten: 12

[A#8, P4] Heuristic Evaluation

We further developed our prototype.

Heuristic Evaluation

Phase 1:

For the evaluation we wanted to use the Nielsen’s heuristics. For the evaluation, we created a Google Form based on Alexa’s template.

We then created two scenarios and two use cases for the other evaluators. Both use cases are broken down in further tasks.

Aufgaben für Evaluatoren

Anwendungsfall 1 – Ein Schema erstellen
Yun ist Jura Student der Freien Universität Berlin. Sein Strafrecht Professor hat ein Delikt in der Vorlesung vorgestellt und Yun soll jetzt für diesen Fall das Mordschema prüfen. Yun und seine Lerngruppe haben sich das Schema aufgeteilt, er muss nur den Objektiven Tatbestand prüfen.

1. Navigieren Sie zur geleiteten Schemata Erstellung
2. Suchen Sie das Prüfungsschema zu Mord heraus
3. Erstellen Sie das Schema mit nur dem Punkt des „Objektiver Tatbestand“
4. Speichern Sie das Schema

Anwendungsfall 2 – Gespeichertes Schemata öffnen
Yun ist sehr effizient mit seiner Zeit. Das Schema hat er schnell erstellt, während er auf den Bus gewartet hat. Im Bus eingestiegen hat er alte Bekannte getroffen. Da er seine Bekannten lange nicht gesehen hatte, hat er sich entschieden das Schema zu speichern. Zuhause angekommen setzt sich Yun wieder fleißig an die Bearbeitung des Schemas. Dazu öffnet er das vorhin gespeicherte Schema.

1. Navigieren Sie in den Aktenkoffer
2. Öffnen Sie das Schema

Phase 2

We contacted group 8 through mattermost but we haven’t got a response until now.

Reflection

Who did what?

Tobias did the improvements for the prototype. Simon created the google form for the evaluators and tried to get in contact with group 8. And Anil was responsible for the scenarios, use-cases and the blog.

What have we learned?

We learned to improve our prototype with a use case and evaluators in mind. This helped us to see some missing parts and which we tried to solve then.

What went well?

Our teamwork went well. And we are happy with the minor prototype improvements.

What do we want to improve?

This assignment was a little confusing for us at first. We had problems to define what was preperation for evaluating the other group and what we should prepare for the other groups evaluation. Then we would like to improve the difficulties to get in touch with group 8.

[A#7, P4] Starting High Fidelity Prototyping (First Iteration)

What framework or tools are you going to use? Why?

Wir benutzen HTML, CSS und JavaScript, da wir unseren Prototypen einfach ändern wollen. Da wir zur geleiteten Erstellung von Schemata vielfach den “selben” Bildschirm nutzen und sich lediglich die Fragen ändern, wäre es ein sehr großer Aufwand gewesen, dies mit gängigen Prototyping-Tools umzusetzen. HTML, CSS und JavaScript geben uns die Möglichkeit, die Inhalte dynamisch zu ändern.

List your functional and non-functional requirements (features) you are planning to include in your High-Fidelity Prototype.

Funktional:

Geleitete Erstellung von Schemata
Manuelle Suche nach bestimmten “Subschemata”
Speichern eines erstellten Schemas
Navigation zwischen den einzelnen Funktionen
Übersicht der Abgespeicherten Schemata

Nicht-Funktional:

Intuitive Bedienung (Keine “Anleitung” oder “Tutorial” o.Ä. notwendig)
Einfache Handhabung: DIe geleitete Erstellung von Schemata soll die kognitive Last der Lernenden verringern und nicht zu weiterer Verwirrung beitragen.

Timeline

Was?	Bis wann?
High-Fidelity Prototype Grundgerüst	11.06.2021
Farbkonzept – Erster Entwurf	14.06.2021
Schema-Übersicht entwickeln	18.06.2021
Einbingung aller Fragen zu einem Schema	21.06.2021
Icons Überprüfen/Raussuchen/Ersetzen	24.06.2021
Suchfunktion darstellen	28.06.2021
Schriftarten Überprüfen/Ersetzen	28.06.2021
Fragen an Schema-Übersicht koppeln	05.07.2021
Farbkonzept – Finalisieren	05.07.2021
Hintergrundgestaltung	05.07.2021
Namensgebung von Schemata einbinden	12.07.2021
Progress-Übersicht während Fragen entwickeln und einbinden	12.07.2021

„Hauptmenü“ fertig	18.06.2021
Geleitete Erstellung fertig	28.06.2021
Manuelle Suche fertig	01.07.2021
„Aktenkoffer“ fertig	12.07.2021

Timeline für zu erledigende Aufgaben

Link zum Prototyp

https://userpage.fu-berlin.de/tobias80/prototyp/

Questions

What menu type did you choose and why?

Wir haben uns für ein Grid-Menü entschieden, da wir ein “aufgeräumtes” und “übersichtliches” Interface schaffen wollten, welches sowohl als Desktop-Anwendung, als auch auf größeren Tablets noch ausreichend gut funktioniert. Durch große Symbole möchten wir schaffen, dass die Nutzer*innen nach kurzer “Lernphase” die Anwendung benutzen können ohne die Schrift auf den Buttons lesen zu müssen. Darüber hinaus sind vielen Nutzern die “Kacheln” als Menüstruktur z.B. von Windows-Betriebssystemen bekannt.

Which UI controls are appropriate for your application and why?

Als UI-Controls kommen nur Maus und Tastatur, beziehungsweise die Umsetzung dieser durch einen Touchscreen in Frage. Alle Funktionen, die eine Maus kann auch über einen Touchscreen umgesetzt werden können, aber nicht anders herum, wird sich für die Analyse auf Maus und Tastatur beschränkt.

Which design patterns are suitable for your application and which ones have you implemented or used? Why?

Für unsere Anwendung wäre beispielsweise ein Design Pattern für die Suche nach Schemata verwendbar. Aktuell ist dort ein Input-Feld als Platzhalter angelegt. Im weiteren Verlauf wird dies entweder inspiriert durch Design Patterns abgeändert oder komplett durch eines ersetzt. Ansonsten haben wir bisher keines Umgesetzt und bis auf die Suchfunktion wird wahrscheinlich nichts durch solche ersetzt.

Seiten: 12

[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: 12

[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.

[A#4, P4] Ideation and Storyboard

Hypothesis and problem statement

Jura Yun needs a way to dynamically arrange examination schemes for legal issues because handling many different schemes quickly leads to confusion. We will know this to be true when we see that organizing and structuring schemes is no longer time consuming.

We believe that by building an app to easily structure and merge these schemes for Jura Yun, we will archieve to lower the effort necessary to handle the examination of legal issues.

Moodboard and sketches

We included our sketches into our moodboard.

Moodboard: http://www.gomoodboard.com/boards/ESd8FPrO/share

Conceptual model for task analysis

We choose a task flow model with BPMN since we are still not sure how we can accomplish the solution for Jura Yun. So, the task flow chart helped us to figure out what design could help Jura Yun in the future. We also talked about features we want to have in our application and which we could think about later.

Storyboard

Reflexion

Who made what contribution?

We met and made the task flow model and the moodboard together with the sketches we prepared before. The storyboard was made by Tobias and I made the blog post.

What did you learn?

We learned, that some conceptual models fit better for specific projects than other. Drawing can help to bring thinks in your mind quite fast on paper.

What went well?

In the meetings we worked together very well. We talked about the new learning unit and its content. We could easily find a date for the meetings.

What would you like to improve?

There is nothing we could improve specifically. We hope we will work together as good as we currently do.

[A#3, P4] Conceptual Model for User & Context

Analyze your (qualitative) data using affinity diagramming

Im Folgenden sehen Sie die in der Übung beschriebenen Schritte zum Affinity Diagramming. Der erste Schritt (alle Notizen auf einzelne Punkte aufteilen) wurde dabei nicht extra dokumentiert. Die Priorisierung im letzten Schritt ist durch eine Hervorhebung in Rot dargestellt. Wir finden die Erkenntnisse zur Implementierung (i.e. Features und Output), sowie zur geplanten Verwendung durch den User am wichtigsten. Allerdings sind die beiden rot markierten Inhalte über Schemata und Zusätzliches ebenfalls als wichtig erachtet worden, weshalb wir diese gesondert hervorgehoben haben.

Derive a primary persona from your data-gathering insights

Hier sehen Sie die von uns erstellte Persona „Jura Yun“. Wenngleich auffällt, dass wir bei der Erstellung viel Spaß hatten, hat uns das Erstellen der Persona die Wichtigkeit einer strukturierten Darstellung stark verdeutlicht. Man bekommt ein Gefühl dafür, dass Jura als Fach sehr unübersichtlich ist und dadurch ein hohes Maß an Strukturierung fordert. Andernfalls könnte die Persona (i.e. der User) später leicht überfordert sein und die App wäre keine Erleichterung sondern im schlimmsten Fall sogar eine weitere Hürde im Lernprozess. Die Persona ist als PDF-Datei angehängt.

persona_jura_yun Herunterladen

Create a scenario

Im Folgenden Szenario sind „what“ und „where“ in der hier gezeigten Art und Weise hervorgehoben.

Yun schaut auf sein Handy und weiß, dass gleich sein letzter Kurs vorüber ist. Nach der Uni begibt Yun sich in die Bibliothek um die Übung zum nächsten Termin fertig zu machen. Wie immer stört ihn seine schwere Tasche, die allerhand Schemata enthält. In der Bibliothek angekommen hält er nach einem freien Tisch Ausschau. An diesem Tisch sollte möglichst niemand sitzen, damit Yun seine verschiedenen Schemata ausbreiten kann. Das Suchen ist nervig und manchmal findet er keinen Platz. Heute hat er aber Glück und findet einen freien Tisch. Yun muss heute prüfen, ob der mutmaßliche Täter einen Mord oder nur Totschlag begangen hat. Dafür benötigt er die Schemata des Strafgesetzbuches. Das Schema für Totschlag findet er nicht in seinen Unterlagen. Deshalb muss Yun nun erst einmal im Internet nach diesem Schema suchen. Nachdem er das Schema gefunden hat, legt er sich schon einmal die weiteren Schemata parat, die er für die Prüfung auf Totschlag benötigt. Nachdem er diese Schemata parat gelegt hat, geht er alle diese Schemata durch und prüft, ob er noch weitere Schemata benötigt, damit er den Fall endgültig prüfen kann. Er bemerkt, dass er für eines dieser Schema noch zwei weitere Schemata prüfen muss. Nachdem er den Fall nun endlich geprüft hat, packt Yun seine Sachen zusammen. Weil er nicht weiß, welche Schemata er beim nächsten Mal benötigt, gibt es keine Ordnung in seiner Umhängetasche. Er denkt beim einpacken daran, wie er nächstes Mal wieder erst einmal die
Schemata suchen muss. Mit der Hoffnung, dass es irgendwann eine Lösung für diesen Papierberg, den er tagtäglich mit sich rumschleppen muss, gibt, geht er nach Hause.

Model two use Cases with UML

Hier sehen Sie die erstellten Use Case UML-Diagramme. Wir haben uns für die drei wichtigsten Aktionen der User entschieden. Das generieren von Schemata, das Exportieren der Schemata und das Speichern der Schemata.

Seiten: 12

[A#2,P4]

Define the goals of your data gathering Session

What do you want to find out?

Das Ziel unseres Interviews soll sein, einen detaillierten Einblick in den Prozess der Prüfungsschemata zu bekommen. Dabei sollen wesentliche Fragen für uns geklärt werden, sodass wir wichtige Features in unserer App erkennen können. Obendrauf wollen wir mehr über den Lernprozess der Jurastudenten herausfinden. Wo lernen sie? Welche Medien nutzen sie? Das soll uns dabei helfen zu entscheiden, welches Format die Anwendung haben soll.

Based on your goal, derive the kind of people you want to gather data from

Das Interview wird mit Tade (einem Jurastudenten) durchgeführt. Danach wollen wir weitere Jurastudenten mit Hilfe einer Online-Umfrage nach ihren Eindrücken befragen.

Decide on your data gathering method

Which methods are you using and why?

Das Interview mit Tade wird dazu genutzt ein besseres Verständnis zu erlangen. Ein Interview ist die perfekte Gelegenheit die Abläufe der Prüfungsschemata zu hinterfragen. Gerade weil keiner in unserer Gruppe Erfahrung in Jura besitzt, ist es einfacher domain-spezifische Aspekte mitzunehmen, indem wir ein semi-structured Interview verwenden. Mit dem Wissen, das wir durch das Interview generiert haben, erstellen wir dann eine Umfrage. Die Umfrage ist hilfreich, um zu klären welches Format die Anwendung haben soll. Zu dem hilft die Umfrage, bei der Einschätzung der Features.

What Type of Interview?

Das Interview ist ein semistrukturiertes, weil wir nicht genug Wissen über Jura und die Prüfungsschemata besitzen um ein strukturiertes durchzuführen. Jedoch semistrukturiert statt unstrukturiert, weil wir durch Assignment 1 eine ungefähre Richtung schon besitzen.

What kind of data do you want to gather?

Das Interview soll uns qualitative Daten liefern. Mit der Umfrage wollen wir quantitative Daten generieren. Die quantitativen Daten sollen dabei unsere qualitativen Daten quantifizieren.

Decide how you handle the topics pilot study & data recording

Die Pilotstudie führen wir mit Tade durch für die Umfrage. Dadurch kann Tade nochmal bestätigen, ob wir seine Eindrücke korrekt aufgenommen haben oder nicht. Das Interview wurde durch Notizen und eine Audiodatei aufgezeichnet und im Anschluss zusammengefasst. Für die Audiodatei habe wir von Tade eine Einverständnis über ein Consent-Form bekommen. Das Resultat der Umfrage wird als CSV Datei in Google Drive gespeichert.

Reflexion

Wer hat welchen Beitrag geleistet?

Tobias hat das Interview mit Tade durchgeführt und die Ergebnisse für uns noch einmal zusammengefasst. Simon war zuständig für die Fragen des Interviews und das erstellen der Google Forms Umfrage. Meine [Anil] Aufgabe war es, den Blogbeitrag zu verfassen, zudem habe ich Fragen zum Interview mitgestaltet. Die Fragen für die Online-Umfrage wurden von uns allen erstellt.

Was habt ihr gelernt?

Das während eines Interviews Fragen aufkommen die essentiell sind an die man vorher eventuell nicht gedacht hat. Das man im Interview so viel spaß haben kann, so dass man dabei Gefahr läuft, Zeit und Thema aus den Augen zu verlieren.

Was lief gut?

Die Teamkoordination war diese Woche sehr gut. Jeder wusste wann er was machen musste und es verlief alles reibungslos. Das Interview selbst verlief auch erfolgreich und es freut uns dass Tade auch spaß hat.

Was möchtet ihr verbessern?

Die Woche verlief gut wir würden gerne auf diesem Level weiter machen

[A#1, P4] JuurMates

Assignment #1 – Pitch Your Project

Who is your user group?
Our user group are law students who have to discuss legal issues. The app can also be used by other people engaging in law subjects who want to check a legal issue.

What is the exact problem?
Studying law is very learning-intensive. Because of the massive amount of content it is very easy to loose track of things.
When checking a legal issue (which is a very common task throughout university) you have to proceed in a structured way. To do so, there are standardized test schemes. Those test schemes are highly variable and nested. In certain cases some points are more important than others, some also may be irrelevant at all, some have to be expanded and so on.
The problem with the present system (e.g. many different documents) is, that those are not dynamic at all. This can lead to the usage of 10 or more different schemes to complete one assignment for university.

Where is your user group interacting with your software?
At their desk, in libraries, maybe even in trains – wherever they learn. It could possibly also be used for exercise courses in universities.

When is the user group interacting with your software?
When they are learning, writing a paper (e.g. Bachelors-/Masters-Thesis) or writing an open-book-exam.

Why do your users need this software?
As pointed our earlier, the great amount of content demands for a structured course of action. Obviously the present solution does not match that requirement. Therefore it is necessary to implement a software-solution that is dynamic and features a clear presentation of the needed scheme. This reduces the cognitive load for the students so that they can focus and learn the important contents of their present case.

How do you want to solve the problem?
Since studying is not bound to the students own desks where they most probably have an Computer, but takes place in trains, libraries or even coffee-shops we aim at creating an app for mobile devices that either guides the student through the specific scheme with questions for every step or that provides a possibility to dynamically create full schemes based on selections of the user. The actual implementation depends on the needs and wished of the user group and has to be specified in the upcoming interview.

Reflection

Who did what?
We brainstormed all together to find a suitable subject with good access to the user group. The actual contact to a student that explained the problem was made by Tobias which is why he (i.e. me) writes this Blog post.
Anil creates the presentation and the project pitch.
Simon came up with the brilliant name and provided ideas for the possible solutions for the problem.

What have we learned?
Understanding the users problems is hard. Especially in a field (like law) which is quite new to us and where we do not have expertise.

What went well?
We found pretty fast a user group which we have good access to. Also this group came up with a good problem that seems to be very manageable by algorithms and digital systems.

What do we want to improve?
Due to other courses and projects it was very hard to find dates for meeting. Therefore we just managed to meet Saturday evening which is far away from ideal. We want to improve that and meet earlier so we are not in fear of getting in a hurry.

And maybe we want to improve our group-picture…