Health Management application JEREMY HENG & Josh fried

Findings & Conclusions

A more polished low-fidelity sketch was created by pulling out favored/more appropriate features from the previous sketches. Ultimately, navigation at the bottom seemed to be most appropriate and the card listing concept was also chosen. Also, headers for each 'page' were chosen to give users a better sense of where they were in the app and to serve as an error-checking mechanism.

High-Fidelity Prototype

A high-fidelity prototype was created using Adobe XD to actualize solutions for the problem space. The prototype demonstrated the interfaces and experiences that the user would be dealing with. It was designed to be a simplistic record-keeping system for four main categories: health records, health appointments, insurance, and contacts. The only actions that really exist for users are viewing, creating, updating, and deleting records. The prototype can be explored here.

Incorporating the Ten Usability Heuristics

Visibility of System Status: If a user clicks on an actionable item in the prototype, the resulting page will display/confirm the page they've been directed to (e.g. Add Contact listed at the top of the page after selecting to add a contact)

Match Between System & Real World: Icons used throughout the app are common interpretations of real world items. For example, a calendar is used to represent appointments and a syringe is used to represent vaccines. Using icons with real-world representations creates familiarity for the user and decreases the amount of cognitive processing. Additionally, terminology and health concepts used throughout the app are the same as would be used/seen in real life.

User Control & Freedom: Users are given complete control over the app and can freely navigate to records. They have the ability to add, delete, and update records that they have recorded in their app. Users also have the ability to exit app pages/screens whenever they want with the unchanging navigation menu at the bottom of the screen.

Consistency and Standards: Consistency was heavily incorporated into the prototype with the bottom navigation menu, colors, and screen headers being almost exactly the same across all pages of the app. Additionally, red/pink was used in the screen headers to indicate that a user was in a screen to add a new type of record.

Error Prevention: Users can see all fields when entering info into a data field instead of the field being hidden after entering something. Additionally, users can back out of pages that they accidentally clicked on by using back arrow in the navigation menu. At the top of each screen, the headers list what section of the app the user is in and the person who's health is being managed. That way, a user can easily see if they're in the wrong record or creation screen so that they don't edit the wrong information.

Recognition Rather Than Recall: Icons used in the app are familiar icons that most users should be able to quickly recognize. Text is also added below most of the icons to make it clear and easily identifiable what those icons do/represent.

Flexibility and Efficiency of Use: The app layout is quite simple and minimalist to increase the efficiency of use regardless of a user's experience level with the app. For experienced users, the layout and workflows for tasks would streamline their actions. Actions from screen to screen are very similar which would increase a user's proficiency.

Aesthetic and Minimalist Design: Each screen (other than the opening app screen) has the following sections: header, content, and navigation menu. Additionally, each screen only contains information related to a user's task so that a user would not need to sift through contextually-useless information. Specific colors and icons were used as part of the design aesthetic to signal available actions to the users or to signal where a user was in the app.

Help Users Recognize, Diagnose, and Recover From Errors: The app allows users to edit and delete all records that are added to their system. When a user is viewing a record, they have the ability to edit each field without having to enter a different screen. This makes it easier for user's to easily rectify mistakes when noticed. The system will notify the user if they upload a file that isn't of an acceptable file extension.

Help and Documentation: Throughout the app, there are easy-to-follow instructions that indicate what actions must be taken (if any). Also, most icons have their name displayed below them which enables a user to quickly identify items.

Applying User Experience Laws

Fitts' Law: Most UI elements that result in actions if clicked are quite large to make them quickly accessible to users. Elements that are unique to a screen were made significantly larger than the ones in universal navigation menus and screen headers.

Hick's Law: All of the app pages had three distinct sections: header, bottom navigation menu, and unique content. These sections were clearly marked and used as groupings for specific actions and information. A card system was used as a means of grouping like info in a list format which is used anytime the app presents a list of items for the user.

Methodology

Testing consisted of having volunteers perform the following eight tasks (tasks were specific to Anna Smith, a made up person whose info and records were already entered into the app): add an appointment, view a health contact, edit an insurance policy, add a prescription, view a person's age, find the list of surgeries, find a doctor's phone number, and attach a file to the dental insurance policy. For each task, the number of clicks to complete, number of wrong clicks, time taken to complete, and user satisfaction were recorded. These metrics addressed how effectively and efficiently users were able to use the app.

Following the tasks, the volunteers were given a post test survey that consisted of the System Usability Scale and a few demographic questions. The System Usability Scale contained ten questions, such as: I found the app unnecessarily complex, I thought the system was easy to use, and I thought there was too much inconsistency in this app. The post-task survey addressed how satisfied participants were with using the app.

All means, standard deviations, and graphs were processed using the following Python script that was developed specifically for this app's testing.

Five volunteers were chosen and tested from 11-16-22 to 11-28-22. The volunteers were as follows: 18 year old male with no partner or kids (A), 23 year old male with no partner or kids (B), 19 year old male with a partner and no kids (C), 60 year old male with a partner and four kids (D), and a 30 year old female with a partner and no kids (E). The reason for five participants is that Nielsen and Landauer reported that testing with only five users can find roughly 85% of a site's problems (1993). Using a small pool of participants will still find most of the app's issues, according to their research.

Test Results

For each task, all four task metrics were graphed on bar charts to more easily observe patterns and potential meaning. Additionally, results for the post-task survey were represented in bar graphs. For metrics or questions that had answers based on the Likert Scale, the responses were translated into numbers to make data processing easier, following this scheme: 0 = Strongly Disagree, 1 = Disagree, 2 = Neutral, 3 = Agree, 4 = Strongly Agree.

Task Results:

For analyzing results of the tasks, the mean and standard deviation were calculated (Figure 5). Also, the raw data was represented in graphs to better visualize patterns or anomalies (Figures 1 - 4).

The number of clicks it took to complete a task were quite consistent between participants, for the same task. Four of the tasks displayed a standard deviation of 0 and only two tasks had a standard deviation greater than 1.5 (Figure 5). This suggested that user experiences were fairly consistent, except for adding an appointment (T1) and viewing a person's age (T5). The high standard deviation for these tasks (7.402 and 6.033, respectively) suggested that user experiences were not consistent (Figure 5) and that the tasks were initially confusing for participants.

The overall number of errors when users were performing tasks was quite low which suggested that the app was intuitive and easy to use. Only Tasks 1 and 5 were concerning with having more than one participant producing errors (Figure 2). This observation further suggested that Tasks 1 and 5 were not consistent in participants' experiences.

Results from the time it took to complete a task were inconsistent. Standard deviations for completion time for all but one task were above 2 (Figure 5). However, none of the participants failed to complete a task which suggested that user competencies with the app varied. For almost all participants, tasks were completed in under 20 seconds which did not seem like an annoying or overburdensome amount of time to complete the tasks (Figure 3) because participants never showed frustration or anger when performing tasks. Although the completion times were inconsistent, they did not raise additional concerns of issues with users' experience.

User satisfaction for the tasks was quite high among all tasks and participants. Only for Task 1 did participants report something other than they agreed or strongly agreed that the tasks were easy to perform (Figure 4). This suggested that Task 1 was more difficult or confusing for users to complete. Additionally, standard deviations for user satisfaction were below 0.5 which suggested that user satisfaction was consistent among participants, within a task. Overall, participants seemed to be quite satisfied with performing app tasks.

Except for completion time, almost all calculated standard deviations were quite low which suggested that user experiences were quite consistent (Figure 5).