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

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

List your various requirements elicited from the user research.

• Fragebogenstruktur
• Relevante Fragen
• Ergebnispräsentation
• Transparenz
• Datenschutz
• Benutzerfreundlichkeit
• Barrierefreiheit

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

Problem: Es gibt bisher keine Möglichkeiten, verschiedene ePAs zu vergleichen.

What insights did you gain from the testing? What are your main takeaways?

User 1:

• Wusste was die Buttons machen
• Zurückpfeil verwirrend 
• Bei der Texterklärung lieber Zurückbutton oder x statt Swiping
• Bei der Ergebnisanzeige sollte man zurückgehen können, um einzelne Fragen anders beantworten zu können, damit man nicht komplett von vorne anfangen muss, wenn man nur eine Änderung vornehmen möchte
• Tutorialpage am Anfang  
• Macht Sinn für 25 Jährige 
• Für Ältere Personen nicht
• Transparenz erhöhen, während gewischt wird

User 2:

• Wusste was die Buttons machen 
• Extraslide mit Tutorial 
• Man erkennt nicht, dass man auf die Punkte klicken kann, um zu springen
• Mehr Auswahloptionen eventuell

User 3:

• Hat den Zurückbutton nicht gesehen in der ersten Iteration 
• Und das Fragezeichen nicht
• Bei Klick auf dem Fragezeichen wurde das Tutorial erwartet und nicht die Erklärung der Frage: Statt Fragezeichen ein “i” zusätzlich zur Klärung der Frage
• Fand es nicht ganz intuitiv 
• Erklärung der Buttons beibehalten

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

Es ergeben sich folgende vier Punkte, die wir an dem Prototypen verbessern wollen:

• Ein Tutorial für die Bedienung
• i statt Fragezeichen für Erläuterungen der aktuellen These
• Bei der Texterklärung lieber Zurückbutton oder x statt Swiping
• Zurückmöglichkeiten an jeder Stelle der App

Die Punkte wurden so ausgewählt: Entweder wurden sie mehrfach genannt oder sind Low Hanging Fruits. 

Define the major task flow you want to support.

Task Flow 1:

Aufgabenfluss: Die beste Krankenversicherungsoption finden
Beschreibung: Leo möchte mithilfe der Wahl-O-Mat-Plattform die beste Krankenversicherungsoption finden, die seinen Bedürfnissen entspricht.

Schritte:

1. Leo landet auf der Startseite von Wahl-O-Mat und sieht einen klaren Aufruf zum Start der Bewertung.
2. Leo beginnt die Bewertung, indem Leo eine Reihe von Fragen zu Präferenzen und Anforderungen an die Krankenversicherung beantwortet.
3. Leo werden empfohlene Krankenversicherungsoptionen basierend auf den Antworten präsentiert.
4. Leo kann detaillierte Informationen zu jeder empfohlenen Option erkunden, einschließlich Leistungen, Beiträgen und zusätzlichen Services.

Task Flow 2:

Aufgabenfluss: Erhalten weiterer Informationen durch Drücken der Informationstaste bei den Wahl-O-Mat-Fragen

Beschreibung: Der Benutzer öffnet den Wahl-O-Mat und drückt die Informationstaste bei den einzelnen Fragen, um weitere Informationen zu erhalten.

Schritte:

1. Der Benutzer sieht eine Fragen, die im Wahl-O-Mat beantwortet werden sollen.
2. Jede Frage ist mit einer Informationstaste oder einem Informationssymbol versehen.
3. Der Benutzer drückt die Informationstaste neben der ausgewählten Frage.
4. Nachdem die Informationstaste gedrückt wurde, öffnet sich ein Overlay oder eine Pop-up-Anzeige mit weiteren Informationen zu der ausgewählten Frage.
5. Das Overlay oder die Pop-up-Anzeige enthält detaillierte Hintergrundinformationen, Kontext oder Erläuterungen zur Fragestellung.
6. Der Benutzer liest sich die Informationen durch und kann bei Bedarf zur vorherigen Ansicht zurückkehren oder weitere Fragen auswählen.
7. Nachdem der Benutzer die Informationen erhalten hat, schließt er das Overlay oder die Pop-up-Anzeige und setzt die Beantwortung der Fragen fort.

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

Screenshot aus Penpot: