Tobias Schröfel – Human-Computer Interaction I

[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

Data Visualization in General

Ziele von Datenvisualisierung

Das Ziel von Datenvisualisierung besteht darin, Daten so darzustellen, dass ein Mensch fähig ist, in ihnen Muster, Trends, Korrelationen oder Anomalien zu erkennen. Hierdurch sollen neue Erkenntnisse gewonnen werden können.[1]

Einsatz von Datenvisualisierung

Visualisierungen müssen allerdings sehr bewusst erstellt werden. Es ist wichtig zu verstehen, wie der Zusammenhang zwischen den Informationen, die Visualisiert werden und den Erkenntnissen die der Mensch daraus gewinnt ist. Ein besseres Design für die Visualisierung hilft Menschen dabei, besser zu kommunizieren und die Daten im Endeffekt zu verstehen. Beispiele für Designentscheidungen für die Darstellung von Daten, die zu Missverständnissen führen können sind Getting Over the Rainbow, Problems With 3D, Data on the Move und Show, Don’t Tell.

[1]: Frei übersetzt nach HCI-11-02 Advanced Topics in HCI: Data Visualization, Seite 2

Quelle: HCI-11-02 Advanced Topics in HCI: Data Visualization, S. 2,5,7. https://blogs.fu-berlin.de/hci1-sose2021/lu-11-advanced-topics-in-human-computer-interaction/, abgerufen 02.07.2021 um 14:00 Uhr

[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

Principles of Good Design

Damit die “Gräben” zwischen Auswertung und Ausführung verringert werden können, formulierte Norman Prinzipien für gutes Design. Diese sind:

Den Nutzer*innen helfen, ein korrektes “Conceptual Model” des Systems zu erlangen
Die Richtigen Teile (also Funktionen, die Notwendig sind, um die gewünschten Aufgaben des Systems umzusetzen) sichtbar machen
Gedächtnisstützen für die Nutzer*innen bereitstellen, damit diese möglichst einfach auf entsprechende Funktionen zugreifen können
gutes Feedback geben
Fehler behandeln (z.B. durch Fehlermeldung)

Dieses Model fokussiert sich allerdings nur auf die Nutzer*innensicht und nicht auf die Kommunikation zwischen dem System und den Nutzer*innen.

Quelle: HCI-07-01 Designing the Interaction between Human and Computer, https://blogs.fu-berlin.de/hci1-sose2021/lu-7-designing-the-interaction-between-human-and-computer/, abgerufen 01.06.2021 um 13:00 Uhr

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

Szenario

Ein Szenario ist wortwörtliche eine Geschichte, die beschreibt, wie eine „Persona“ sich in einer Reihe von Ereignissen verhält. Hierbei wird das „Was“ und „Wo“ definiert.

Ein Szenario kann dabei helfen:

Designprobleme zu erkennen und zu reflektieren.
Interpretationen zu berichtigen.
stakeholders in den Designprozess einzubinden.
use-cases motivieren.
zu erkennen, was die user erreichen wollen (ihre Ziele).
das aktuelle Verhalten darzustellen und die Einschränkungen, Kontexte, Irritationen usw. zu identifizieren, unter denen user operieren.

Darüber hinaus können Szenarios in ihrem Detailgrad an die geforderten Umständen angepasst werden.

Quelle: HCI-03-03 Conceptual Models: Context Focus, https://blogs.fu-berlin.de/hci1-sose2021/lu01-defining-requirements-and-design-rationales/, abgerufen 28.04.2021 um 18:00 Uhr

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