[A#10, P1]

(1) Evaluate your test results.

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

We created this based on the System Usability Scale developed by John Brookee at the Digital Equipment Corporation, but had not the time to use it during the tests.

We used the method introduced in Assignment #6 for this evaluation too because we received very good feedback after presenting it to our other fellow students and we believe it fits to the other methods given in this assignment.

How did you evaluate the results?

After filling in the formulas provided we expanded it with our difficulty estimation and with both we created the following table to summarize the results:

TaskNotesTake-Away
Log-inNo option to log-in without google or social media.Add more anonymous way or even without log-in.
Figure out what is the last recipe you cooked
Add ingredientsIngredients doesn’t have unit. This confused the user since it is not consistent with other ingredients.

Additional after adding the users are confused why the home-screen is the next one and not the fill-pot-screen.
No drop-down when no unit.

Test person should stay in FillPotLayout when adding an ingredient.

App bar name should be Fill Pot and not My Pot when searching for ingredients
Access potNo indication that the pot is clickable.Add tutorial.
Not-clickable with grey color could work too.
Get recipeAdd more content
Add recipe to historyTest person literally said that he would never click the „Add to history“ button after cooking.He want to use the smartphone for something different after cooking.We will describe a better way to motivate the click on the „Add history“ button in the next block(see below).

Get recipe with too little ingredientsThe provided explanation text is very helpful when no recipe suggestions available
Log-outMake it more difficult to log-out, because we want to keep users as long as possibleLogout should be just on the home-screen not in every screen and also with a pop-up.

What did you learn from the testing?

We want to improve a general issue which is the size of the fonts which might be a bit too small, especially for seniors. We will now mention one part of our design that was continuously discussed in every single task and we think it is important to go into detail about the ideas we can share after this semester regarding this.

What are your main takeaways?

The main general takeaway from usability testing is the idea that the developer/designer perspective might be very different from the user’s expectation from the app. Concretely, we could improve our prototype through test evaluations. Besides, the tests drew our attention to a serious usability problem. Namely, the last step of the recipe preparation contains a button named „Add to History“ that has to be clicked for the application logic to work. What we noticed during tests is that all test participants tend to think that the goal is achieved when they reach the recipe preparation description which is not the case. The „Add to History“ button is crucial since it doesn’t only add the recipe to history if the user wants to access it later but it updates the ingredients pot by removing the used ingredients. The solution that we came out with is to always pop the confirmation alert dialog whenever the user tries to exit the application or go to the main screen. If the user isn’t cooperative and chooses to forcefully exit the application, notifications should be pushed to remind the user that he has to update his ingredients pot. We also want to mention in the pop-up that we will empty the pot and add to history every looked up recipe because we have „favorites“ as a list controlled just by the user.

(2) Project description

Mouadh Khlifi – Master student on Computer Science at the FU Berlin

Christian Zygmunt Jeschke – Master student on CS Education at the FU Berlin

Take-away or food delivery is convenient, but ordered food mostly comes with too much plastic. Moreover, leftovers have to be thrown away. To protect the environment and save food we want to make it easier to find out which meal you can do with leftovers. From our own experience, we know: Even if we have ingredients, sometimes we decide not to cook because we are just too hungry and want to save time. We designed and implemented the app Hello Fridge to solve this issue. The app allows searching for recipes just by inserting ingredients. We expect that our users will more likely open their fridge (and check with our app if they can create something novel by themselves) before ordering food. We used proto.io for the first iterations and now the Flutter Framework from Google for the development. During the methodology-oriented design process, we made multiple types of user tests. On one hand to conceive a concrete idea of what the end product should look like. On the other hand, to detect and solve usability ambiguities that a user can encounter.

Our most important lesson with the focus on HCI was this design decision since we had to change it a lot

Test the app in you browser here (preferabily on your phone)

Hello Fridge App

Please ask us for access to the source code

Who did what?

We had a strong pair work this week but we can mention that Mouadh was more focused on the administration of the web app while Christian did that for the evaluation.

What have we learned?

We identified that Meta Strategies like the consideration of multiple perspectives is a very important and difficult task. We need to keep this in mind during the whole process because once we forget it we are developing just for ourselves and have no chance to sell to the user.

What went well?

We managed better to find a good timing here.

What do we want to improve?

We need to find out how to work in the future.

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

Evaluate your test results

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

We created Diagrams with Google Docs and compared the different user ratings from the After Scenario Quest (ASQ) and the time they needed for the tasks. We calculated the average for the time and every post-task question and included them in the diagrams.

What did you learn from the testing?

  • Every user interacted really differently in the test.
  • To ask the 3 post-task questions took a lot of time.
  • It was hard to convince people to use a rating for the post-task questions.
    • We asked people during the interview and couldn’t always get numbers as answers, people seemed to find it easier to explain their thoughts.
    • It would have been probably more beneficial to give them a form where they can choose what number they want visually.

What are your main takeways

  • When using post-task questions, it seems better to only ask one instead of three.
  • Tasks shouldn’t be to short, otherwise measuring the time becomes a bit complicated and the evaluation results aren’t meaningful. (e.g. Task 8: Du bist aufgewacht und nimmst gleich dein Handy in die Hand um es zu entsperren.)
  • Task 1 took the most time in average, that is probably because the user didn’t know that they can find the factors in ‘sleeping mode’.
  • Overall the user were satisfied with the time the tasks took.

Project description

Prototype

Link to the final prototype: https://www.figma.com/proto/uyswzIlrEDZOnSqmzk08te/Sleepy-Heads-HiFi-Prototype?node-id=17%3A11&scaling=scale-down&page-id=0%3A1

Prototype made with Figma (1000×500 px, png)
Unique – Our Day & Night design

Unique in our prototype is that we have a design for the night and for the day.

Tagline

Sleepy Heads – Good night and sleep well. 🙂

Group members

Angelika Albert
Freie Universität Berlin
Bachelor Informatik

Ayse Yasemin Mutlugil
Freie Universität Berlin
Bachelor Informatik

Tanita Daniel
Freie Universität Berlin
Bachelor Informatik

Description

Many people suffer from sleeping problems and need help with falling asleep, having a well-rested sleep and waking up. Sleep is very important so that people can handle their everyday life. There are a lot of factors that can affect the sleep and many people aren’t really aware of this. For example: We all know that we should avoid screentime before going to bed, but we often do it nonetheless. That’s why we decided that our app should have a blue light filter and we chose to avoid the colour blue and its variations. This is the reason why our mobile application is only using warm colours.

Our goal is to increase the quality of sleep and improve understanding of the persons sleep schedule. Everything will be conveniently recordable in one app and there is no need for paperwork. By recording sleeping patterns, it provides the capabilities to improve the sleep quality and allow doctors to diagnose faster, easier and more accurately.

Additional Pictures

Dashboard
Notification
Dream
Sleep factors
Rate Sleep

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

  1. Hierarchisierung während der geleiteten Schemaerstellung verdeutlichen,
  2. Quellenangaben bei Definitionen und Meinungenstreiten hinzufügen und
  3. 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:

ProbandEinschätzungKommentar
1keine AngabeNicht 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.
2leicht (5)für mittelgute Studenten (für Novizen allerdings sehr schwer, für Experten sehr leicht)
3sehr 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

ProbandBenötigte Zeit
112 min
214 min
38 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 guided creation of Schemes
Example of Overview of the created scheme
Example of additional information that is shown next to the overview of the created scheme
Example of the „Aktenkoffer“
JuurMate – Text-based Logo

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

[A#10, P7] Veritas – Evaluation and Project Description

(1) Evaluate your test results.

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

We first wrote down all our notes. As there weren’t many notes (14 in total), we skipped all more complex evaluation methods and simply discussed all notes in the group. We also used a post-test questionnaire (UMUX) to get feedback from users after the test. The questionnaire consisted of questions regarding their feelings after first contact with the app. 


How did you evaluate the results?

We found main points that we all agreed on were relevant in terms of the conducted tests. Those issues were the most problematic for users during the tests. We used them to make final touches on our prototype. We also retrieved positive points to evaluate what went correctly and was met with approval from our users. From all information gathered we extracted the main takeaways and applied them in the prototype.

What did you learn from the testing?

  • Overall, users found the app very easy to use (all users surveyed ‘strongly agreed’ to that statement in the post-test survey) and one mentioned it was intuitive.
  • All surveyed users disagreed with the statement: Veritas is a frustrating experience
  • the info-button was not clickable, but only the text. Two users clicked solely on the button, though, and assumed that it didn’t work
  • One user criticized that the onboarding screen (how to use the app) didn’t show the current site and that they had the urge to skip it and jump right into it. This reminds us of heuristic evaluation: showing the system state is part of Nielsen’s heuristic.

Just speaking from usability in the narrow sense, we are fairly confident that the app was easy to use and well designed.

However, many users doubted the usefulness of the political compass. Many users wished for an explanation in regards to how articles are positioned. One user rejected the idea of the political compass altogether. Alternative solutions suggested were to show more “political dimensions” (in a radar chart). We feel that this would hinder the interpretability even more though. Still, one user explicitly and without us asking mentioned that they’d use the app. Another also said he would maybe use it. 

The testing itself was quite relaxed and the participants were well-informed in political topics and, as such, very interested in our app. This made for a good user group. The tasks didn’t quite fill their purpose. The users usually only worked for about 1 or two minutes per task. The thinking-aloud part was not done consistently. When asked about their opinion afterwards though, the users were eager to give additional feedback.

What are your main takeaways?

  • The political compass – our key feature in some sense – is controversial.
  • All participants questioned on which factors the articles get placed on the political compass. We should portray this information in our App.   
  • UX-wise we did a fairly good job 🙂

(2) Project description

Prototype:

Unique Part:

Name: Veritas – Escape your filter bubble today

Group Members: Arne, Clemens, Daniel, Mateusz

Project Description: Today’s news is often inherently biased and lacks nuanced journalism. Some more, such as breitbart news, and some less, such as reuters. With the recent surge of social media, a large share of unsuspecting readers fall into a so called filter bubble, i.e., they only see news of specific political backgrounds, which they are anticipated to like. Some think, this may lead to political extremism, further deepening preconceived opinions and ideas. 

Veritas is a tool that makes it easy for users to explore opinions and articles in all corners of the political spectrum. You give Veritas a topic and it presents you a large collection of articles on the given topic that cover a diverse set of published viewpoints.

Final Prototype: https://www.figma.com/proto/xqMeWV6kxUEShVbQSxePjD/THE-INVINCIBLE?node-id=167%3A178&scaling=scale-down&page-id=0%3A1

(3) Reflection

Who did what?

Arne, Daniel, and Mateusz evaluated the test results. Clemens wrote the project description and reflection.

What did we learn?

We learned about the Smartspider which is a different type of political compass.

What went well?

We split up the tasks well and everything was on time.

What can be improved?

When we have time, we consider improving our prototype further because it still lacks some realism.

[A#10, P6] Go Walkies – Evaluation and Project Description

(1) Evaluate your test results

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

Quick Planner
Image shows the function Quick Planer with suggestions for routes and a map (Google Maps (C))

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)

Part of the central functionality of Go Walkies! – suggestions of routes depending on individual preferences (map is from Google Maps (C))

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.

Link to your GitHub/GitLab repo

https://git.imp.fu-berlin.de/gowalkies/gowalkies

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

[A#3, P10] Evaluation of the test results and final project description

Evaluation of test results

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


Zum einem haben wir alle Kritiken und Verbesserungsvorschläge herausgeschrieben, zusammengefasst und diskutiert, bei welchen es sinnvoll ist auf sie einzugehen und die Verbesserungsvorschläge umzusetzen.
Außerdem haben wir zur Bewertung der App die Tester/innen den “System Usability Scale” (SUS) ausfüllen lassen und ausgewertet. Unsere Ergebnisse waren 80, 85 und 90 Punkte, was alles in die Kategorie Excellent fällt. Dies freut uns natürlich sehr, allerdings sind wir auch der Meinung, dass unsere Testproband:innen nett waren und uns möglicherweise etwas zu freundlich bewertet haben.


What did you learn from the testing?

Es macht tatsächlich einen großen Unterschied, ob man als Entwickler:in Entwürfe oder Systeme noch einmal durchgeht und guckt, ob alle nötigen Funktionen eingebaut sind, diese verständlich sind, oder ob das jemand tut, der sich damit noch überhaupt nicht beschäftigt hat und ganz offen ohne Vorwissen die Sache angeht.
Es sind ein paar Probleme aufgetreten, bzw. Funktionsweisen nicht erkannt worden, mit denen wir nicht gerechnet hätten und es kamen auch einige sehr gute Anmerkungen und Verbesserungsvorschläge, auf die wir nicht gekommen wären, da wir zu sehr in der Thematik drin waren und so keinen offenen Blick mehr hatten, für was noch alles möglich/vielleicht sogar notwendig ist.

What are your main takeaways?

Testen ist unglaublich wichtig und sollte am Besten schon relativ früh erfolgen, damit es noch möglich ist, die vorgeschlagenen Veränderungen und Verbesserungen einzubauen, ohne dass dies einen enormen zusätzlichen Arbeitsaufwand nötig macht.
Außerdem sollten mehrere Tester/innen genutzt werden, da unterschiedliche Menschen einen unterschiedlichen Fokus haben und damit auch unterschiedliche Ideen und Verbesserungsvorschläge. Außerdem zeigt sich so auch, ob etwas, was beim ersten Tester/ der ersten Testerin nicht funktioniert hat, ein generelles Problem ist, oder dies nur ein Einzelfall bei dieser Testperson war und somit gar nicht behoben werden muss.

Project description

  1. One image (1000×500 px, png), which shows your prototype.

2. One image (200×200 px, png), which shows some unique part.

3. Name of your project +tagline:
Scenic Route – find your perfect walking route!

4. Name of all group members:

Milos Budimir, Freie Universität Berlin, Master Informatik
Marc Oprisiu, Freie Univerisät Berlin, Bachelor Informatik
Sebastian Wullrich, Freie Universität Berlin, Bachelor Informatik

5. Project description text:

Last year showed us the importance of staying healthy in times of pandemic. Walking with one’s closest friends turned out to be the most important form of socialization during the lockdown, but also has a positive effect on the psyche of each individual. Scenic Route was developed to emphasize awareness of one’s surroundings. Unlike conventional route planning, it does not calculate the fastest route, but the one with the most sights or the most unusual attractions. You get relevant information about interesting buildings and the surrounding area while walking around, so that you become an expert of your city! Choose whatever sort of gastronomy or attraction you would like to see on your route and enjoy the walk while being provided with interesting background knowledge based on experiences of a (soon to be) huge community. Functionally our prototype does still not provide real time route guidance. In the actual implementation open source map data such as OpenStreetMap could be used.

6. Additional images:

7. LINK TO OUR PROTOTYPE

Reflexion

WHO MADE WHAT CONTRIBUTION?

We worked together on this Assignment at a WebEx meeting.

WHAT DID YOU LEARN?

We have learnt how to evaluate testing results, and also where we made mistakes, where there has been place for improvement of our prototype, how it could be done better next time.

WHAT WENT WELL?

Whole process went really well. We were happy to work together on another assignment. 

WHAT WOULD YOU LIKE TO IMPROVE?

There is nothing we would like to improve, since we are pretty much satisfied with how it went, both content wise and atmosphere wise.

[A#9, P1] Preparation of a summative evaluation

(1) Improve your high-fidelity prototype

In the heuristic evaluation we received 4 violations while 1 of them reached the 4th level of severity, two reached the 3rd level and one is on the lowest. Nevertheless, we decided not to pick the highest level available because it was, we believe, not our initial design approach. Since changing this design will make a fundamental change on our problem to solve, we do not want to follow this feedback and rather focus on the other. The problem is described „To look at the preparation you need to press the button on the bottom right corner. To go back to the ingredients, you need to click on the arrow in the upper left corner.“ A bit special is that we received two ideas for „Recommendation:“ where we skip „a) Ingredients + preparation on one page with scrolling“ and going as our solution „b) Divide both parts and store the preparation step (where you were) when you switch to ingredient list. Switching to back to ingredient list should be with the same button as ‘Showing preparation’“. We expect that this will change one of the first interaction problems which is also the most intense one because we discussed on every iteration, namely, how should the user interact with our app after cooking.

We implemented our app here https://mouadhkh.github.io and we followed the desciption above to know the usability issues and features and here is the excact list:

implemented fillPotLayout, fillPotlayout action still missing

implement mainLayout, theme not working, log out button missing,no links for buttons and recipes are not clickable at all

-fixed TabBar and restyled

add recipes suggestions

horizontal slider for recipes

add new recipe layout

add layouts for a single recipe

add preparation implementation for recipe

add alertDialog for confirmation

log out button on all screens

(2) Preparation for a summative evaluation

Even if on the tests at the 6th assignment we had no problems, we want to make some improvements because of the heuristic evaluation where we had to improve our tasks from the #6 assignments. Especially the task amount is higher now because our current prototype allows more and therefore, we have more details here.

In the second attempt the task has been specified by this HCI seminar and it was not necessary to add them like in the #6 assignments. Same as the other group we hoped that the tasks presented are a good starting point to understand the prototype without our own interruption.

Skript

The roles: The observer is taking notes while the facilitator guides the interview. All participants are affected by the solution that HelloFridge offers. Since the target group is living in our area we decided to provide the script in German:

1.Hinweis für den User
Wir testen die App, nicht dich! Fragen bitte gerne stellen, ich kann aber nicht versprechen, alle Fragen direkt zu beantworten! Bitte laut denken

2- Erklärung des Kontexts
Essen bestellen und Fast Food ist bequem und schnell, aber es schadet der Umwelt. Um diese zu schützen erlaubt unsere App HelloFridge mit einer Zutatenliste passende Rezepte zu finden. So können für die Essensreste Zuhause neue Gerichte gefunden werden.

3-Fragebogen
Alter ?
Erfahrung mit dem Umgang mit Smartphones ?
Regelmäßiges Nutzen von Mobile Food Apps ?

4-Szenario
Du hast Hunger. Wie immer, gehst du zum Kühlschrank und schaust ob du etwas kochen kannst vor allem damit du deine Essensreste verkochst. Du hast zwar einige Zutaten, aber ein Rezept fällt dir nicht direkt ein. Deshalb nimmst du dein Smartphone, suchst nach einer Rezepte App und klickst auf das innovative Hello Fridge.

5-Aufgaben
Sollten zu einem Zeitpunkt Verständnisfragen zu den Aufgaben auftreten, bitten wir dich, diese uns gegenüber zu äußern. Wir stehen dir auch gerne zur Seite falls mal etwas schiefgelaufen ist.

Log Dich ein
Was ist das letzte Rezept das gekocht wurde ?
Wir wollen nun dieses Rezept nur mithilfe der Rezeptliste finden.
Füge dazu eine normale Einkaufsportion von Hänchenbrust, Reis, Tomaten Olivenöl und Gewürze hinzu.
Lass dir von der App ein Rezept finden.
Bestätige dass du das vorgeschlagene Rezept gekocht hast.
Finde heraus welche Zutaten du noch hast nachdem du gekocht hast.
Füge noch ein beliebige Zutat zum Hello Fridge Topf hinzu und versuche nach einem Rezept zu suchen. (Du wirst kein Rezpt sehen können)
Log Dich aus

6-Abschließende Fragen
Welche Vor- und Nachteile siehst du grundsätzliche bei der Rezeptesuchen-Funktion der Hello Fridge App ?

7- Abschluss
Hast du weitere Fragen oder Anmerkungen ?

Which standardized questionnaire did you choose and why?

After talking about it with the guests, we used the time for that.

Who did what?

We splited this week the tasks in detail but we have both worked on the programming and writing.

What have we learned?

We learned especially how to finish a project with the SDK Flutter and interaction design.

What went well?

We are very happy with our final result.

What do we want to improve?

We try to work on our time management and to find a balance between programming and Human-Centered Design.

[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

  1. 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.
  2. 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.
  3. Das PDF wird übernommen.
  4. 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/)
  5. Hiermit getan. Das Script zum Testen sowie die Aufgabenstellungen werden von A#6 übernommen. Ebenfalls ist die Rollenverteilung die selbe.

[A#9, P5] Preparation of a summative evaluation

(1) Improve your high-fidelity prototype

1. Choose the biggest problem found during the last heuristic evaluation and answer the following questions:

The biggest problem in our mobile application is that we have no emergency exit.

Why is this the biggest problem for your users?

The biggest issue was that when you are at a screen, e.g. Muscle Relaxation Method, you must click the back button serveral times in order to get back to the dashboard.

How will you solve it?

In our prototype we designed a burger menu that have shortcuts for specific functions in our application. Therefore we want to add there a link to the Dashboard, so that the user can get to the dashboard faster.

How do you expect the user will behave, after the problem is solved?

Like I wrote in the last question the user can get to the dashboard faster and the overall navigation would be quicker.

2. Decide what usability issues you are going to fix in your prototype and what features you are going to implement next.

For the first week we focus, as we planned in our Gantt-Chart, how the dream-site should look like, how the user could rate his sleep and add his sleep data. For the second week of this assignment we want to focus on the statistics.
Also we want to improve the emergency exit as described above and change the text in our notification message because during the last heuristic evaluation this was also stated as one of the bigger problems in our prototype.

(2) Preparation for a summative evaluation

What are things you would like to do differently this time?

We want to describe our tasks differently, so that it is more in the language of the user.

What documents do you need?

  • Consent Form:

Einverständniserklärung
zur Verarbeitung personenbezogener Daten.

Hiermit erteile ich meine Einwilligung, dass im Rahmen eines Usability-Tests eines Prototypen die von mir erstellten Audio- und Video-Aufzeichnungen für die Evaluation der Arbeitsgruppe 5 (Sleepy Heads) verarbeitet werden dürfen.

Folgende personenbezogene Daten werden verarbeitet:

  • Biographische Daten (z.B. Ausbildung, Beruf)
  • Daten, die ein Nachweis Ihrer Einwilligung der Datenverarbeitung sind (z.b. diese Einwilligungserklärung)

Die genannten personenbezogen Daten werden ausschließlich zu Forschungszwecken verwendet.

Diese Einwilligung ist freiwillig und ich kann sie ohne Angabe von Gründen verweigern, ohne dass ich deswegen Nachteile zu befürchten hätte. Zum Widerruf ist eine formlose E-Mail an

tanid96@zedat.fu-berlin.de, yasemin.mutlugil@fu-berlin.de oder angelia00@zedat.fu-berlin.de ausreichend.

__________________________________________________
Ort, DatumfjruhfkjrdfjhdjhfjdhjfhdjhfjdhfUnterschrift

  • Script:
    (1) Notes for the User

    Wir testen die App, nicht dich! Fragen bitte gerne stellen, ich versuche sie soweit es geht zu beantworten. (Bitte laut denken, also alle deine Aktionen mit dem Prototypen beschreiben.)

    (2) Kontext der Anwendung
    Sleepy Heads ist eine mobile Anwendung mit der man seinen Schlaf tracken kann. Es wurde entwickelt um Personen mit Schlafproblem zu helfen ihren Schlaf zu überwachen und diesen zu verbessern. Ebenfalls bietet es ein Traumtagebuch, Einschlafhilfe und Auswertung zum Schlaf. Im Rahmen dieses Nutzertests möchten wir unsere App testen.

    (3) Aufgaben
    1. Du bereitest dich vor Schlafen zu gehen und willst in deiner App angeben dass du Muskelschmerzen und Kopfschmerzen hast.
    2. Da du jetzt hungrig ins Bett gehst und dazu kein Faktor vorliegt möchtest diesen Faktor hinzufügen.
    3. Da du Muskelschmerzen hast, wählst du vorher eine Muscle Relaxation Methode aus. 
    4. Nachdem du mit der Übung fertig bist, wählst du einen Podcast aus den du beim einschlafen hören möchtest. 
    5. Der Podcast soll nur für 30 Minuten spielen, stelle dies ein.
    6. Da du die letzten Tage scheinbar im Schlaf geredet hast möchtest du den Sound beim Schlafen aufnehmen um zu sehen was du sagst.
    7. Du bist jetzt bereit zu schlafen und willst deinen Schlaf starten.
    8. Du bist aufgewacht und nimmst gleich dein Handy in die Hand um es zu entsperren.
    9. Du hattest in der Nacht einen Alptraum und möchtest ihn notieren.
    10. Du hast nicht so gut geschlafen durch den Albtraum und möchtest das in der App festhalten.
    11. Da du keinen Fitnesstracker hast der automatisch deine Schlafzeiten notiert, machst du dies manuell.
    12. Zum Schluss möchtest du wissen wie gut du im Vergleich zu anderen Nächten geschlafen hast.

Which standardized questionnaire did you choose and why?

We decided to use the post-task questionnaire in order to see on which task or action the user had problems or is dissatisfied. Therefore we used the After Scenario Quest(ASQ) with a scala from 1 to 7.
With the post – test questionnaire we would only get an overall valuation which we found not so effective to change specific functions in our prototype.

This are the questions:

  • Overall, I am satisfied with the ease of completing the task in this scenario.
  • Overall, I am satisfied with the amount of time it took to complete the task in this scenario.
  • Overall, I am satisfied with the support information (online help, messages, documentation) when completing the task.

The questions are from https://slidetodoc.com/presentation_image_h/aceaee22d2394a20e57f0acdb9ea7e28/image-39.jpg, retrieved 04.07.2021, 10:55 AM

Who will do what in the evaluation?

We thought that we have for the upcoming evaluation three tasks:
Moderator, notetaker and timekeeper
Tanita will be the moderator, Yasemin the notetaker and Angelika the timekeeper.

[A3, P9] Preparation for Evaluation and Prototype-Improvement

(1) Improve your high-fidelity prototype

The biggest problem which group 7 found for our prototype is the unclear technique of choosing the route which is to be taken. We agree that this is a problem which should be addressed with high priority.

Why is this the biggest problem for your users?

This is the biggest problem for our users because it is not clear how to save a route, how to dismiss a route and how to start the route. That is because we thought of introducing (Tinder-like) swipes, where you either go left or right and can’t go back. We now realize there is a better implementation for our use case.

How will you solve it?

Left swipe = dismiss, right = saved for later (to be found in “Saved routes”), middle click = start the route.

How do you expect the user will behave, after the problem is solved?
We believe that it will give clearer instructions st. users will easily use our app and be able to choose a route naturally and without much thinking on how to do it.

Decide what usability issues you are going to fix in your prototype and what features you are going to implement next.

We have fixed the issues with swiping and route choosing. We also have fixed and changed the way back arrows behave on certain screens for consistency reasons. The info button for certain monuments and natural/cultural elements during the route was introduced. 

(2) Preparation for a summative evaluation

What documents do you need?

  • Adapted script from assignment 6 (see below)
  • Template to measure the task completion rate.
  • System Usability Scale (SUS) questionnaire 

Adapted script from assignment 6:

Hinweise für den User: Wir testen die App, nicht dich! Fragen gerne stellen, wir können aber versprechen, dass wir sie alle direkt beantwortet werden. Wir möchten betonen, dass Du nichts falsch machen kannst! Wir bitten Dich deine Gedanken laut auszusprechen.

Kontext der Anwendung: ScenicRoute ist ein unkonventionelles Routenplanerprogramm. Es berechnet anders als herkömmliche Routenplanung nicht die schnellste Route, sondern diejenige mit den meisten Sehenswürdigkeiten, den außergewöhnlichsten Attraktionen oder den als sehenswert erachteten Wanderwegen.

Fragebogen: Wie alt bist du? Wie lange wohnst du in Berlin? Wie oft gehst du spazieren täglich/mehrmals die woche/seltener als einmal die Woche. Wie lange gehst du in der Regel spazieren?


Szenario: Du stehst morgens um 9 Uhr, machst dir einen Kaffee, frühstückst und kümmerst dich um deine heutigen Arbeitsaufgaben. Diese Arbeit ist gegen 17 Uhr in der Regel erledigt und Du nutzt die Zeit um spazieren zu gehen. Meistens zieht es Dich in Richtung des nahegelegenen Parks, indem Du gerne spazieren gehst. An dem heutigen, recht sonnigen, Tag wanderst Du allerdings ziellos durch die Straßen Deines Viertels. Du nutzt den Spaziergang um Dir bei einer nahe gelegenen Rösterei einen Kaffee zu holen, wie du es eigentlich bei jeden Spaziergang gerne machst, und Dich auf eine Bank zu setzen. Auf der gegenüberliegenden Straßenseite fällt Dir ein sehr schönes Gebäude auf. Du bist Dir aber nicht sicher aus welcher Epoche dieses stammt. Du fragst Dich, ob es öffentlich genutzt wird. Eine Google Suche bringt dich nicht weiter und wünschst dir einen einfacheren Weg bei deinem Spaziergang an eine solche Informationen zu kommen.

Aufgaben: Gucke Dir die App an und beschreib uns wie sie auf Dich wirkt. Mach Dich mit der App vertraut. 

  • Beginne eine neue Route zu planen und diese zu starten. 
  • Anschließend probiere eine neue Route hinzuzufügen. 
  • Suche eine deiner gespeicherten Routen und starte diese.

Abschließende Fragen: Bist Du der Meinung alles Nötige, was Du für die Nutzung einer solchen App erwartest gefunden zu haben? Hat Dich irgendwas am Design gestört?

Abschluss: Hast Du noch weitere Anmerkungen oder Fragen?

This time, you will also measure the satisfaction of users, by using a post-task or post-test questionnaire. Please choose independently what suits your project.

Which standardized questionnaire did you choose and why?

  • System Usability Scale (SUS)
  • Uns gefällt, dass es direkt einen Score zurückgibt, welcher uns einschätzen lässt, wie gut nutzbar unsere App für Nutzer:innen ist. Des Weiteren hat sich herausgestellt, dass SUS gut geeignet ist, um die Nutzbarkeit eines Systems zu überprüfen, ohne dass das Ausfüllen zu viel Aufwand und somit Zeit der Nutzer:innen erfordert, da es sich nur um 10 Fragen handelt. 
  • SUS QUESTIONNAIRE: https://forms.gle/Wyzoc2YLyrbbvASP6 

Document your preparation.

  • 1. Treffen am 24.06.: Haben uns überlegt, wie wir unseren Prototypen verbessern wollen, aber die Umsetzung davon auf nächste Woche verschoben, da es uns wichtiger erschien die Evaluation vorzubereiten, insbesondere aufgrund des Termins mit Alexa am Dienstag, wo wir noch einmal die Möglichkeit haben Fragen zu stellen bzgl. Dingen die uns noch unklar sind.
  • 2. Treffen am 29.06.: Treffen mit Alexa fiel aus. Wir haben die Vorbereitungen für die Evaluation abgeschlossen und die Änderungen am Prototypen, die wir noch durchführen wollten, eingebaut. Templates wurden ausgedruckt, Google Forms erstellt.

(3) REFLEXION

WHO MADE WHAT CONTRIBUTION?

As always, the three of us would meet in a WebEx meeting and work together on the Assignment. We went through the evaluation which group 7 conducted for our App and talked about the issues they found. We decided how to improve our app based on that and also made the improvements directly in Figma, after consultations with Alexa. Also, the second part (Preparation of summative evaluation) we did together while working on a collaborative Google doc. 

WHAT DID YOU LEARN?
We have learnt how to deeply look into the application while designing it and focus on certain common behaviours, such that we avoid most common mistakes and understand the good practices. 

WHAT WENT WELL?
In our opinion the whole Assignment process during the 2 weeks went well and without any noticeable problems. 

WHAT WOULD YOU LIKE TO IMPROVE?
There is nothing we would like to improve. After working on this project for some weeks now, we have learnt how to work together, prepare and deliver.