Prototype

We continued to improve our prototype by adding more interactivity to facilitate exploring of our UI. Additionally, we now have emergency informations, more help details and an option to share a „Befund“.

Summative Evaluation

• What documents do you need?
  • Standardised Questionnaire (NASA-TLX) 9 Kopien
  • Testskript
  • Consent Form
• 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.
  • We chose to use a post-task questionnaire
• Which standardized questionnaire did you choose and why?
  • We chose the NASA TLX questionnaire
  • We chose post task, because our tasks are relatively independent from each other and therefore more likely to produce differing intersting insights, that might be lost if not captured immediately
  • We chose NASA TLX because our domain is in the area of accessability features. As such we are very interested not only in the general difficulty of a task.
    But also in other more specific metrics relating to the difficulty of task completion (physical, frustration, etc. )
• What could be improved for the tasks?
  • Make the goal less specific
    (Share Document X to doctor Y vs Share a document to a doctor)
  • Write Task more like a scenario

Material

Prototype:

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

Task 1:

Sie sind beim Arzt (Dr. Example) und er muss Ihr Großes Blutbild einsehen.

Task 2:

Sie haben eine schlechte Erfahrung mit Dr. Example gemacht. Entziehen Sie ihm den Zugang zu Ihren Röntgenbildern.

Task 3:

Sie sind im Haus Ihrer Großmutter und sie hat Atemprobleme. Für diese Fälle haben Sie Zugriff auf die biometrischen Daten ihres Telefons und können es entsperren. Finden Sie Informationen über ihre Allergien.

Evaluation:

https://forms.gle/H1k6a2RTzdXJTL8QA

Consent:

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

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

Problem Statement

Martin (pensioner) needs a way to effectively use the ePA of the TK, while making use of his accessibility tools because he is unable to use the current interface with his fontsize and it is not yet possible to integrate text-to-speech or speech-to-text programs.
We will know this to be true when we see Martin using the full functionality of the ePA. When prompted how his experience with the App is, he should say: “Da kann man nicht meckern.”

Hypothesis Statement

We believe that by improving the TK ePA app to work better with accessibility tools for Martin, we will achieve greater usability for this app, especially for the elderly and people that use the accessibility tools that are provided on their devices.

Sketches

Storyboard

Reflection

Gathering data using bing, chatGPT and Bard

Our goal was to explore possible the usefulness of LLM’s for finding information about the ePA’s usability and accessibility. We looked at the free version chatGPT provided on https://chat.openai.com, at the bing chat mode and at the recently released LLM by google, Bard.

We soon found that google’s Bard is far from remembering the context of a conversation as good as the GPT based chatbots. We were not able to keep up a useful conversation.

ChatGPT’s major flaw for our use case is its lack of recent information (up until 2021) and internet access.

Bings chatbot, which is based on GPT4, does not have either limitation, but a conversation is limited to 20 prompts. However, bing states it is not able „to find any specific information about the usability of the German ePA (elektronische Patientenakte) or its accessibility for people with impaired vision.„

Indeed, our research we did for exercise 2 showed that there is not much information about this on the internet. Additionally, the ability of LLM’s to find niche information, which might only occur a handful of times in the entire internet, is very limited.

Creative tasks seem to be more suited than finding rare information. Bing is able to generate personas and scenarios based on the context that I created when prompting bing for information about the usability of the ePA.

https://sl.bing.net/bpYTyTkKyzY (3 personas, 3 scenarios)

Using Reddit to gain insights

Out of curiosity, we published a post on a German developer thread and received plenty of feedback and strong opinions.

The opinions varied from strong rejection due to data security and data centralisation concerns to people welcoming the change and digitalisation of the German health system. People complained about the registration process of the TK app while others shared very positive experience about the ePA and the TK App.

An interesting idea was to contact journalists writing about the ePA and related topics to gain more insights and potentially find an interview partner.

Persona (generated by bing)

Name: Martin Schmidt

Age: 60

Occupation: Retired

Location: Hamburg

Health status: Glaucoma (increased pressure within eyeball), has severe vision impairment and needs a cane to walk, can use digital services with difficulty and assistance

Goals: To maintain his independence and dignity, to get support and care when needed, to stay informed and connected with his family and friends, to enjoy his hobbies and interests

Frustrations: Low vision aids and devices, inaccessible or complex websites and apps, lack of empathy or awareness from others, social isolation or stigma, loss of mobility or freedom

Motivations: Accessibility, simplicity, reliability, safety, comfort

EPA usage: Martin uses the ePA app on his tablet with a large font size and high contrast mode. He also uses a text-to-speech software and a speech-to-text software to interact with the app. He uploads his eye pressure measurements and medication schedule to his ePA occasionally. He also downloads his test results and doctor’s notes from his ePA and listens to them with headphones. He grants access to his ePA data to his ophthalmologist, his general practitioner, and his son. He dislikes the ePA app because it has many usability issues for him, such as small buttons, unclear icons, long texts, confusing menus, and inconsistent layouts. He also complains that the ePA app does not work well with his assistive software and sometimes crashes or freezes. He wishes the ePA app could be more user-friendly and accessible for people with low vision. He also hopes the ePA app could offer some features like voice control, audio feedback, zoom function, and help function.

Scenario

Martin has an appointment with his ophthalmologist next week. He wants to check his eye pressure and see if his medication needs to be adjusted. He decides to use the ePA app to prepare for his visit. He opens the app on his tablet and turns on his text-to-speech and speech-to-text software. He says “Login” and the app asks him to enter his PIN. He says his PIN and the app confirms that he is logged in. He says “Show me my documents” and the app displays a list of documents that he has in his ePA. He says “Sort by date” and the app sorts the documents from newest to oldest. He says “Open the latest document” and the app opens a PDF file that contains his last test results from his general practitioner. He says “Read aloud” and the app reads the document to him with a synthetic voice. He listens carefully and tries to understand the numbers and terms. He says “Stop” and the app stops reading. He says “Go back” and the app returns to the list of documents. He says “Open the second latest document” and the app opens another PDF file that contains his last eye pressure measurements from his home device. He says “Read aloud” and the app reads the document to him. He listens and compares his current measurements with his previous ones. He says “Stop” and the app stops reading. He says “Go back” and the app returns to the list of documents.

He wants to share these two documents with his ophthalmologist before his appointment, so he can review them and give him some feedback. He says “Select the latest document” and the app selects the document. He says “Select the second latest document” and the app selects another document. He says “Share with my ophthalmologist” and the app asks him to confirm his choice. He says “Yes” and the app asks him to enter a time limit for the access. He says “One week” and the app confirms that he has granted access to his ophthalmologist for one week. He says “Send a message to my ophthalmologist” and the app opens a message window. He says “Hello, I have shared my latest test results and eye pressure measurements with you via ePA. Please take a look at them and let me know if you have any questions or concerns. Thank you.” The app transcribes his speech into text and shows it on the screen. He says “Send” and the app sends the message to his ophthalmologist.

He hopes that his ophthalmologist will reply soon and give him some advice on how to manage his glaucoma better. He says “Logout” and the app logs him out of his ePA account. He closes the app and puts away his tablet.

Reflection of last week

Instead of investigating a non existing DiGA or an existing Health app that is not registered as a DiGA tackling Asthma, we decided to go for an existing DiGA or even switch to the ePA. The ePA is more interesting to us three and also affects all of us. It will soon be relevant to the entire German society and thus have a big impact. Additionally, the ePA is easily (we all see about that) accessible to all of us and brings some interesting questions. Some points of interest are the acceptance and usage of the ePA among doctors and the meaning and consequences for the elderly or other groups not that are less familiar with or able to use digital services.

Humanity centered design

The main take away from the article is the concept of Humanity Centered Design, meaning a design approach that is not focused on the individual user but on the society or humanity as a whole. The goal of a humanity centred design is to benefit the global good and wellbeing. This concept is hard to apply to apps that are specifically developed to fit the German law that defines the DiGA.

Ressources

TK DiGA Report:

https://www.tk.de/resource/blob/2125136/dd3d3dbafcfaef0984dcf8576b1d7713/tk-diga-report-2022-data.pdf

AOK DiGA Umfrage:

https://www.aok.de/pk/cl/rh/inhalt/apps-auf-rezept-insgesamt-positiv-bewertet-aber-fuer-viele-verzichtbar/

LinkedIn zu UX in DiGAs:

https://de.linkedin.com/pulse/usability-und-user-experience-ux-von-digitalen-diga-hosun-lee?trk=articles_directory

Bewertung einiger DiGAs von Stiftung Warentest:

https://www.test.de/Digitale-Gesundheitsversorgung-Apps-vom-Arzt-verordnet-was-steckt-dahinter-5552344-0/

Reflektion

Entscheidungsprozess nimmt viel Zeit ein. Auch weil uns die genauen Anforderungen etwas unklar sind.

Zeitmanagement muss besser werden. Arbeitsteilung läuft gut 🙂

Arbeit mit Trello hilft, weil man zusammenarbeiten kann.

Wir müssen unser Thema, Stakeholder etc stark einschränken bis nächste Woche.