The time has arrived to focus more on the user interface. Making an app intuitive requires laying out its functions in a way the fits the user’s natural way of doing things. Figuring out which functions will be used most often and in what order is a key to having intuitive navigation. Since prn:OnCall is an app for tracking interactions with patients, a natural way to start is with a patient list. Because iOS has so much built-in support for application design and navigation, a patient list can easily be configured to provide a gateway to other functions. With this in mind, I am using a ”command center” approach in designing the UI. All high-level navigation options will be present on the main patient list screen. These options will provide quick access to information that is not tied directly to a specific patient (e.g., a list of available locations). Information specific to a particular patient will be accessible only from within the context of that patient. Within each app screen I am still left with deciding which controls to use. iOS allows one to create reusable custom controls, which does allow for individual creativity.
As a personal learning experience, I am experimenting with how to use context as a design guide. The general idea is that users move from context to context and not simply screen to screen. What constitutes a complete context is not quite clear, but already the idea has helped to guide UI design and helped me get a handle of what I think will be better EHR UIs. I will write more about Context-Aware UIs in the future.
Preferences are another aspect of iOS apps that are proving to be more helpful that I initially thought. There is no limit to how many preferences one can add to an app. The great thing is that they allow users to adjust the app’s behavior. Simple things such as font changes are obvious candidates for preferences, but there is no reason that more important app features cannot be adjusted (e.g., the type data saved or with whom the app shares data). Preferences are a great usability tool.
Prn: OnCall, as currently envisioned, intentionally supports a very narrow need: documenting patient interactions that occur outside of visits. Since it is not an EHR, there is no need for capturing the details needed for billing or to fulfill the requirements of a formal medical record. Consequently, workflow issues are fewer. This is really a documentation and memory aid app. Areas where workflows will likely be an issue, such as adding a new patient, must be as efficient as possible. However, to delve more fully into formal workflow support will require input from users. As it stands, the current design is based on my of personal experience being on call and that of other primary docs I know. Fortunately, Apple has a great beta support, and I can create copies of the app for testing and user feedback.
At this stage, most of the key architecture and code design decisions have been made, but I am beginning to feel the need for more UI and user experience design input, which I need to think about for a while. I will say more about the topic of UCD in the next post.