Designing for learning and knowing:

Nurses in chronic care and patients’ self-monitoring data

In this video I talk about my thesis. Below you can find the link to the actual text:

Designing for learning and knowing

My approach aligns with a design case study.

(from Practice-based Computing: Empirically-grounded Conceptualizations derived from Design Case Studies; in: Wulf, V.;Schmidt,K.; Randall,D.(eds): Designing Socially Embedded Technologies in theReal World, Springer, London, 2015, 111 - 150)

Step one: Ethnographic engagement

During the first phase, it is important to understand how the work of the nurses looks like and what real problems they are dealing with.

To be able to do that, I conducted an ethnographic study. It lasted approximately 3 weeks (8 hours of pre-observations and 3 weeks of full participation in the field). During this period, I shadowed and observed how the nurses work (both with their computer but also when conducting supportive talks with patients). I engaged in numerous conversations, collected photographs of the environment and documents the nurses use for their work. Later, I also conducted formal interviews.


I gradually started to focus on one of the issues the nurses experienced in their work: frequency issue. When the nurses talk to the cancer survivor (their main way how they learn about the survivor’s problem), they often need to pose a question about frequency of “How often do you …?” (experience pain, defecate, urinate etc.). However, that is an information that is difficult for the patient to recall, especially in sufficient detail that the nurse needs to know. The nurses engage in a range of strategies that help them elicit the needed information in deeper detail (Cerna et al. 2019). However, the information was always only an estimate, hence prolonging the treatment.

Step two: Product development

To be able to solve this problem, we have decided to draw on the recent advances in self-monitoring and self-tracking and design a mobile application that would allow the patients to document the development of their symptoms over time.


To do that, we brought together a team consisting of: two developers, three researchers (me, as an ethnographer with learning focus, the project manager with Applied IT background and another PhD student with background in Information systems), and a communicator (kommunikatör). Another relevant stakeholders who were involved in some stages of the product development were the main professor (who led the whole clinic and our project) and the patients.


The primary purpose of the application was to complement and support the communication that the nurses have with the patients about their symptoms. Hence, the nurses’ knowledge and expertise became the starting base for the requirements process, even though it is the patients who will use the application to collect quantified data about themselves.


The design meetings were organized as a series of meetings where the nurses, developers, researchers, and patients took part (see Table 1). Six design sessions took place at the hospital where the rehabilitation center is located, approximately once every three weeks from February to April 2016. The main themes of the design sessions were the user experience of the mobile application, the experience sampling, and the daily survey. A high fidelity prototype was then introduced to a group of patients, and a second prototype was created based on their input. The updated prototype was then downloaded by two patients, who tested it for several weeks. The patients’ experiences during the testing were then captured during another workshop and by follow-up phone calls.


Requirements solicitation

During the first meeting, the developers inquired about the nurses’ work and tried understanding what the nurses need to know to be able to help the patient manage their symptoms. These knowledge needs were later translated to the possible features of the mobile application and presented during the next meeting as low-fidelity mockups.

During these meetings, the common ground and language is gradually developed (participants come from heterogeneous domains, and need to first learn how to talk to each other, which terms to use for what).


Prototypes introduction to the nurses

During the upcoming meetings, various prototypes were presented to the nurses, ranging from low-fidelity mockups (a PDF with possible choices of the screens) to high-fidelity mockups (an interactive mockup presented on a computer). The nurses provided their feedback and informed additional requirements solicitation.


Patients’ involvement

Once the prototype was ready enough to be usable (so an actual mobile application), three patients were invited to test the prototype. During a session with them, we introduced the application: one of the researchers showed a walkthrough the application on a screen. After the introduction, we helped the patients to install the application on their phones. We let them use it for ca 3 weeks and then we met again to discuss their experience with the application. Collected feedback was further used to improve the mobile application.

Step three: Appropriation phase

Finally, once this test period was over, we made the application available online and the nurses started involving the application in their work.

This period lasted for approximately a year and a half and it is equally as important as all the previous parts - it is here not only to find bugs (that only appear when fully in use) but also to allow the nurses and the patients to fully understand the potential use of the application and develop their own routines on how to use the application in their work and daily life.

During the first year, one or two of the researchers served as a technical help when technical problems emerged, for example when logging in.

To be able to understand the use of the tool we designed, we recorded multiple phone calls of the nurses with the patients.