Before we came to Kolkata, our team had spent the entire semester building a relationship with iKure and establishing what we thought was a justifiable and solid project plan. Our original intention was to design a technology-based tool for Indian Community Health Workers, which could support communication and problem-solving during their field visits. We fully intended to come to India with a few partially-built prototypes that we could get feedback on from the CHWs once we arrived.
Although we did not have a wealth of background context on the CHWs or their work environments from our partners, iKure’s seeming acceptance of our project plan convinced us to proceed down the path of iterative design and community-based participatory research, to build a nearly complete tool that supported CHWs’ roles.
However, things have not turned out quite as we planned during our time here in Kolkata; a discovery that has occurred on multiple levels of this project.
1) What is our actual project? Before we left for Kolkata, our team fully anticipated being able to do extensive contextual inquiry and pilot testing with a few small, yet flexible prototypes to determine what was most useful for CHWs given their workflow and variable health and technology literacy levels. Our partners at iKure seemed to agree with this plan. However a week prior to our departure, they essentially instructed that we build a “mobile” electronic health record… and scrap the project we had been working on for the last 4 months.
2) What about Community-Based Participatory Research and Contextual Inquiry? In public health practice and research, and in UX design, an essential process to developing a project or mHealth tool for communities is gathering input from these user groups, and evaluating their current contexts and routines. Although we attempted to begin this formative information-gathering from February to May, our partners never connected us with Community Health Workers–our primary user group–to conduct interviews via Skype or phone call. Furthermore, they seemed to express a disinterest in gathering the information we needed from the health workers, and did not understand why we needed to interact with CHWs or ASHA workers at all to build the technology tool.
3) What are our roles as a student team and within the iKure framework? This discovery was two-fold, because we not only needed to reshape what our individual roles were for the project, but also how we would contribute as a cohesive team to iKure’s operations and how we were viewed by their management.
Throughout the semester, we pretty much delegated Skype discussions to Nick, which meant he had to lead most of our conversations with iKure and answer the questions they had about the project. Although we thought this made logistical sense (we knew how to standardize the calls so nobody was talking over each other), we soon realized once we got to Kolkata that the iKure management believed Nick was the project manager, and would primarily interact with him–essentially ignoring Jackie and Anjuli.
We realized as a team that our roles needed to drastically change, especially since Nick had to take on the role as a developer and could not possibly balance this enormous task with project management, especially because our timeline for the project was shortened from a few months to a few weeks.
We decided that with Jackie as the project manager and UX specialist, Nick as the developer and health communication specialist, and Anjuli as the public health specialist and field testing manager, we were able to spread out our responsibilities more effectively, and better convey to iKure that we were a unit, a working team that contributed equal weight and insight to the project.
As designers for this project, our goals for the remaining weeks have been to gather as much information about CHWs as possible by pushing for frequent field visits (despite our partners’ reluctance), and improve our mobile tool using the feedback gathered from the health workers.
As consultants, we need to understand the future our project has in iKure, and hand-off documentation that includes: project sustainability recommendations, public health evaluations from our field visits, and technical style guides that standardize iKure’s existing technology framework and promote best practices for community-centered, action-oriented design and emphasize the importance of building with communities, instead of through a top-down approach.
We didn’t realize back in January that our partners had a completely different end-goal in mind for this project, but during our short time working in India, our team has learned that we need to be flexible with the current situation, just as our project needs to be flexible to support the needs of the Community Health Workers working in rural Kolkata. In addition to being flexible with the project, we want to continue pushing for visits with health workers, and hope that at the end of our time here, our partners finally see the value these visits have in determining how technology can be used effectively and appropriately in community health activities.
The Cali-Cuttas & Technologies for Rural Health 