List your various requirements elicited from the user research.
- 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.
- 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.
- 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.
- 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:
- Access to hep should always be available in static states
- Description of Buttons should be ehanced with icons and clear labeling
- 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.
- Share the prescription of Novaminsulfon to to a doctor
- Find your Covid-19 Vaccinations
Liebes Team, vielen Dank für die Zusammenstellung der Anforderungen. Aber ich wundere mich, dass Sie die Erkenntnisse aus Ihrem einen Interview nicht als Grundlage für die Anforderungen genommen haben. Es scheint so, dass Sie das Interview eher verwendet haben, um sich selbst zu vergewissern, dass Sie auf einen guten Weg sind. Aber das ist nicht Sinn und Zweck von solchen Anwendungen. Des Weiten ist mir basierend auf Ihren Task Flow noch nicht klar, was Sie genau testen wollen. Personen werden das immer so „durchklicken“, aber „so what“? Wodurch wird ersichtlich, was Ihre Zielsetzung ist? Hier nochmal der Hinweis, dass es doch eher darum gehen sollte, eine nicht-accessible App/Taskflow mit einer accessible App/Taskflow zu vergleichen, oder?! Bitte diskutieren Sie das mal im Team. Aktuell werden Ihre Evaluationen wenig Erkenntnisse bringen. PS: Warum dieses ‚bunte‘ Design?