Elyse Cornwall Final Reflection

Before this class, I thought…

Before taking CS247B, my only experience with HCI was in CS147. That course left me wondering whether all design classes would look more or less the same in terms of deliverables and timeline. I was also curious whether what I’d just learned was “real”; would any of this be relevant in the workforce for those who would end up as PMs or UX designers? I wasn’t planning on doing either of these things, so much of what I learned in CS147 didn’t feel relevant to me outside of class. For me, CS247B was the next step in continuing my coterm degree, and I didn’t think much about the behavior change theme until the class began.

I did this work:

Something I loved about this class was making sketchnotes. Sketchnoting was one of the first things we discussed, and I’m glad to have learned this skill both as a student who takes lots of notes, and as someone who doesn’t consider myself very creative. I’ve been doing sketchnotes for my other classes and it’s helped me process my readings without writing a ton. It’s also been a confidence boost, because drawing is something that I find relaxing and enjoyable and sometimes I’m even proud of what I draw! I thought Deb Aoki’s guest lecture was fun, but I also had a hard time balancing the personal style I had been developing with the drawing conventions she introduced to us.

My notebook 🙂 

I thought that having our final deliverable be a clickable prototype really worked – we got to spend more time thinking about our user’s experience on the app rather than trying to decipher frontend code. I think that CS147 had encouraged students to split up work by coding and design tasks, which meant that students could have completely different experiences in the class. I thought CS247B did a good job of making all aspects of the course accessible to students regardless of academic background, by providing readings and examples whenever we embarked on an unfamiliar task. It also helped that the TAs gave constructive feedback on each assignment. Ending with a clickable prototype meant that every teammate got to contribute to the final product, and stayed on the same page about what others were up to.

I found system paths and bubble maps to be great tools for turning our ideas into actual features and screens. Sometimes, I’m tempted to focus on the details of an interface before thinking about the user’s experience in the app. These exercises showed me how to start with the bare minimum functionality, and use this to drive the development of an interface.

When working on a team, I sometimes have trouble trusting the work of others without double-checking it myself. I often find it stressful to have someone else’s work affect my grade, but I think this courses’ transparent and often completion-based grading took the pressure off. I stopped checking up on my teammates’ progress and quickly realized that I could trust them to get stuff done, or let the group know when they couldn’t. Our team did well on assignments, stayed active over text, and actually got to know each other better.

Yay teamwork

I wish that the theory we talked about in readings was paired more closely to the work we completed. We talked about all of these behavior change techniques and interesting research, but we didn’t necessarily have to apply this to our projects. For example, after our gamification reading, I would hear teams talking about gamifying components of their apps. We would have ethics discussions on a topic, but at least according to the grading rubric, there was no need to incorporate these findings into our project. I wish that we were more explicitly asked to apply the learnings about behavior change and ethics to our projects.

Ethical considerations

Our group considered using notifications to nudge our users to submit a reflection each day, but according to the readings and some study feedback, this wouldn’t work well for our project. Since our app was about reflecting positively on past decisions to minimize regret, it didn’t make sense to remind them daily, when they might not have a decision to reflect on at that time. We chose not to push notifications to our users in this way because we didn’t want to be annoying or unhelpful just for the sake of getting people to open the app. 

Push notifs

Our app has users make accounts, and add other users by phone number, so we needed to make sure that we had a good plan for privacy on our app. Although we didn’t actually have to implement a back-end, we knew it would be important that we a) collected the least amount of data necessary to give the needed functionality and b) stored this data securely and only retained it for as long as necessary. An important consideration when designing the prototype was transparency; we wanted our privacy settings to be easy to find and understand, and this was something we investigated in usability testing. When we discussed adding a social feature to our app, I felt torn because this would change our app from something that could keep data locally on the person’s phone to a social media app. I worried that we were making the app social just for the sake of having profiles and friends, without thinking about the ethical complexities that arise in social apps. We would need to consider how to prevent harassment on the app, and investigate how validation and competition would impact users’ reflections. I still feel as though the social part of our app isn’t crucial in order to deliver the key functionality, so I’m not sure it was the best choice from an ethical standpoint.

My team thought carefully about inclusive design when deciding how to allow users to input their reflections. We were excited about multimedia input, which would allow users to express themselves with more than text. We recognized that in some ways, we were introducing visual accessibility issues if photos and videos weren’t well captioned and couldn’t be interpreted by a screen reader. On the other hand, these types of inputs might be more accessible for low-literacy users. We realized that we couldn’t be perfectly inclusive of everyone, but we must be aware of how our choice to have multimedia input would exclude some users while including others.

Now, I think this:

Now I think that it is possible to learn “real” design skills even while completing a project that only exists within the scope of a class. I thought it was cool how Christina weaved examples from industry into class, even though I’m not planning to take that route after I graduate. I also liked how we tried out different diagrams and tools, acknowledging that all of these were just techniques that someone had come up with, and that we could take or leave these strategies as we pleased. I feel more optimistic knowing that even as students we have the ability and responsibility to think critically about the design process and the power we have to shape human behavior.

Next time, when faced with a similar situation I will…

Next time I work on a team, I will assume best intent and trust my teammates to share work fairly from the outset. I also want to be intentional with the feedback I give, and candidly share my thoughts so that my team can stay on the same page. In future HCI classes, when presented with a design task like “conduct X interviews” or “make this diagram” I will critically consider the benefits and drawbacks to the activity, and ask for more context if I don’t get why we’re doing it. 

Team 3!