Before taking CS 247B, I thought it would be very difficult to come up with a design idea with a team of strangers. I took CS 147 last year, and it was extremely fast-paced and time-intensive. I was grateful for having a pre-formed 147 team with trusted friends that I enjoyed working with. While we had some disagreements, we generally had the same values, interests, and work styles which made brainstorming ideas, scheduling interviews, and completing deliverables very easy. My friends and I expected to form a team for 247, but the teaching team split us into different groups. I was initially nervous that the new team dynamic wouldn’t work, but I appreciated meeting my teammates and making a cool product with them!
Throughout the quarter, I was grateful that our final deliverable was a Figma prototype rather than a coded application. 10 weeks is a very short time to navigate the iterative design process, and I liked having several weeks to ideate with my team, test our assumptions, and go back to the drawing board. I also found the in-person teammate feedback sessions to be very useful. Since we’re on a quarter system at Stanford, I often feel like brushing unhealthy team dynamics under the rug. I rationalize my fear of confrontation by telling myself that in a few weeks, the project will be over anyways. However, these feedback sessions improved the team dynamic by compelling everyone to not only share their concerns but also come up with tangible solutions.
For example, our team realized we had work style issues regarding time management. Some teammates preferred to complete the assignments ahead of time while others submitted late at night and sometimes used the 24-hour grace period. This led to some frustration since the teammate who usually finished earliest took on more deliverables out of concern that the other team members would forget to complete their assignments on time. This dynamic was unsustainable for the team of course because one member would do more work before the other members got a chance to make significant progress. And, when the other team members wanted to give feedback and make changes, the earlier member felt as if they were receiving last-minute critiques that should have been addressed earlier.
Our solution was to let the team know ahead of time when we expect to finish our work (early, during the grace period, etc), and create a feedback system where one person reviews another person’s work before the team-wide review. That way, nobody feels as if a busy teammate is blowing off an assignment, and everyone has an opportunity to provide sufficient feedback.
Going forward, it would also be good for more class time to be dedicated to brainstorming. Sometimes in the group, it felt as though only a few people had time to share their ideas and other people’s opinions didn’t get as much air time. Scheduling a time outside class for 5 people to regularly meet is difficult, and it would be great to have more in-class time to hash out the details of our design and give one another feedback.
Concerning our design process, there were many ethical aspects to consider. At the beginning of the quarter, we discussed nudging and manipulation. Our app certainly takes advantage of the “friction” strategy where we discourage users from carrying out certain tasks by making them tedious to do. For context, the Apple screen time limit, a competitor of ours, has barely any friction when users want to ignore their screen time limit. Users can easily keep clicking buttons like “15 more minutes” or “ignore time limit for today” without being held accountable. On the other hand, when users try to delete a screen time limit from our app, several features discourage them from doing so. A modal pops up telling them to take a deep breath, then it asks users to verify their choice by clicking the purposely-highlighted button “No, I want to keep progressing!” or the non-highlighted button “Yes”. We designed the modal to highlight the “no” button hoping that users rushing through the deletion process would accidentally click it thinking it was the “yes” button. If users click “yes” the last bit of friction is asking them to type in the textbox verbatim “I don’t want to reduce my screen time anymore.” We hope that this message reminds users why they initially decided to lower their screen time.
These nudges toward keeping an intervention are acceptable because our users are dedicated to reducing their screen time. We are helping them achieve a goal that they presumably want to achieve, otherwise, they wouldn’t have downloaded our app. Also, the steps toward deleting an intervention are still short, so we don’t completely block a user from completing that task. Perhaps these mechanisms could become manipulative for people that have trouble reading small text. Referring back to the design of the “No, I want to keep making progress” and “yes” buttons, users who struggle to read the exact text would probably click the “no” button when meaning to click the “yes.” This could be manipulative since it would make the intervention deletion process systemically difficult for an underrepresented group of people.
One way my thinking has evolved during this class is related to accessibility. It took us a while to realize that our product could be inaccessible to certain communities. Our initial idea was to slowly distort people’s screens by turning them to grayscale or making them blurry. These are great ideas for getting people to get off their smartphones, but they also may be too intense (or not intense enough) for people that are visually impaired. People that are colorblind, for example, may not have a less-addictive scrolling experience when their screen switches to grayscale. To address these accessibility issues, we decided to include another distortion: audio. Perhaps if someone is scrolling through TikTok and the audio slowly becomes higher-pitched or fuzzier, they might get annoyed enough to log off. This way, many of the users who may not prefer visual distortion can still use our app.
Still, we are making a lot of assumptions about visually-impaired users and what they’ll find useful. Due to the time constraints of the quarter, we were unable to find visually-impaired participants for our studies. Next time, when faced with a similar situation of navigating accessibility, I’d make sure to think about these issues early and reach out to people with different abilities to hear more about their experiences.
