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.
Due to time restrictions we only met once after we already did our prototype versions. In the meeting we changed some details and extended the digital prototype further on.
The use case and/or model (task analysis from last assignment) this prototype relates to.
Our Use case describes a user adding a recipe into his list. We describe this scenario in the digital version. In the paper prototype we focused on the process to create a profile with the individual needs of our persona.
How the storyboard is reflected in your prototype.
The storyboard is reflected in our prototype in such a way that the adding of recipes to the list is shown and the individual account settings are adjustable
Self-assessment of potential strengths and weaknesses of this first step into your design space.
In our opinion, doing a paper prototype is a lot of work compared to a digital prototype. Also changes in the paper prototype are a lot expenditure because in the worst case you have to redo the whole screen in more than one state of the prototype. The strength of the prototype is that we got an idea of how the usage of the app will feel.
(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.
Retrieval describes the process of remembering information from the long-term memory. There are three ways to retrieve information: recall, recognition and relearning.
Recall describes the access of information without cues. In other words: Not by sensory input but by brain activity. Thus to recall information correctly, coordination and time is needed.
Example: A journalist writes a column about a specific topic that they have a lot of knowledge about.
Recognition describes the identification of already learned information by sensory input. This means that the information is retrieved when encountering it again.
Example: A person sees their favorite food from childhood and immediately remembers how they ate it as a child.
Relearning describes learning of information that one already has learned in the past.
Example: A person picks up a language again that they have learned in school and is able to learn it again quite quickly.
(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).
The Human Processor Model is a framework for system designers. It is a cognitive modeling method, which is also a possible way to evaluate the usability of a product, by estimating how long a person will take to perform certain tasks. The estimates are given by the framework, which eliminates the need to perform experiments with the users. Another aspect of the framework is that the designer can guess what the expected chance is that a person remembers an item that was presented to them in the process. This can be used as an indication of whether or not a user is likely to recall crucial elements that they encountered during the procedure.
