Doctors Diary
As a part of the course Development in Platform Ecosystems at the University of Oslo, we were tasked with designing and building a new component for DHIS2 based on a selection of descriptive cases derived from real projects in the DHIS2 Design Lab.
The case
In Uttar Pradesh, India the Ministry of Health would like to get more insight into the workload and challenges the health staff faces at the various hospitals and clinics throughout the state. To do so, the Ministry would like to utilize the statewide Health Management Information System, DHIS2 to support the collection, flow, and presentation of information.
The Ministry thus wants an easy-to-use interface where doctors are able to submit a brief daily report to the District Health Officers related to patient care, use of the equipment and any related issues for their respective action.
Design without access to the intended end-users.
One of the most essential parts of creating good artifacts is knowing who you are creating it for. Thus, we as designers utilize a plethora of methods and techniques to gain insight into our intended users. Without this essential information, we are left with an educated guess based on assumptions.
As we were not able to involve the actual doctors and health officers ought to utilize the created system in the design and development process we had to base our design on what information we had available. We thus broke down the case description and researched the implementation context to the best of our ability and came up with a set of frugal personas, activity-oriented scenarios, and a list of contextual constraints and enablers. In addition to the creation of these “user substitutes”, we reviewed literature related to the implementation of health information systems and the challenges related to use and came up with some challenges our solution had to address.
Hospitals seldom have computers, a stable power supply or an internet connection. However, all doctors had been supplied and were familiarised with smartphones due to previous mHealth projects in the state. 3G or 4G connection had good coverage throughout the state, but the throughput could be minimal and connection unreliable at times. Most health facilities had issues with low staffing and a heavy patient load, which rendered the health staff with limited capacity to learn and operate advanced digital interfaces. In combination with the issue of “data vacuuming” highlighted throughout literature, our solution had to feature:
- Simple and familiar User Interfaces
- Optimization for mobile as well as desktop computing
- Limited and compressed API calls and Local Storage
- Offline capabilities and automatic database synchronization
- A doctor specific journal emphasizing practitioners data ownership
- Emphasis call to action design to guide actions
Design Process
Based on published literature, empirical learnings from the Information Systems Research Group, an activity focus, and our bare-bones user personas we set out to explore the given design space.
Early on in the process, we realized that the goals of our user roles were quite distinguished and that there also were separate infrastructural constraints. Thus, we made a conscious decision to design two seemingly different applications, that were optimized towards achieving the respective user goals. Doctors needed a fast and lightweight application that communicated at a glance what actions where needed on their part. Their system needed to be optimized and designed to handle rapid mobile reporting. District Health Officers, on the other hand, would receive large amounts of reports each day from their district and needed a desktop-oriented application in their work.
As the doctor-persona we created had limited prior experience with digital artifacts, we thought it wise to base our design on a skeuomorph. Thus, we oriented the doctor's UI around the familiar calendar.
Learning Outcomes
There are many things working on this project taught me. The web app was to be an extension of an existing platform that is utilized by the state. This posed an interesting challenge and shaped the afforded design space. It was also interesting to work without any active and direct user participation. Having to mimic users arguing and grounding our design choices in these artifacts was a great source of learning and the limited user data we were able to gather got our design quite far along.
Building upon an existing platform also poses technical learnings, as we got to experience and play around with boundary resources afforded to third parties to facilitate innovation through the extension of the platform core.
We also got to experience working with a design system, which helped us speed up development and focus on optimizing flow and use-related affordances. This project introduced a few firsts for me, such as writing a more extensive application with React, creating and utilizing Higher-Order Components, as well as being in charge of reviewing and handling all merge requests to the project repo.
The repo with all source code and more detailed explanations of this project are currently only available through the University of Oslo’s enterprise Github. I might change that in the future.
