LITERATURE REVIEW
CHAPTER 3 METHODOLOGY
3.9 SISO Design Tool
3.9.2 PID Controller Parameter Using SISO Tool
1. Provide a quick, accessible overview of MuTI messages.
2. Make it work like GSM voice mail: If the doctor or nurse doesn’t answer, the caller can leave an asynchronous message.
Minimise cost to end user and community
Ethnography, RA/RI criteria
Contextual fit User Wi-Fi enabled mobile phone instead of GSM mobile phone.
At a user and organisational level, we needed to develop a version of the MuTI system that ran on a cellular phone: ‘MuTI in your pocket’ (this requirement was traceable back to the work models derived from the contextual inquiry findings). Our conversations with the nurses led us to believe that they would be more familiar with a cellular technology, find it less daunting and potentially easier to learn. Migrating the MuTI functionality onto a cellular phone would address several of the mobility and portability issues associated with the laptop solution. The MuTI training observations showed that during the message creation process, the tasks associated with media capture and attachment took the longest for the nurses to complete. For example, if a nurse wished to attach a photo to a MuTI message, she would have to take a photo with a standard digital camera, import it onto the PC and then use the file browser to attach it. We addressed the problem by utilising the integrated multi-media features of a cellular phone, thereby simplifying the media attachment process. Our vision was that a nurse should be able to capture and attach any media type within two to four button clicks.
At a functional level, the MuTI Mobile system was required to scale beyond two client devices (this requirement was traceable back to AS who pointed out that Canzibe needed four MuTI Mobile handsets, one for the hospital nurses to share and one for each doctor). To achieve this we migrated from a point-to-point to a client-server connection model. The new model would provide the necessary scalability, whilst allowing one-to-many and role based messaging.
The requirements and redesigned workflows are captured in the following scenarios:
4.5.1.1 Scenario 1: Call a hospital doctor on duty
A patient arrives at the Lwandile clinic complaining of an irritating skin condition. Sister Z examines the patient but is unable to make a diagnosis. She attempts to call the hospital and Doctor LZ answers. Sister Z describes the condition and Doctor LZ recommends that the nurse apply a topical ointment to the irritated piece of skin. The doctor further recommends that the patient continue treatment for five days and then return to the clinic for a check up.
The nurse ends the call and treats the patient.
4.5.1.2 Scenario 2: Send a message to the hospital doctor on duty
A patient arrives at the Lwandile clinic complaining of an irritating skin condition. Sister Z examines the patient but is unable to make a diagnosis. She attempts to call the hospital but there is no answer. The MuTI Mobile system switches to asynchronous messaging and presents the nurse with the “create a multi-media message” interface. She proceeds to take a photograph of the patient’s skin condition and attach it to the new message. Next, she records a voice message to describe the condition in more detail and appends that clip to the message.
The nurse then sends the message to Canzibe hospital, where the doctor on duty will receive it via MuTI Mobile.’
4.5.1.3 Scenario 3: Send a message to a specific clinic
A hospital nurse is assessing a patient that has arrived at the Canzibe hospital. The patient does not have a medical history book. The nurse questions the patient verbally to gain a better understanding of his condition. The patient claims he was referred to Canzibe by a nurse at the Lwandile clinic. Before sending the patient for a private consultation with the Doctor LZ, the nurse uses MuTI Mobile to call the Lwandile clinic. There is no answer. The MuTI Mobile system switches to asynchronous messaging and presents the nurse with the “create a multi-media message” interface. The nurse attaches a voice mail message in Xhosa and a picture of the patient.
4.5.1.4 Scenario 4: Send a message to all the clinics
Doctor SS needs to inform all the clinics of a measles outbreak in the Libode district and query whether they have the necessary vaccines and medication. If not, she requests that they inform her and specify the stock items they require so that she can bring them on her next visit or deploy a driver if the situation is urgent.
4.5.2 Generating a design solution
The low-fidelity prototype (see Figures 4-8 and 4-9) explored user reactions to two important features of the proposed design: The migration to a cellular handset and the integration of multimedia features.
Figure 4-8: Paper prototype of the original MuTI user interface
Figure 4-9: One of the sketches from the paper prototype of the MuTI Mobile system
4.5.3 Evaluating the solution
Low-fidelity paper prototypes were used to introduce TV to the MuTI Mobile concept early on in the design process and to capture her reactions, feedback and comments. Evaluating the paper prototype with TV, as opposed to the nurses, was not the author’s first choice, but was the only available option due to the busy work schedule of the clinic nurses. This was another example of using an informant as a proxy to represent the nurses’ voice in the design process.
The prototyping session began with a discussion of a paper version of the existing MuTI system. Next, we explored the concept of moving MuTI onto a cellular phone with the help of Figure 4-9 and other sketched prototypes. As the session progressed the author noticed that the TV appeared disturbed, and it became clear that she was concerned about any changes to the MuTI system. She said the nurses had just become familiar with the existing MuTI software application and how to use it. She suggested that instead of moving the application to a mobile phone platform, the author should improve the offline messaging feature, making it easier to use but still keeping it on the laptop computers.
The session failed to extract any significant feedback on the MuTI Mobile design concept;
what was evident was the nurses’ sensitivity to change.
4.5.4 Learning outcomes
4.5.4.1 The artefact
The wider ethnography provided two possible interpretations of TV’s reaction to the paper prototype. The first interpretation was based on her involvement at the Lwandile clinic, which she would often visit to use the laptop and practice using Windows and Microsoft Word – it is possible that her reaction was partly based on fear that the laptop would be taken away once MuTI Mobile was implemented. It is worth noting that Transcape had provided TV with an opportunity to attend additional IT classes in Mthatha and she would spend time practising on the MuTI laptop every Thursday when the nurses were busy with patients. She would also travel for almost three hours to get to the clinic if AS could not provide her with transport.
This was an indication of how dedicated she was to the training programme, how much she needed the income she generated from the training sessions and how valuable time with the laptop was. Taking the laptop away was not the research team’s intention and with hindsight it was clear that this should have been made clear during the introduction to the prototyping session.
The second possible interpretation requires us to consider that TV may have been confused as to the purpose of the prototyping session and what we were trying to achieve by discussing paper drawings. As Lim et al. [89] point out, this confusion may have been an effect of the prototype itself rather than the underlying design concept that we wished to convey. Stacey, Eckert and McFadzean [151] remind us that sketches are often ambiguous and open to multiple symbolic interpretations. Taking the abstract nature of the paper prototyping session and her fear of losing the laptop together, it was no wonder TV rejected the redesign process.
4.5.4.2 The process
Low-fidelity prototyping sessions were not very effective at capturing meaningful design feedback on the underlying MuTI Mobile concept. Our original design assumptions were therefore perpetuated into the next design iteration, effectively committing us to travelling further down the design path without gathering any significant design feedback from the target users or a proxy user. These findings are consistent with those of other ICT4Dev researchers. Parikh, Ghosh and Chavan [124] reported that rural Indian villagers were initially
very confused by the paper prototypes they were shown. The researchers needed to explain the broader purpose of their visit, what they were working on and why they were doing it before the villages understood the paper prototype. Despite the confusion being cleared, the researchers did not report any significant design feedback emerging from the paper prototyping session. Medhi, Sagar and Toyama [101] reported similar findings: Heavily abstracted imagery caused confusion when demonstrating interface concepts to illiterate woman in Indian slums.
Communicating design intent and reasoning in the early phases of a design process is one of the major challenges facing 4Dev designers. Inability to elicit meaningful concept or usability feedback from target users means the designer may commit significant resources to the exploration of a solution that may ultimately neither be found to be usable nor interpreted as being useful. Worse still, it may not even address a relevant problem.