Case Study: Hospital Run Heuristics
From 2020 to 2022, I am working on an outsourced project, Hospital Run. Hospital Run provides offline software for developing countries. As a UX designer, my role is to make sure I set a plan to inspect the software from an efficiency and usability standpoint and build a bridge between the needs of the users and a team of developers.
First, I performed Heuristic Evaluations to see where usability is lacking and what needs to be improved. I used the Heuristic Evaluation method by Jacob Nielsen and his ten rules:
Visibility of System Status;
Match Between the System and Real World;
User Control and Freedom;
UI Internal/External Consistency;
Design/User Error;
Recognition over Recalling;
The flexible process is carried out in different ways;
Minimalism;
Help to Recognize, Diagnose, Recover from mistakes;
Help and Documentation.
Each rule was inspected, and a variety of recommendations were determined.
1) As we see in Hospital Run Software, initially, the visibility of system status was achieved by changing the color of the buttons. The accessibility by #HEX colors and difference with the background was run on all of those changes. Propositions to change the color of some buttons were dictated by the accessibility test.
Before
After
2) The language used in the software is clear and easy to understand. Therefore there is technical or specific language that might get some people confused. The medical terminology like labs, patients, imaging are applicable within the field and make sense in given settings. In terms of design being skeuomorphic, there is not a match with specific physical objects because there is no such need. Only we can say that calendars match their paper grandparents, as category icons remind things from the actual medical world.
3) User Control and Freedom refer to fixing the mistakes and being able to undo the action. There are no undo options possible in the software; there is not even a left error that leads to going back steps. There is only a < sign to the left of the page; this is part of the dashboard that is not related to undo option.
4) Regarding the cancel button, there is a bit of misunderstanding between the two versions of the Hospital Run Software. Research has shown that the Cancel button should be placed to the left while moving forward (save and continue) buttons should be set to the right as a sign of moving forward. In Hospital Run, few options have been seen so far, and we need to make sure that the developer's team makes sure that the issue is fixed.
5) For older versions of the software, both Internal and external consistencies are achieved. Internally within the application, it uses the same colors, fonts, elements, etc. At the same time, there is a match with the overall medical software look achieved by blue-ish tones, specific graphic elements, and a minimalistic approach. The only concern is a new version of the software that has some inconsistencies in the styling in columns, and also, the mobile version that needs to be created should reflect the same UI template.
6) If we put some information in the Hospital Run software and something went wrong, the error message would explain what happened. Still, after you submit the results, and even if you have multiple mistakes, will you most likely show and explain just one.
7) During evaluations, we noticed that the staging version of the software was overwhelmed with information that could be hidden and recalled only when necessary. For better Recognition and less recalling, we recommend the process of check-in in the patients through the mobile app to make the process easier.
8) The design approach to the Hospital Run is very minimalistic. At this moment, the team of developers is working on the second version of the application. But for now, it seems like most of the design solutions will stay the same, being pretty simple and elegant.
9) Possibility of the error in the staging version of the software is high due to some logic errors like the one below. Also, in the software, it’s unclear when filling out the forms which specific field is required and which one is not. Also, some errors were found in creating the patient when the patient was created, and some mistakes were eliminated.
10) For this stage of the development, Hospital Run Software has no Help or Documentation section. There is not much support from the developer that we can get when an error occurs or when there is a question. At this moment, the only source people can try to get a hold of and get help is the Hospital Run Git Hub page: https://github.com/HospitalRun, where anyone can post-issue or ask questions. Also, if users have a question, they can send an email: hello@hospitalrun.io. Additional information about software as a long blog can be found on the website: https://hospitalrun.io
Unfortunately, the help within the software itself is not available at this stage.
SCALE EVALUATION
The scale Analysis system example was taken from Nielsen Norman Group (https://www.nngroup.com/articles/rating-scales/)
Used Likert Scales: “In a Likert scale, respondents are asked how much they agree or disagree with a set of statements. An overall position is derived after analyzing all responses to related questions. Using a Likert scale, usability assessment questionnaires, like System Usability Scale (SUS) and Standardized User Experience Percentile Rank Questionnaire (SUPR-Q). “
Semantic Differential: “Semantic-differential questions require respondents to rate their attitude by selecting a position on a bipolar adjectival scale—the two ends of the scale host antonym adjectives (e.g., ugly-beautiful, easy – difficult). The Single Ease Question (SEQ) is an example of a semantic differential scale. The SEQ presents a 7-point scale with the ends labeled very easy and very difficult.”
In the first round of scales evaluation, we were trying to see how hard or easy tasks were. At the same time, how intelligent the software is, We wanted to make sure that we consider how usable the software is and if it’s hard or not to perform simple tasks.
As a result of the software overall neither satisfying nor not straightforward, concerns like usability, ease to navigate, and ability to prevent and fix mistakes.
The second test took typical tasks like scheduling appointments or creating a new patient and tried to see how easy or hard it is. Overall, it’s not hard to perform the job, but some fields are not easy to fill in because of a specific language. So 90% of the process can be ruined because some information asked to fill in is not clear. And there is no option to skip it but save the whole bunch of other stuff that is ready to be submitted and is most necessary. This may cause a lot of confusion and slow the process a lot!
RECOMMENDATIONS
Make sure every category and all words and phrases are clear to all people;
Colors-coding for the software interface to make sure that it’s readable and accessible;
The implication of the design elements from Figma to staging version; creating the overall recommendations and making sure that components are put to the Components Library in GitHub so developers know and can use those elements for correct interface look and functions;
Undo Options have to be provided as left error or back button, Cancel and Next buttons should shift in places, so users are protected from making mistakes;
UI consistency from XD file; Overall look of the elements and some columns should be developed to be consistent and well-looking in terms of straight lines and a clear geometrical matrix.
The error message should specify every mistake and give suggestions on how to correct them;
Recognition/Recalling issue, functions that are not needed at the moment should be hidden. But not in the way it is in the software now. In the staging version, using errors down creates a crowded screen. For the functions like creating patients and check-in in for the patient, we recommend making a mobile/tablet application that will help check in patients in a faster and more convenient way.
The flexibility of the processes should be achieved by applying shortcuts in the software to make the work easier and faster.
Make sure there is help and documentation if case it’s needed, not as a GitHub outside source, but inside the software;
Ensure that if stuff is unnecessary to fill in the tab, there will be no error when submitted by leaving it blank. Make sure that drop menus make sense and that we can save progress even on 50% and come back to finish it without losing any entered data.