List your various requirements elicited from the user research.

This step should be earlier in the process, as you know, but it is useful for focusing your work

• Eingabe von neuen Medikamenten 
• Einfache, übersichtliche Ansicht 
  • des heutigen Medikamentenplans
  • der bereits eingenommenen Medikamente 
  • aller einzunehmenden Medikamente an einem bestimmten Tag.
  • der Informationen eines bestimmten eingegebenens Medikaments
• Erinnerung zum Einnahmezeitpunkt eines Medikaments

Decide based on your requirements and the insights from the low-fi prototype-testing what functionality to include in your high-fidelity prototype.

Consider your problem statement. What insights did you gain from the testing? What are your main takeaways?

Decide on an approach to select the most appropriate requirements (whatever appropriate means in your context)

Der erste lo-fi Prototype zeigte, wie umfangreich ein Prototyp sein muss, um auch nur die Funktionalität testen zu können. Verschiedene Fälle von vergessenen Medikamenten, Einnahmeformen neuer Medikamente, etc. benötigen jeweils ihr eigenes Set an Images. Dies beschränkt entweder die Nutzer bei der freien Erkundung des Prototype’s oder die Zeit, die für die Erstellung pro Image möglich ist.

Wir haben daher, als Kompromiss der beiden Vorgehensweisen, den Prototype direkt an unser Use Case angepasst. Die relativ simple Medikamentenansicht ist fast vollständig abgedeckt, die Eingabe neuer Medikamente ist auf 1 vorgegebenes Medikament beschränkt.

Define the major task flow you want to support.

Based on your scenario, describe at least two major task flows. These descriptions will serve as task descriptions for the evaluators within heuristic evaluation next week.

Task Flow 1:
Szenario: Maria guckt morgens auf den heutigen Medikamentenplan und achtet darauf, die Medikamente, die sie über den Tag verteilt einnehmen muss, bei sich zu tragen
Maria öffnet die FIMO-App
-> Sie geht von der FIMO-Übersicht zu den Medikamenten
-> Sie sieht ihre Medikamente, die noch eingenommen werden müssen für den Tag
-> Sie kehrt zum Home-Bildschirm zurück, um das Handy andersweitig zu nutzen

Task Flow 2:
Szenario: Maria folgt mittags ihrem Tagesablauf und bekommt von der FIMO App eine Benachrichtigung, dass sie gerade ein Medikament einnehmen muss
FIMO App Benachrichtigung zur Medikamenteneinnahme
Maria öffnet ihr Smartphone
-> die Benachrichtigung zur Medikamenteneinnahme wird angezeigt
-> Maria hakt die entsprechende Einnahme ab

Task Flow 3:
Szenario: Maria ist bei ihrem Arzt und ihr wird ein neues Medikament verschrieben. Dieses holt sie sich in der Apotheke ab und möchte es nun entsprechend in der App unter Medications eintragen. Das Medikament heißt „Med-X1Y“. Es handelt sich um Tabletten, die täglich um 12:30Uhr eingenommen werden müssen. Sie soll heute mit dem Medikament starten und das Medikament erstmal auf unbestimmte Zeit einnehmen, bis der Arzt ihr neue Anweisungen gibt.
Maria öffnet Fimo-App via App Icon oder Widget
-> Maria geht zu ihrer Medikamentenübersicht oder zu ihrer Tagesübersicht
-> Maria startet nunmit der Eintragung eines neuen Medikaments
-> Maria hat ihr Medikament in der Hand und scannt den Barcode zum Eintragen der Informationen
-> Der Barcode wird gescannt und die Informationen werden eingetragen
-> Es entspricht dem, was eingegeben werden muss und so fährt sie fort.
-> Der vorausgewählte Einnahme Plan zum gescannten Medikament entspricht dem, was der Arzt ihr gesagt hat, daher fährt sie fort.
-> Die Eingaben der Einheit stimmen, daher fährt sie fort.
-> Da die aktuelle Zeit mit der einnahme Zeit übereinnstimmt, muss sie nichts ändern und geht zum nächsten Schritt.
-> Sie drückt auf das korrekte Feld des Beginns
-> Sie drückt auf den Angaben ihres Arztes entsprechendes Ende
-> Sie schließt die Erstellung ab
-> die Medikamentenübersicht listet nun auch
ihr neues Medikament
-> Sie beendet die App und geht zurück zum Home-Bildschirmum ihr Handy andersweitig weiter zu nutzen.

Task Flow 4:
Szenario: Maria möchte sich vergewissern, was sie am Sonntag, dem 25.ten, an Medikamenten zu sich nehmen muss und zu welcher Zeit.
Maria geht auf das Kalender Widget der Fimo App
-> Sie klickt den entsprechenden Tag, von dem sie die Info sehen will
-> Sie sieht nun die Medikamente, die sie an dem Tag zu sich nehmen muss.

Continue to improve your high-fidelity prototype.

What is needed to have a proper prototype? Make sure that you focus on the important. Please list the areas, you plan and you do work on. What improvement have you brought into your prototype?

Fortschritte: 

• Eingabe neuer Medikamente ist nun möglich 

Geplante Schritte: 

• Erweiterung der Usability
• Abdeckung unerwarteter Aktionen von Nutzern

Prototype: https://marvelapp.com/prototype/jga9b2b

Heuristic Evaluation Formular:

https://docs.google.com/document/d/1wdTlsgXi9mtHswptcG6oUYP2xMe4KlZiDarvcAG-bWU/edit?usp=sharing

Reflect on the results of the heuristic evaluation you conducted in class.

Heuristic Evaluation

The heuristic evaluation was done by us three and kindly also by Prof Müller-Birn.

The main violations of our Prototype found by the evaluators are situated in the process of sharing and finding documents. The prototype does neither give information about the person I am sharing documents with nor about the duration for which it is being shared. Furthermore, the cards in the document overview do not display their sharing status. When searching for a document the user first has to choose what type of document to search, which assumes that the user can assign the searched document, for example a vaccination, to the category that actually contains it, in the case of a vaccination it is „Ausweise“. It would be much better to allow to search in all documents regardless of their type. Generally, our hierarchy of documents seams to not be very helpful but instead confusing.

Reflecting on Comments and explaining our problems and decisions

We received comments below our previous blogpost and will use this post to summarise and reflect on them.

Throughout the first 3 weeks, we were struggling to decide on a narrow enough topic and considered different options, like an asthma app. The comments try to remind us to really consider the principles of humanity centred design „Design with the community, not for them.“ And yes indeed we struggled to find stakeholders we could talk to and ask for their perspective and needs, even after we narrowed down our topic.

In the first couple of weeks we had two main problems: first, we were not able to decide on a topic to focus on and after finally deciding for the TK ePA, we still were not able to narrow down our focus. This problem coexisted with our lack of interview partners. So in other words, we were not able to decide what to do and additionally found no interview partners that could point us to the right direction and give us a good topic. So we tried to decide only relying on researched information from articles and our personal experiences.

We finally had an interview with Marcel who told us that it’s important that developers implement accessibly features and guidelines supplied by the operating system.

The problem with the interview was, that the interviewed Person mostly uses voice assistant. And this is hard to implement and showcase in a UI Prototyping software. The same applies to some of the guidelines to implement accessibility features, because we do not interact with system libraries and there’s nothing like button numbering and information hierarchy on code level when using Figma. Thus, we focused more on the design guidelines that are actually visible and experienceable in a click dummy.

While exploring the TK app, we found that it lacks several „best practices“. It also does not handle accessibility features appropriately. In some cases, parts of the UI are not visible due to overflow and non-responsiveness. Also, there’s no dedicated iPad app.

The design of the App works good for the average user as can be seen in the app stores (4.8 Stars with 300k+ reviews). But there is no „simple“ mode. So we decided to do just that, a mode that can be turned on and completely redesigns the app to make it more accessible and responsive to accessibility features. It is true that this decision was not really based on the information we gained in the previous weeks but more on the limitations and problems we faced. This is indeed a bit frustrating and should have been mentioned in our weekly reflections.

As the following research shows, most of the people are not aware of accessibility features built into the OS. Overall, 15.7% of participants had the idea to fid a solution in their settings of which on average 12.1% identified the correct setting. For readability issues, roughly 20% would have searched for a solution on their phone of which almost all identified the right setting. They also show that it can be beneficial and feasible to detect the users accessibility needs. Based on this detection, a recommendation can be made to the user. For example, if a user tends to hold his/her phone closer to his/her face than the average person, it is likely that a larger font size could benefit the user.

Jason Wu, Gabriel Reyes, Sam C. White, Xiaoyi Zhang, and Jeffrey P. Bigham. 2021. When can accessibility help? an exploration of accessibility feature recommendation on mobile devices. In Proceedings of the 18th International Web for All Conference (W4A ’21). Association for Computing Machinery, New York, NY, USA, Article 21, 1–12. https://doi.org/10.1145/3430263.3452434

Our Prototype mainly aims at readability, clear navigation and simple information hierarchy. As the research shows, the way of presenting this option is crucial for users to actually use it. A possible approach is to ask everyone in the onboarding process if a „simple mode“ is wanted. If possible an implementation of the detection mechanism proposed in the paper would be beneficial, if this is not provided by the system. On the other hand the TK app could also listen for system settings. If users are already using a larger font size or other accessibility features our app can switch from the normal to the simple layout based on a threshold or prompt the user if this is wanted.

Continue to improve your high-fidelity prototype.

Our Prototype focuses on the items needed for the tasks for the heuristic evaluation. In addition it features items necessary to convey the feeling of a functioning and complete app, although not all routes and buttons actually work.

In the past week we reworked the flow of sharing a document adding choices for how long and to whom one shares a document. A search for potential recipients was integrated. In addition we restructured the categorisation of documents by adding to search in all documents and by giving more specific categories like „impfpass“, „Briefe“ etc. The emergency data was moved to the first level of the hierarchy.

We also adjusted the tasks accordingly.

Heuristic Evaluation material

Prototype:

https://www.figma.com/proto/FGW7aa5zIfj257zIb1JG90/FirstPrototypeHCIePA?type=design&node-id=184-937&scaling=min-zoom&page-id=184%3A936&starting-point-node-id=184%3A937&mode=design

Feedback Formular: https://forms.gle/HD7S7pVTN8AELKxRA

Aufgaben:

1. Teilen Sie das Rezept für Novaminsulfon mit Herr Dr. Example for 2 weeks.

2. Finden Sie Ihre Covid-19 Impfungen. 

Reflection

Mit der Zeit hat sich in unserer Gruppe eine schnelle Kommunikation entwickelt. Das ist notwendig, da wir selten alle gleichzeitig an den Aufgaben arbeiten, da wir alle unterschiedliche Vorlesungen und Termine haben. Auch eine etwas klarere Arbeitsteilung ist deswegen notwendig.

Diese Woche haben wir viel Feedback zu verarbeiten gehabt. Einerseits die Kommentare unter den vorherigen aufgaben und andererseits die Heuristic Evaluation. Diese Ergebnisse haben uns dazu gebracht unseren gesamten Prozess bis hier her zu reflektieren. Die Ergebnisse davon sehen sie oben in „Reflecting on Comments and explaining our problems and decisions„.

(1) Reflect on the results of the heuristic evaluation you conducted in class.

Outstanding – Upcoming – Occasional metaphor is not great.
Alert button not very attention catching.
There is no guide to abstract amounts of water.
While there is a notification for success it has no undo button.
There are no error messages at all.
Adding a medication should also allow for scheduling a new one in the same window.
There is no option to choose a custom time, or custom amount of water.

We need to improve the general user error prevention and error explanation, extend the functionality of some screens. Some of the metaphors are not quite clear in the medication part of the prototype. While there might be some aesthetic issues they are not that critical at the moment.

2) Continue to improve your high-fidelity prototype.

We have implemented:

• custom time and amount while logging water
• overview of medication
• custom time for medication
• error screen for unimplemented functions
• undo button in confirmation prompt
• info button in water log screen (needs some more work)
• the alert is more prominent
• changed schedule icon
  
  We plan to improve the metaphor for the medication logging screen and change it from Upcoming – Outstanding – Occasional, but it still needs more thought we havn’t come up with a better metaphor so far.
  
  The water info screen is very basic and need more information/function

(3) Prepare another round of heuristic evaluation  (this time you test the interface of another group)

Heuristic Evaluation:

https://docs.google.com/forms/d/e/1FAIpQLSdJ4Q0nTYRRnkr9JLkPJGNet9RmhNW3AH0Xj8hp6A2hLOgXXg/viewform?usp=sf_link

Figma Prototype:

https://www.figma.com/proto/ONmVu304UbP1EqQErFBFY5/HiFi-v2?page-id=0%3A1&type=design&node-id=1-2&viewport=1461%2C350%2C0.52&scaling=scale-down&starting-point-node-id=1%3A2&mode=design

Who contributed what?

We worked on the prototype together.

What have we learnt?

It was fun using a design tool, they are more complex than we first assumed.

What went well?

Coordination of teamwork, our time management was also very good this week.

What can be improved upon?

This week nothing.

Zusammenfassung der Rückmeldungen in der Heuristischen Evaluation

• Probleme und Fehler beim Mapping der verschiedenen Ansichten und Schaltflächen in Figma
• Prototyp noch sehr rudimentär mit wenigen verschiedenen Interaktionsmöglichkeiten, wenige „Quality of Life“ Funktionen (zu vorheriger Ansicht zurückkehren etc.)
• Sehr „leere“ Anwendung -> viel verschenkter und freier Platz, Anwendung könnte wesentlich kompakter sein
• Nummerierung der einzelnen Elemente und Probleme unklar
• Ersetzung des momentanen überlappenden Layout durch Anwendung mit Overlay-Charakter vielleicht zielführender
• Ziel und Funktion der Anwendung unklar

Link zum Prototype auf Figma

High Fidelity-Prototyp: https://www.figma.com/proto/vKlEYIkcpOjpLLNpAIOY6F/HCI-first-prototype?type=design&node-id=1-3&scaling=min-zoom&page-id=0%3A1&starting-point-node-id=1%3A3

Heuristic Evaluation Form: https://docs.google.com/forms/d/e/1FAIpQLSfYjptnWvuVZwWnj5XQnChkWsiv-P8ktnyN5SowfupHybUPiA/viewform

(1) Reflect on the results of the heuristic evaluation you conducted in class.

Bei der durchgeführten heuristischen Evaluation wurden verschiedene Bereiche identifiziert, in denen Verbesserungsbedarf besteht. Die Ergebnisse zeigen, dass das Design nicht auf allen Seiten konsistent ist. Das Design einiger Seiten weicht voneinander ab. Die Navigation auf der ersten Seite erfolgt durch Wischen anstelle von Klicken, was ebenfalls eine Inkonsistenz darstellt. In allen anderen Frames ist zum Navigieren bzw. Interagieren lediglich ein Klicken erforderlich. Die Kennzeichnung des der markierten Navigationselemente im Tutorial ist nicht auffällig genug und die Platzierung der Sprechblase des Roboters nicht auf allen Frames identisch. Die Position der „Weiter“-Buttons variiert auf den Sprechblasen der verschiedenen Screens und sollte einheitlicher gestaltet werden. Die „Weiter“-Buttons haben die gleiche Farbe wie andere Elemente, was ihre Sichtbarkeit verringert. Der „Zurück“-Button sollte eine relative Rücknavigation ermöglichen und nicht zu einem bestimmten Bildschirm führen. Des Weiteren wurden Kritikpunkte an der Gestaltung der Roboter-Grafik geäußert, da sie viel Platz auf dem Bildschirm einnimmt, jedoch keine zusätzlichen Informationen bietet. Bei Formularen ist der „Submit“-Button immer aktiv, obwohl keine Daten eingegeben wurden, was den Nutzer verwirren kann. Die Benutzerführung weist ebenfalls Schwächen auf. Bspw. wird der Nutzer beim Klicken auf „Skip Tutorial“ auf der ersten Seite nach keiner erneuten Bestätigung gefragt. Ebenfalls sollte eine Option zum Wiederholen des Tutorials vorhanden sein.

Zusammenfassend erfordern die Ergebnisse der heuristischen Evaluation Verbesserungen in verschiedenen Bereichen wie Designkonsistenz, Platzierung von UI-Elementen, Sichtbarkeit von Elementen und Benutzerführung. Diese Punkte sollten bei der weiteren Vorgehensweise berücksichtigt werden, um eine bessere Benutzererfahrung zu gewährleisten.

(2) Continue to improve your high-fidelity prototype.

Improvements / Areas we worked on:

https://www.figma.com/proto/vKlEYIkcpOjpLLNpAIOY6F/HCI-first-prototype?type=design&node-id=1-3&scaling=min-zoom&page-id=0%3A1&starting-point-node-id=1%3A3

(3) Prepare another round of heuristic evaluation  (this time you test the interface of another group)

(4) Reflection

Wer hat welchen Beitrag geleistet?

Wir haben uns die einzelnen Punkte, die in unserem High-Fidelity-Prototyp verbessert werden müssen, untereinander aufgeteilt, sodass jeder ungefähr den gleichen Arbeitsaufwand hat.

Was habt ihr gelernt?

Wir haben gelernt was bei der Erstellung eines High-Fidelity-Prototyps wichtig ist und wie man ein Formular für eine Heuristische Evaluation entwirft.

Was lief gut?

Die Kommunikation im Team lief sehr gut. Wir haben und regelmäßig getroffen, um uns auszutauschen und an der Bearbeitung der Aufgaben weiterzuarbeiten.

Was möchtet ihr verbessern?

Wir möchten unser Zeitmanagement weiter verbessern, um zum einen die uns zur Verfügung stehende Zeit effizienter zu nutzen und zum anderen genügend Zeit für unerwartete Änderungen zu haben.

List your various requirements elicited from the user research.

1. Document management: The app should allow users to view a list of documents stored in their ePA and provide options to sort the documents by different criteria, such as date.
2. Document navigation: The app should enable users to open specific documents, such as PDF files, and provide options to navigate back to the list of documents.
3. Document selection and sharing: The app should allow users to select multiple documents for sharing and provide options to share them securely with specific recipients, such as the user’s ophthalmologist. It should also allow users to set time limits for access to the shared documents.
4. Be able to upload own documents do digitize them.

Decide based on your requirements and the insights from the low-fi prototype-testing what functionality to include in your high-fidelity prototype.

Our Feedback from the last Lab session included:

1. Access to hep should always be available in static states
2. Description of Buttons should be ehanced with icons and clear labeling
3. Filter categories in searches make the screen crowded

These points combined with the user requirements has lead to the following implementation of the HiFi-Prototype:

1. Document management: The user has the ability to search for existing documents within pre defined categories. The user can then authorize the document to be accessable to professionals such as doctors.

2. Medical Passports: The user has the ability to create and maintain their vaccination status within the app.

3. Examinations & Prescriptions: The user can see documents associated with prior doctors visits and prescriptions in the document management

The UI implementation follows the idea of “Big-Button-Interfaces”.
The goal is to remove small and nested UI elements and instead provide big and visible buttons, that promote a clear and understandable route towards the users goal.

This idea is mainly influenced by the following three sources:

Mobile Gesture-Based User Interfaces for People with Disabilities
Shaun K. Kane introduces the term “Slide Rule” which states that contrary to common UI practice: One should always make buttons that fit the entire screen on its horizontal axis and provide clear messaging.
This approach has been tested by Kane with disabled users to great success, reducing the error rate and increase satisfaction.

Apple previews Live Speech, Personal Voice, and more new accessibility features

“Assistive Access” is Apples adaptation of the “Slide Rule” and similar ideas put forward by Kane. The snapshots of common apps from the iOS eco system provided additonal ideas such as the implementation of the back button and the creation of visual hierachy.

User Interview – Disabled person that uses accessability features

We coonducted a user interview two weeks ago with a person that is dependent on multiple accessability features. These are mainly focused on properly navigating the app without using the fingers as much. F.e. numbering buttons and using VoiceOver to navigate that way.
He stressed that Big Buttons derived from the “Slide Rule” could be a great additon, as it could save users in moments where VoiceOver or similar approaches might fall short.

Additonally some users might not be comfortable/unable to use voice assist and would greatly benefit from “Slide Rule” based navigation.

Define the major task flow you want to support.

1. Share the prescription of Novaminsulfon to to a doctor
2. Find your Covid-19 Vaccinations

Start building your prototype.

https://www.figma.com/proto/FGW7aa5zIfj257zIb1JG90/FirstPrototypeHCIePA?type=design&node-id=78-70&scaling=min-zoom&page-id=77%3A69&starting-point-node-id=78%3A70&show-proto-sidebar=1

(1) List your various requirements elicited from the user research.

• PwP need to form healthy habits
• Show PwP correlation between habits and symptoms
• User wants to see report on their use of the app
• User need simple way to track risk factors
• User needs a way to log the medication they take in the app

(2) Decide based on your requirements and the insights from the low-fi prototype-testing what functionality to include in your high-fidelity prototype.

Feedback:

• Navigation bar symbols are not clear/intuitive
• Add water button was broken
• Give confirmation after adding an item
• The groupings in the medication section were not clear
• Popup alerts for medication
• Make water and step counter clickable
• Left, Right indication when entering tremor
• Sort symptoms by category

Functionality:

• Logging water
• Logging Caffeine
• Logging Symptoms
• Logging Medication
• Water Overview
• Caffeine Overview
• Step Overview
• Medication Overview
• Symptom Overview
• Alerts to take Medication
• Confirmation after adding log
• Overview per day week and month

(3) Define the major task flow you want to support.

• Adding a new entry to the diary

User should be able to enter his symptoms, his water intake and his caffeine consumption. He should also be able to log his medication and the time he took it. 

• Viewing the diary statistics 

The user should be able to access the statistics. There he should get an overview of his water intake, his caffeine consumption, his steps, his symptoms and his medication intake. These graphs should give him an overview of his daily life and give the user feedback. Ideally the user should be able to see correlation between things which gives him more insight into his disease and the affecting factors.

(4) Start building your prototype. The UI should be clearly developed (consider all interaction, visual, and information design)

https://www.figma.com/proto/XFQFLHfH8FnOMLSF5KOi9u/Prototype-2?type=design&node-id=1-2&scaling=scale-down&page-id=0%3A1&starting-point-node-id=1%3A2