Table 1.

Requirements, decisions, and considerations in the design of Daily24, a circadian ecological momentary assessment (cEMA) app.

Requirement		Daily24 design decisions	Additional considerations
Front end
	Collect recurring, circadian data, but limit collection to essential data	Focus on sleep and diet (and not activity)	Should be fast and easy to enter data; specific variables based on core (causal) model of the research hypothesis
	Rely on recurring user data entry	Sleep times, times of eating occasions, meal and snack sizes eaten	There are no passive entry approaches at this point in time
	Balance need for more research data against loss of engagement	Use categories of food size rather than specific foods and their calorie count	A simplified interface means that we gain from more daily interactions, but do lose some details
	Minimize labeling bias in data entry and minimize feedback	App does not communicate judgment	Avoid feeding back data (eg, summary graphs); avoid guiding users towards a particular change in behavior
	Maximize use over multiple days, minimize use within a day	Focus on data entry; simple interface	Target time frame was at least several weeks of daily input over 6 months
	Maximize user engagement	Gamify to encourage fun interactions with the app and to reward those that track leaderboards, virtual trophies, “Power28,” “PowerWeek”	A specific challenge for a data collection app that does not offer any direct benefits (as research is not supposed to)
	Maximize pool of potential research participants	Develop both for iOS and for Android; national + recruited	Used React Native to maximize developer time; trade off on national, beta-testing, commercial licensing, one-to-one distribution; national reviews might have decreased participation; loss of inter-app interoperability
	Maintain privacy	Nonidentifiable usernames selected using random word-pairing generator	Avoids concern about users creating identifiable usernames
	Manage expectations in comparison with commercial Apps (fitness trackers)	Address limited functionality up front during signup	None
	Balance research-data feedback among research needs, user expectations, and research ethics	N/Aa	Users of commercial apps expect feedback; research argues against feedback; ethics argues in favor of research
	Involve target users in design	Stakeholder advisory board and user testing, iteration over options and discussions on what to take out and to leave in	None
	Support multiple types of users	“Super users” that want to enter multiple times each day vs “once-a-day” interaction for a short window of time	None
Back end
	Minimize high-touch engagement costs	Real-time dashboards (updated hourly) and SMS and email messages	None
	Minimize development cost	Re-used our initial backend for Metabolic Compass and added dashboards	As an academic use case, revenue generation is not expected, and therefore development costs are not recovered
	Support the research process: Recruitment, Execution, Data Analysis	N/A	(Differs from commercial)
	Protect participant privacy	Designed in strongly from the beginning: used a UUIDb to link study data with messaging and created random usernames	HIPAAc and IRBd are major drivers of this desideratum
	Support multi-institutional recruitment and data collection	Designed in strongly from the beginning	We collected REDCap survey data and recruited from multiple institutions
	Continuous debugging and improvement of user experience	Used InstaBug to collect user feedback as well as technical issues	None

^aN/A: not applicable.

^bUUID: universally unique identifier.

^cHIPAA: Health Insurance Portability and Accountability Act.

^dIRB: institutional review board.