CS 247B was a great experience. I enjoyed working with my team, and we ended up with a very cool project. Prior to the class, I had done a bit of work on related topics, specifically on using games to motivate behavior change in players (similar to what is taught in 377g), but it was very helpful to formalize these behavior change concepts in the classroom.
The format of CS247B was not my favorite. I am a bit disillusioned with Stanford’s approach to HCI, particularly in the way that 147 and 247 are taught. I know that there are many different 247’s, but from what I understand, they all incorporate needfinding, go through multiple steps of iteration, and culminate in some kind of high-fidelity prototype. While this workflow teaches many important concepts and gives students the chance to practice the design process, I think it cements the idea into students that every problem can be solved with an iPhone app. We mentioned very briefly on the last day of class that there should be a “Go/No-Go” check early on in the design process, and I feel that this workflow doesn’t emphasize that enough; rather, it communicates to students that with enough needfinding and journey mapping, any app can be useful, which I don’t know to be true. I suspect that this ideology is why Silicon Valley is flooded with apps that are 1) copies of each other and/or 2) end up converging on the same features.
All that said, the class itself was still fun. I worked very well with my teammates, and our project does seem useful. We created a social media limiting app, which is a very popular behavior change concept, so we worked hard to steer it very far away from our competitors. The concept of forcing the user to change locations in order to keep scrolling poses some friction in terms of adoption, but is substantially different enough from the state of the industry that we hope the novelty and effectiveness will override the friction.
In terms of ethical considerations, we employ nudges and manipulation through our reminder notifications. Rather than simply telling our users that they are nearing their screen time limit, we also remind them of goals that they set during the onboarding process to provide them with alternatives to scrolling. We use some social pressure as well with our leaderboard features. We hope the social pressure nudges the user to compete with their friends to keep screen time low. This is an acceptable nudge because we don’t require the user to add friends and compete, thus they have complete control and can revoke consent from this nudge at any time. In terms of privacy, we understand that our app has a lot to consider; with a user’s location and scrolling activity, one could construct a vivid image of who a user is and what they do. This is very sensitive data. Thus, to keep data safe, we would hash all demographic and personal information associated with a user and keep the hash function local on the user’s device. Thus, even with a data breach on the software end, none of the leaked information would trace back to a single person. There are additional steps that could be taken as well, such as manipulating/hashing the location data as well for further safety.
After this class, I understand more about the design process. While I mention my frustrations with it earlier in this reflection, I can begrudgingly admit that the practice is definitely helpful and informative. I just hope students don’t get stuck in one methodology! Anyways, I’d like to thank all of my classmates for the discussions and conversations we’ve had in class. I’d also like to thank my group members for helping to create a really cool product. I’d like to thank the TA’s for guiding us through the process, and lastly, I’d like to thank Professor Wodtke (and Nina!) for teaching such a great class!
