Developing requirements for a mobile app to support citizens in dealing with ticks and tick bites via end-user profiling

Introduction

Ticks are small insects that feed on animal and human blood. In the Netherlands, the tick species Ixodes ricinus can infect the host with an infection called Lyme borreliosis or Lyme disease (LD) during the process of feeding. LD often starts with a relatively innocent skin lesion called erythema migrans (EM), sometimes accompanied by flu-like symptoms. When left untreated, LD can evolve into a serious chronic condition with symptoms like joint inflammations and neurologic complications. ¹ In the Netherlands, and Europe in general, the number of General Practitioner consults for tick bites and cases of an EM has increased rapidly in the last decade.^2,3 Preventing tick bites (e.g. by wearing protective clothing or using repellents) and checking for tick bites after spending time in tick habitats have been found to be effective and cost-efficient methods to prevent LD. ⁴ As a result, they have been propagated by health organizations as measures citizens should take, regardless of whether or not they fit in with the way citizens want to enjoy nature and how they want to deal with the risks involved. However, in order to achieve behavior change, and to make people comply with preventive measures for LD, advice needs to align with the needs and wishes of the target group. ⁵ In other words, one should only present those preventive measures to citizens that they are likely to adopt. One of the tools that can be used to tailor this preventive advice is mobile health (mHealth) technology.

mHealth technology is a new phenomenon that will change the way in which citizens consume health information and communicate with health organizations and health professionals. It allows citizens to access a health service where they need it and when they need it. ⁶ For the context of public health, mHealth is particularly suited for patient education, disease self-management, and remote monitoring of patients. ⁷ But in order to know how to design mHealth technology and to reap its benefits, experiences with the development and evaluation of these interventions need to be shared, something which is rarely done yet. ⁸

This article discusses the development of requirements for an mHealth intervention aimed at supporting citizens to deal with ticks and tick bites and persuading them to comply with preventive advice. When we talk about requirements, we mean specifications of what a technology should do, should look like, and how it should be implemented. The development process we applied is centered on the profiling of the designated end-user, and we show how one can derive end-user profiles for mHealth interventions and which requirements and benefits can be derived from them. This is one of the first articles to discuss in detail how one can design an electronic health intervention via end-user profiling and value-based design. The result of this process is a set of requirements that not only specifies what the technology should do (functionalities) but also how it should be implemented. A focus on the latter ensures that an mHealth technology not only has an added value to the user but will also be used and promoted by organizational stakeholders (such as Municipal Health Services (MHSs)).

In the next sections, we will discuss the foundation of our design approach and then chronologically discuss the different activities (such as brainstorms, interviews, and a focus group) we undertook in order to come to end-user profiles and requirements for a mobile tick app. At the end of the article, we discuss how such an app should be designed and reflect on the merits of applying an mHealth design approach that utilizes end-user profiles.

Design approach

The development of requirements was guided by the Center for eHealth Research (CeHRes) roadmap,^9–11 which focuses on creating electronic health interventions that are in line with citizens’ contexts and characteristics (following the principles of human-centered design ¹² ) and the creation of an implementation plan and business model. It consists of five phases, which are depicted in Figure 1 and, in all phases, formative evaluations improve the quality of design.

OPEN IN VIEWER

Figure 1.

CeHRes roadmap.

Table 1 shows the activities we deployed during the development of requirements and how they match with the main phases of the CeHRes roadmap. In this article, we will focus on the development of requirements and will therefore restrict ourselves to the first three phases: contextual inquiry, value specification, and design.

OPEN IN VIEWER

Table 1.

Phases, activities, and products in the requirements development process.

CeHRes roadmap phase	Requirements development phase	Main activities	Products
Contextual inquiry	Preparation	- Composing the project team - Deciding upon the overall goal(s)
Contextual inquiry	Stakeholder and primary end-user identification	- Audience segmentation- Stakeholder elicitation	List of primary end-users and stakeholders
Contextual inquiry	Requirements elicitation	- End-user interviews- Stakeholder focus group	Transcripts
Value specification	Requirements analysis	- Determining values and requirements- Profiling primary end-user	- Values and requirements- Personas
Design	Communicating requirements	- Completing requirement notation templates- Creating the design document	Design document

Project team and project goals

The first step was to compile the project team: those who would lead requirements elicitation activities, interpret results, and translate those results into requirements. The team consisted of one eHealth expert (working in academia), one mHealth expert (working in academia and for the Dutch National Institute for Public Health and the Environment (RIVM)), one public health policy advisor with an expertise in infectious disease control (working for the RIVM), and finally, one public health infectious disease nurse (working at a MHS). When the situation called for it, external expertise was consulted. For example, a biologist checked the correctness of information on ticks, and technical advisors provided advice on the technical feasibility of our plans.

Next, the project team set the overall goals of the app: to prevent people from contracting a tick bite, to remind them to check for tick bites, to teach them to properly remove ticks, and finally, to assist them in making the decision on when to visit their general practitioner after a tick bite. Mobile technology was introduced as a technology push. The adoption rate of this technology is estimated to be very high in a few years’ time, and it is likely that mobile technology will become the preferred medium for many citizens, instead of websites that should be viewed on a desktop computer. Furthermore, mHealth technology provides many opportunities for communicating with citizens at a time when it matters most (i.e. immediately when they notice a tick bite). The project team then set out to identifying stakeholders and primary end-users.

Stakeholder and primary end-user identification

Stakeholders (every party or person affected by the mHealth intervention ¹³ ) were first identified by the mHealth expert, the public health policy advisor, the public health infectious disease nurse, and additionally, the manager of a tick prevention project of a MHS. Stakeholders were identified by scrutinizing the Lyme borreliosis protocol of the RIVM. Then, a brainstorm was held to identify additional stakeholders. The following list with the most important stakeholders was the result:

Primary end-users were identified with the help of four MHSs that segmented the general population of citizens by conducting a risk analysis. They identified distinctive subpopulations that are most at risk of contracting LD, using a systematic procedure for risk determination for infection prevention. ¹⁴ For different groups of people, the following factors were determined: their size, chance of infection, influenceability, chance of comorbidity, information need, quality and amount of current preventive efforts, availability of effective interventions for this risk group, and finally, the social desirability that this group is catered for. A combination of scores for these assets resulted in three audience segments that were most important: Outdoors People, Parents & children, and Professionals in the green sector (e.g. gardeners and foresters). Catering for the specific contexts and characteristics of these audience segments would be most likely to result in a maximum effectiveness of the mHealth intervention. ¹⁵ Therefore, we decided to create one app for Outdoors People and Parents & children, as these groups partly overlap, while for professionals in the green sector, a separate mHealth intervention would be developed. In this article, we will focus on the development of the app for Outdoors People and Parents & children. These groups were taken as a focal point for design. Therefore, the next step was to profile them.

Profiling primary end-users

In order to profile Outdoors People and Parents & children, we conducted semistructured, in-depth interviews. Interview schemes were based upon an overview of end-user characteristics that need to be mapped in order to profile primary end-users of an eHealth technology. ¹⁶ The following aspects were addressed:

We recruited interviewees via the travel clinics of two MHSs. Visitors were asked to participate, as they often take part in outdoor recreation. As it turned out to be difficult to find parents with young children, we recruited an additional seven parents via a convenience sample (i.e. they were friends of colleagues). In total, we conducted 15 interviews with Outdoors People and 10 with parents. Although this number might seem small, the goal of our research was to support technology design and not to generate an overview of citizen’s attitudes and behavior with regard to ticks and tick bites upon which statistical tests can be run. Therefore, we stopped interviewing when we reached the point of data saturation (i.e. additional interviews did not generate new insights). After a short introduction, interviewees were guaranteed anonymity. Next, they provided informed consent and gave permission for an audio-recording. We questioned parents about their children, ticks, and LD. The interview protocol can be found on http://docs.ehealthresearchcenter.org/lex/Appendix%20A.pdf. Audio recordings were transcribed in ATLAS.ti and coded by using the categories for persona attributes from LeRouge et al. ¹⁶ Next, we made an overview of each interviewee’s response to the most important attributes.

Personas

As we stated before, communicating preventive health advice is most effective when advice is tailored toward the needs and wishes of a person. Therefore, we created an overview of the primary end-user’s needs and wishes, upon which we could consequently tailor preventive advice.

The interview results made it clear that the two primary end-user groups should be split further. Although all persons in these groups ran the risk of contracting a tick bite at one time or another, distinctive sets of behavior and attitudes toward tick bites and tick bite prevention measures were found for Outdoors People who do or do not check for tick bites, as well as for Parents who do or do not check their children for tick bites. For each of these four groups, we created a persona. Personas are descriptions of fictitious persons who resemble an end-user group. ¹⁷ The advantage of using personas is that they are easy to understand and are a good means to inspire eHealth design and its implementation and to engage the design team. ¹⁸ The personas were created by following a procedure set out in van Velsen et al. ¹⁹

The characteristics of Outdoors People who do not check for tick bites corresponded with the answers of 12 interviewees, making it a primary persona. This persona does not really care about ticks or LD, does not visit risk areas often, does not check for ticks, and intends to use an app only when noticing a tick bite. Outdoors People who do check were represented by three interviewees, making it a secondary persona. This persona has experience with tick bites, often visits risk areas, (almost) always checks for ticks, and will use an app to read about ticks out of curiosity.

Parents who check their children for tick bites were in the majority (eight interviewees), making it another primary persona. They are concerned about ticks and the risks involved, their children often play in backyards and forests, and they (almost) always check their children for tick bites when they have been in an endemic area. Finally, they would use the app when noticing a tick bite. Parents who do not check were represented by two interviewees, making it another secondary persona. They do not think the risks involved are high, and consequently, they never check for tick bites. Their children often play in backyards, and they would rather consult a mobile website when noticing a tick bite on their child.

Figure 2 shows the persona for Outdoors People who do not check. All personas can be found here: http://docs.ehealthresearchcenter.org/lex/Appendix%20B.pdf

OPEN IN VIEWER

Figure 2.

Mark: the persona for Outdoorspeople who do not check.

Consulting stakeholders

In order to get input from the identified stakeholders about our plans for a mobile app, we conducted a focus group. We invited representatives of each stakeholder group, except for patients who were already catered for by means of the interviews and personas. The intermediaries were represented by persons working for scouting groups and the National Forest Service. Additionally, we conducted a separate interview (with the same setup as the focus group) with the trade organization for entrepreneurs in the recreation branch (e.g. camp site owners), as they were unable to join the focus group.

As a preparation, the participants were asked to read the personas and scenarios we created on the basis of the personas (stories of encounters with ticks, demonstrating the current prevention and care path). This was done in order to spark the discussion. During the focus group, we mapped each stakeholder’s role in the prevention and care path of LD, we identified bottlenecks, and finally, we asked feedback about preliminary design ideas (e.g. a tick radar, demonstrated by showing a German tick radar: http://www.zeckenwetter.de). The focus group lasted 2 h. Spoken text was transcribed in a Word document to serve as input for requirements specifying the implementation of the app.

Guidelines for designing a mobile tick app

In order to come to design guidelines, we first determined the values end-users and stakeholders have. Values are ideals or interests a (future) end-user or stakeholder aspires to or has. ¹¹ They are important directives for the design of the mobile tick app as they indicate what general goals it must absolutely serve, or which (personal) principles it should not violate. Then, we identified requirements. Requirements are technical directives, specifying how the mHealth intervention should be designed. Following a procedure devised by van Velsen et al., ¹¹ one project team member and an external eHealth expert identified values and requirements for the system. Sources for values and requirements were the transcribed interviews, the focus group, and the personas.

In total, we identified five values, of which three hold for the potential end-users:

The designated end-users (Outdoors People and Parents) want to be informed of the risks ticks pose and how they should deal with them. Second, these citizens want to enjoy nature in a carefree manner. This is their first priority when they go outdoors, and they do not allow the risk of a tick bite to interfere. Relatedly, they want an intervention aimed at supporting them in dealing with ticks and tick bites to be easy to use.

Four values hold for professional stakeholders:

First of all, stakeholders want to be well informed of the risks ticks bring with them and how their organization should deal with them. Second, interventions aimed at supporting them should be easy to use; they should fit easily in existing working routines. Furthermore, an intervention should be provided to them on time, and it is important for them that they can promote their own identity or organization name.

Next, we identified requirements. We will summarize those with a high priority (i.e. those requirements that are crucial for an effective mHealth intervention that is adopted both by end-users and other stakeholders).

Conclusion

In this article, we have discussed the development of requirements for an mHealth intervention aimed at supporting citizens to deal with ticks and tick bites and have listed high-priority requirements. Our development process was centered around the profiling of the prospective end-user and has made three things clear. First, it underlined the necessity of thoroughly investigating the designated end-users and their context of use. Each primary end-user group (or persona) has a different set of characteristics and context, which must be catered for in the mHealth intervention. For example, one of the end-users’ values was “enjoying nature in a carefree manner,” and therefore, promoting checking for tick bites is most likely to have a higher return on investment than advertising other preventive measures such as wearing clothes that cover the body. The latter would be medically correct and complete but will have a poor fit with the context in which it is to be used. In this case, the adoption and impact of the intervention will be low. Such a tactic does imply a shift in developing communication strategies by public health organizations. Traditionally, they communicate all preventive measures for a given condition to the public that have proven their worth in scientific studies. Instead, they should make a selection of measures that work and that will be easily adopted by the target group. This tactic should also work for situations besides tick bites, unless omitting a precaution leads to great risk for the citizen. For example, prevention of food-borne infections may benefit from this approach: there are many possible precautions (not consuming raw milk, boiling food, preventing cross-contamination via cutting boards, etc.), of which some will be more easily accepted than others. In order to simplify the message and make it more actionable, only easily adoptable precautions should be communicated. Second, this case demonstrated that public eHealth technology that aims to increase healthy behavior (such as checking for tick bites) is per definition also persuasive technology. Persuasive health technology has the goal to form, alter, or reinforce attitudes or behaviors in order to improve health without coercion. ²⁰ Several requirements that resulted from our contextual inquiry (reminders, tailored information, and the inclusion of an authoritative source) aligned with persuasive system features that have proven their worth in the past. ²¹ It is therefore of high importance for eHealth designers to be aware of the features that improve eHealth persuasiveness, and when and how to implement them. Third, and finally, we have elicited and formulated several requirements that were not focused on the technical device itself, but on its implementation (e.g. when to send promotion material to campsites and to leave white space on this promotion material so they can include their own logo). From the focus group, it became clear that these stakeholder demands were extremely important. If we would not take these wishes into account, organizations would not be willing to promote the app, regardless of the app’s proven worth or value to end-users. Developers of mHealth technologies should therefore be not only great technology creators but also connoisseurs of the organizational context in which they are embedding their technology and how to serve the actors within this organizational context.

Designers should take into account that when they take our findings as input for their own mobile tick app, these requirements are partly a product of the Dutch situation. There may be a difference in information needs, attitudes toward the risk of a tick bite, and attitudes toward preventive measures between endemic and non-endemic countries. Furthermore, different countries or regions can have different tick species that spread different diseases, may have a different set of organizations that are involved in preventing and dealing with tick bites, or may have different technical possibilities (e.g. the number of locations with no reception for mobile data traffic). In order to deal with these issues, the project team should consult a biologist, and they can replicate our requirements development activities in order to identify and profile primary end-users and to consult stakeholders.

The requirements we have discussed in this article will allow us to design an mHealth intervention that has the capacity to persuade the target group to conduct healthy behavior with regard to tick bites while respecting their values (such as enjoying nature in a carefree manner). In the next phase of the project, we will come to a design by several rounds of prototyping. Finally, we will assess the uptake and effect (assessed in terms like “increase in checking for tick bites” and “confidence in one’s ability to remove a tick”) in a trial.