Meerkat: Intervention Study Synthesis

Assumption Map & Tests

Most critical assumptions:

1. “Habit stacking can be effectively implemented”
2. “Users usually read to accomplish something rather than doing it for pleasure”
3. “Users often feel too tired at the end of the day to enjoy reading”

Assumption Tests:

1. Habit Stacking: We asked participants to stack 5 minutes of reading on top of going to the bathroom. We measured the success rate of the stacked reading (if people actually read after going to the bathroom).
2. Reason for Reading: We gave users two options: a short, entertaining story, or a short informative article about current events. We measured how often users picked one option or the other, and why they did so.
3. Reading Satisfaction: We asked users to read for 5-10 mins at the start and end of their day, and measured their reading satisfaction levels through a qualitative survey after each morning and night session.

Results:

1. Habit Stacking: We found that on average, the users recorded reading while going to the bathroom about 64% of the time, which almost reached our “we are right if” goal of 70%. One key takeaway from the experiment was that habit stacking needs to give the user the opportunity to meaningfully engage with the target habit. In the case of going to the bathroom, users were sometimes only able to read for a minute or two, which isn’t always ideal. While the bathroom habit stacking seemed to be effective in getting users to read, it may be more realistic to read while going to the bathroom only if they’re going to be in there for more than a minute or two. Most importantly, this test showed that people were willing to read while going to the bathroom, so this is a promising result.
2. Reason for Reading: We found that 3/4 of the users picked the informative article. That represented 75% choosing that category, which is quite significant. The takeaways from this are that college students (and young professionals) largely prioritize gaining knowledge when they read, and it was interesting to see that the one student that chose the short story was someone who already likes to read in her free time. 
3. Reading Satisfaction: What we found was that all three of the users reported a higher satisfaction after taking the morning survey vs. after taking the night survey. We learned that users definitely don’t want to read as much when they are tired, and even though they are satisfied after reading, it’s much more difficult to get motivated to read if they are tired in the first place.

 

Intervention Study

Our intervention study blog post is linked here.

Our intervention study responses is linked here.

Overview:

Our intervention study consisted of a google survey which we sent to each participant for four consecutive days. We had participants record whether they read that day or whether they faced a “read obstruction,” which we defined as an obstacle that prevented the participant from reading that day. If a participant recorded a reading session that day, we also had them record information about the time of day in which they read, the location where they read, their medium of choice, their motivation for reading, and whether or not they had a desire to use a social media app after reading. We also asked participants to simulate our “app switcher” in that, during the 4 days of our study period, we reminded participants that if they opened a social media app, they had to immediately switch out of the app and instead read for 10 minutes. In our google survey, we recorded whether the motivation to read was intrinsic or extrinsic (via our simulated app switcher).

If a participant didn’t read that day (i.e. they faced a “reading obstruction”), we asked them why they were motivated to read in the first place and what prevented them from doing so. We also asked them whether social media influenced their decision not to read (i.e. were they tempted to open Instagram instead).

 

Findings:

Overall, during the four day study period, most participants logged reading sessions rather than reading obstructions. This seems to follow from the fact that they were more likely to read during those 4 days since they were asked to do a reading intervention study, and thus, it was a more conscious decision than perhaps any other four day period. 

We found that most participants recorded reading for enjoyment (i.e. non class related reading) in the morning in a comfy atmosphere such as their bed or couch. The second most popular time of day to do so was in the evening after dinner. Of our 4 participants, two recorded that they were motivated to read instead of use social media because of our app switcher simulation intervention. One participant even described that this was his motivation to read on two separate occasions because he found himself opening instagram, which reminded him that he should be reading instead. The biggest motivation to read was in order to complete required class readings. Because of this, these participants did not record another reading session for pleasure. 

After each reading session, about half the responses indicated that the participant had a desire to use social media after finishing their reading session. Half the participants chose digital mediums whereas the other half chose physical ones. This trend mostly aligned with the motivations for reading. Those who were reading for pleasure typically read a physical book whereas those who were reading for class read digital material.

The biggest cause for a reading obstruction was getting “sucked” into one’s phone, whether it was checking their phone first thing in the morning or getting lost in the TikTok algorithm. The second biggest cause was either too much homework or being tired after doing schoolwork all day, which generally aligns with what we found in our baseline interviews.

 

Implications:

The findings of the intervention study seem to support our App Switching product. Because most people report obstructions due to getting distracted on their phones, this seems like the perfect place to intervene. Of course, the simulated app switcher relies on participants remembering that they should be reading when they open a social media app, which is far less intrusive than our App Switcher would be. Therefore, we expect that our app would be much more effective at pulling people out of their normal scrolling habits because it will be designed to be somewhat intrusive (likely with customizability options for users).

Our intervention study also reinforced the idea that a digital product could be a successful intervention medium because each participant, at some point in the study, recorded reading on a device, whether it be a news source or a downloaded essay. This inspired us to include a feature in our app whereby, when the app switching intervention pops up, a user can navigate to a digital reading platform of their choice (i.e. The New Yorker app, NYT app, etc…) or opt for a physical medium. This feature would be customizable to the user. Our intervention study proved to us that users willingly read on digital mediums, and so there would be very little friction in switching from a social media app to one that prioritizes reading. 

Additionally, we will likely be adding a feature in which the app learns, either through user input or some ML algorithm, what time of day a user prefers to read so that the app switching functionality can be deployed at an optimal time of day in which the user is more likely to want to read.

 

System Paths

System path diagram process: 

1. Understanding the persona: My team and I had two primary personas – the top right being Find Better Book Brooke (FBBB), who struggles with being distracted during her reading sessions, and Data Driven Dave (DDD) in the top left, who is distinguishable with his desire to read to gain knowledge for his data science research as part of his graduate studies. When planning our initial system paths, we wanted to first think about our two persona’s differentiating experiences and draw paths for one persona at a time (this was our initial approach, but I will explain our reflection on this approach in the next segment). 
2. Creating the system paths: For FBBB, we had her first interaction with the system be through a notification of some sorts, which was probably sent due to her prolonged usage of certain social media apps like Tiktok that prompted the system to remind FBBB to read (remember, she is the persona who struggles with distractions like social media). We made the assumption that she would be goal setting as the next step, in which she identifies her ideal time spent reading per day, when she would want to read as part of her routine, and how committed she would be to her reading goal. She would then start reading (in which the system starts a timer) and if she were to leave the app, she would be unable to open any social media apps as it would switch her back to the system (so, she would be leaving the system’s “circle” during this time, but we did not draw that on the actual system path above). Once the timer ends, she would be free to use any app she would like. When we started drawing the system path for our second persona, DDD, we realized that he had many converging touch points that aligned with FBBB’s paths, from goal setting to the reading timer starting and app switching process. His entry into the system, however, would be a notification on his phone screen (maybe, a widget) that would bring him into the system. 
3. Iterating through the system path (AKA the addition of sticky notes): Since we had spent the first part of the diagram creation on parts where our persona’s paths aligned, we decided to think about points where they diverged a bit more. This meant that we would expand on our system paths by including exceptions or specific use cases to each of our personas as an extension of converging points (with sticky notes). For example, although goal setting was a point of convergence for our two personas, areas where they would differ or need exceptions include wanting to possibly edit their goals after they’ve already set them. Or, for a user that FBBB who may not sure of what type of reading goal to set or the amount, perhaps she’d benefit from preset goals that align to her specific needs, which the system can provide. The same logic of treating exceptions applies to the app switching process, in which different users may want stricter or looser app switches. For example, if a user were to want “lose” restrictions, they would be able to more easily bypass the app switch, whereas users that want harsher restrictions may have to complete a puzzle to bypass the switch. 

Key insights from system path diagram: 

1. The importance of where our user may enter the system: Our personas differed the most in how they entered the system or were prompted to open our app and start reading. For FBBB, she struggles with social media as a distraction to her reading, and so giving her a nudge when she uses distracting apps would be more applicable to her existing habits. For DDD, he would most likely enter the system through notifications that happen during specific times of the day when he may be studying or have free time after class. As we design our final product, we will think about how we can personalize or cater our notifications to make our nudges more effective. 
2. The importance of where our system may converge or diverge: Where a user enters the system may differ, but where they converge are points that we need to cater towards for our core features. For example, we have identified in our diagram that goal setting, onboarding, and the start to end of the reading timer and potential app switching process will be crucial. As we see lines overlap and sticky notes added, our main takeaway is that these key points of interaction are significant to differing persona’s paths, in which we are designing not just for one persona but for all. When we design our app, we need to think about possible edge cases or points of personalization/universalization that these touch points may bring. Let’s say we make preset goals or reading times that map to certain reading habits (ie. college students may want 30 minutes reading sessions a day in the morning). We’ll want to have goals like this that are comprehensive enough to match our key personas while ensuring that our users will still converge and follow a similar path after they have chosen their goal. This is important because, although not explicitly mentioned before, our MVP should be a system path diagram with only the most efficient or essential paths that serve the purpose we want it to serve for our users. 

 

Story Maps

Story map process: 

1. Activities: Our high-level activities for our persona DDD included login, registration, Defining reading goals, and the actual app switch process. These activities were derived from our system path diagram as key touch points that were shared across all our personas, as mentioned above. 
2. Steps and details: When it comes to the steps our users go through for the above activities, the login and registration steps are quite similar to existing platforms. For example, login and registration would require the user’s email/username, password, and other more personalized features like notification settings. Our larger activities, though, center around different factors that users may want to personalize or cater towards their own goals. Goal setting would need the user to discuss their goals (ie. to read more in general or gain knowledge and retain their readings), their preferred time of reading when integrated into their personal routines, their desired reading session lengths, and how harsh or loose they may want the app switches or restrictions to be. The actual app switch would be based off of these goals, which may require the user to add extra steps or more granular details. For example, a user would need to input the apps they’d want our system to access and block out if they’re outside of the suggested blocked apps list. If the user indicated that they had strict reading goals and wanted harsher app restrictions, they would receive a puzzle of some sorts that matches the inputted difficulty. 
3. MVP/solutions: Below the line are potential solutions to pain points the users could encounter at each step. One of the biggest problems we identified was how we could get the user to commit to the app and realistically read as a result of it. So, our goal was personalization in order to combat the problem, since we identified from our prior research that catering to a user’s existing habits, schedules, and goals in a realistic manner would make our app be most effective while holding our users accountable. Our solution, then, was an app that could cater towards a user’s ideal reading goals and switch them from a set of chosen distractor apps based on the commitment the user outlined during onboarding and registration. A user that expresses more dire commitments and prefers harsher restrictions would have to complete a puzzle of high difficulty to go back to the distractor app, while a user with lower commitment to the app and prefers looser restrictions would only have to complete an easy puzzle. 

 

Key insights from story map: 

• Points for personalization for our MVP: Our story map had highlighted several areas where we could add touches of personalization to each user activity that would make it more realistic and inviting for the user to follow. For example, the difficulty of the puzzles mapping to the commitment level the user indicated in their goals/onboarding process. We also thought about how we could expand or touch on certain inputs that we asked the user during goal setting. For example, one of our questions could be for the user to input their preferred reading material, such as podcasts, books, or more. If we were to track the amount of time the user spends reading per reading material, that could be content for a “reading wrapped” at the end of each quarter. We could apply this logic to notifications as well, and we will think about how we can make notifications appear when the user is following their existing routine to make the app more effective – personalization is key to adoption. 
• Reduce friction points: We realized that our goal for the story map is to ensure we have the least amount of restrictions or steps for each user during the activities, since having too many requirements may sway the user away from the app. One way we can mitigate concerns of too much friction is by giving users more control over them, such as by indicating their initial commitment. 
• Gradual commitment and tracking towards retention: When we created our story map, one of our biggest concerns was how we would hold our user accountable or ensure that they are actually reading when the timer is on. Or, if they would commit to the app daily or a couple times a week without the potential for churn after a couple uses. From this, we realized that gamification elements may be useful for the MVP. We may want to focus on time/progress tracking features or add streaks and achievements to ensure that the user has a goal they are working on for the app as well. 

 

MVP Features: BookBounce

Our Wire Flows and Sketchy Screens

Our Mood Boards and Style Tiles

Screens/Visuals:

• login/sign up: 
  • The sign up includes an onboarding process that asks basic questions about their reading goals and what they like to read. Further customizable things like time limits they want on various other apps will be done in settings
  • After signed up, they will need to log in using their email/password
• Profile/Settings: 
  • All settings designed to give them a customizable experience that will help them become a consistent reader
    • How long they want to read 
    • Time of the day they want to read 
    • Type of book they want to read
    • Notifications on/off
  • Change password
  • Establish friction settings for switching back to the app they were using (explained further below)
• Notifications: 
  • Sent to the user to indicate when goals are or are not being met 
  • Why notifications? To encourage the reader to read! 
• Once inside, the home page: 
  • Progress tracking: 
    • Streaks to show how many days in a row 
    • Some sort of graphic to visualize progress in the app 
      • Likely a graph to show how much they’ve read over time, either in terms of time or number of words read
    • Shows them how many times they’ve read that week, and potentially how much. Ex: “you read 15 articles this week”
  • Spotify wrapped idea – show the user the types of reading they’ve preferred

 

App Switch Functionality:

• When a user is on another app for too long, BookBounce will automatically switch the user over to our app: 
  • Let’s say the user is on Instagram. When the IG timer is up, it automatically switches to our app, specifically a screen that has all of the user’s preferred reading methods. There’s an icon for each one, and the user is able to tap on any of them, and it will redirect them to that app. Ex: if they want to read the WSJ, they would click on that icon on the screen and it would redirect them to that app
• When a user tries to go back to the app they were using before the switch, the following happens: 
  • BookBounce will again bring the user back to our app, and based on the settings the user sets, the following will happen:
  • In settings, the user can indicate easy, medium, or hard in terms of how difficult they want it to be to return to the app they were using before the switch 
    • Easy: just a simple password 
    • Medium: answer several math problems (this is medium for now)
    • Hard: Multiple security questions they have to answer, like what street did you grow up on? (just to make it extra annoying)

 

Bubble Map

Our individual Bubble Map diagrams are available here.

This is the synthesized Bubble Map diagram:

To synthesize our in-class bubble maps diagrams, we tried to find the common themes present in all our diagrams, which ended up being the “app switcher” functionality, and the “home” page. Since those are two distinct ways the user interacts with the app, we took those as the 2 main building blocks of our synthesized bubble diagram. The key insight from this step, which echoed insights from our previous steps, was that our app has 2 distinct pathways for user interaction, and thus has 2 different entry points that result in different goals and outcomes.

From there, we added on the sub-bubble of “goals” and “registration/log in” to the “home” page. These are 2 pathways that we saw in our individual bubble map diagrams in different levels of separation from the home page, so we synthesized those as pouring into or out of the “home” bubble. This led us to the insight of how to best manage the production of these pathways and let us visually see how future work can be easily split up and where the key connection points are.

For our “app switcher” side, our individual bubble maps showed that there is a cyclical nature to that function, which we reflected in the synthesis. This is also where the connection to other apps happens, cycling between the vice of choice (TikTok, Instagram, Candy Crush, etc.) and the reading material previously customized by the user.

Our bubble map diagram utilizes color to denote categories and subcategories of bubbles, and size that denotes the amount of time the user spends in each bubble/screen. As such, our hope is that the “app switcher” contains the most time spent. After looking over our feedback from previous assignments and our in-class discussions with the teaching team, we also explicitly added the “emergency exit” sub-bubble to the “app switcher”. We hope that this accounts for very little use, hence the bubble size, but it is a necessary feature for the user’s conservation of agency.

To reiterate, our key insights from this step are:

• There are 2 distinct pathways of interaction in our app.
• The bubble map diagram is a good way to see how information flows and is connected, and thus can be used to divide the later prototyping most efficiently.
• The app switcher functionality is cyclical first and foremost.
• We need to integrate an explicit emergency exit into our design, accounting for real emergencies, while also not being overly easy to bypass.

 

Our links:

Our Intervention Study Overview

Our Intervention Study Responses

Our Wire Flows and Sketchy Screens

Our Mood Boards and Style Tiles