Step 2: Developing the SMS system’s architecture and programming framework
System architecture and programming frameworks are helpful for SMS implementation planning as they can guide researchers in determining different parameters for the way messages should be sent to participants. A message architecture specifies aspects such as the message types (e.g., texts sent to prepare participants for the program, texts sent to remind participants of the upcoming session, texts sent after intervention sessions to reinforce content), timing and scheduling of message delivery, the volume of messages, personalization and any other advanced programming or logic considerations. These frameworks should be broadly robust (i.e., applicable across different users, sites, and adaptable to idiosyncratic disruptions such as different schedules for different groups) and not produce additional barriers to access (e.g., not sending messages at inconvenient times, not sending an overwhelming number of messages),The first SMS system decision researchers should make is whether it should function as a two-way or one-way messaging program. In two-way systems, participants not only receive program messaging to their mobile devices, but they are supported to text back questions and receive individual attention and responses from program staff assigned to monitor the system (e.g., CHWs) or advanced chatbots (automated systems that generate replies, often based on keyword content). One-way SMS systems only support communications to be sent to participants; participants may text into the program, but in a one-way system, inbound communications are not monitored in real time (or at all) and participants would generally receive no replies to their text messages. Deciding upon implementing a two-way vs. one-way system involves discussion around both pragmatism (e.g., does the project have the available resources and staff to support consistent two-way monitoring and replies?) and need (e.g., does the population and behavior require ongoing interactive support to achieve targeted outcomes?).Attrition and retention are key indicators of the system’s implementational success, and conceptualization and measurement of these outcomes may differ depending on system architecture – specifically, whether a one-way or two-way system is built. For both types of systems, if a “STOP” command is built in (i.e., a participant can reply “STOP” at any time to leave the SMS program), tracking the number of participants who opt out is one metric for attrition. Regarding retention, most SMS systems will allow researchers to identify if participants are successfully receiving SMS messages to their phones. For one-way systems, retention can be measured over time by tracking how many messages are successfully delivered between and within individual participants. For two-way systems that generally elicit dialogue between a coach and participant or require the participant to reply to particular messages, participant responses can be tracked as a measure of retention. Overall, to mitigate attrition and support retention with the SMS system, a research team member (e.g., a CHW) should be tasked with reaching out to participants who are either not receiving their SMS messages or not responding as requested. In some cases technical assistance may be necessary (see “As a general rule of thumb when considering system architecture, researchers must ensure potential participants will find the SMS system’s programming logic (i.e., timing, volume of SMS) to be culturally appropriate to their needs and preferences. One way to ensure system architecture matches the target population’s preferences is to seek the help of a community advisory board (CAB) made up of multiple stakeholders from the target community (e.g., local residents and community leaders) who can assist researchers by making system programming recommendations regarding timing and frequency that would be acceptable to target participants [Researchers should also consider specific requirements of the intervention program that the SMS system is designed to support in terms of “types” of messages and timing. For example, is it sufficient to send messages from a single bank of messages (i.e., a single type) on a consistent schedule over time (e.g., 2 weekly messages from the bank for 8 weeks)? Alternatively, some intervention programs may require different types of messages to be sent at different times and at different frequencies (e.g., there may be messages that need to be sent in the early phase of the program that are different from messages that need to be sent at a later phase and/or messages may need to be sent more frequently initially and then taper). Based on these kinds of considerations, the types of messages and the schedule may be quite simple or very complex to design. Researchers should also consider the possibility of potential schedule disruptions and how any time-based message system will adapt to those scenarios.In many LMIC contexts, program participants may be close friends, neighbors, or family members living within the same household or community—and participants may share their individual text messages with others. This prompts another level of consideration of the system’s architecture – the degree of personalization integrated into SMS logic and content (e.g., including participants’ names, tailoring content to individuals’ data). With close cross-participant interaction in mind, messages may be more impactful if some elements of personalization are adopted, which may enhance participants’ internalized feelings of program “fit”, commitment, and engagement [Researchers may choose to adopt an SMS framework that incorporates an individualized “tailoring” process. This strategy from behavioral science is intended to enhance motivation and engagement with intervention content by making participants feel individually supported in achieving program goals and having a program that is “personalized” for them [