I liked this section because it shows how you can tell the same story in different ways just by deciding where to add tension. I think the And-But-Therefore structure is actually pretty useful since it makes you think more about what parts of the story you want people to focus on. It also made me realize that storytelling isn’t just about what happened, but how you choose to frame it.

I totally agree. This part really stood out to me too. I’ve read this story before, but it still makes me think about how something as simple as a “male or female” button can show the limits built into technology. It’s crazy how designs like that assume everyone fits into just two options, when that’s not the case at all. It really opened my eyes to how bias can exist in everyday things like airport scanners.

I totally agree with this quote. I like that cognitive walkthroughs focus on what people are actually thinking as they move through an interface, instead of just how the interface looks. It shows that even older methods can still be super relevant, since understanding the user’s mindset never really goes out of style.

Yeah, I totally agree with this quote as usability tests are awesome for catching stuff like confusing buttons, weird layouts, or a clunky flow. But they don’t really show if the design actually fits into someone’s real life or if it’s genuinely useful. It made me realize that even if something tests well in a lab, it might still fail to be meaningful in the real world. I think it’s a good reminder that good design is about more than just making things easy to use and it’s about making them worth using.

I think the idea of the gulf of evaluation makes a lot of sense, especially when you think about how confusing some interfaces can be. I like how the example of the alarm switch shows how simple feedback, like a click or a visual change, can make a huge difference in understanding what’s happening. It made me realize how much we rely on small cues like that to feel confident that something actually worked.

I really agree with the idea that prototyping isn’t just about making something, it is about figuring out what’s worth making and why. I think that perspective is super useful because it reminds me that not every idea needs a polished version right away and sometimes a quick, rough prototype can teach you more. It also made me realize how much context matters like how your time, resources, or even your team’s comfort with risk can totally change what kind of prototype makes sense.

I didn't really think about the functionality of things like sign-up or login functionality when doing a competitive analysis before, but this reading made me realize how important that actually is. I used to focus more on the main features, not the smaller things that affect how users interact with a product. Now I see that those parts can really impact how smooth or frustrating someone's experience is. It definitely changed how I think about what makes a product stand out.

Yeah I totally agree with the fact that the way you word a question really changes the kind of answers you get. For example, a bad question would be something like "why is instagram not a good app?" because this is forcing the user to feel some type of way. In my project, I noticed that when I asked open-ended questions like "How do you feel during your week at school?" people give a lot more interesting and detailed answers. I also actually understand how they feel without forcing them to feel some way

I totally agree that critiques should be a two-way conversation rather than just one person pointing out flaws. It makes a lot more sense when both the designer and the critic are actively explaining their reasoning because it feels more collaborative that way. I also like the idea that critiques are only as good as the person giving them as it reminds me how important it is to get feedback from people who actually understand the problem you’re solving.

I really like this section and think the idea of externalizing your ideas is super useful. I've noticed that when I sketch something out or explain it to someone else, I can spot the flaws way more easily than if I just keep it in my head. The Leonardo da Vinci example makes a lot of sense too as it shows even really smart people need a way to organize their thoughts. It's making me realize I should probably write down or sketch my ideas more often instead of trying to remember everything.

I agree with this because it is true that there really isn't such a thing as an "average user" and everyone's needs are so different. But it makes me wonder: if every solution is going to leave some people out, how are we supposed to actually solve issues? I guess it is more about finding a balance and deciding who/what you're prioritizing rather than trying to make something perfect for every single person.

I agree that arguments are important because they help show the causes and effects of a problem, which makes it easier to persuade others that the issue is real and needs to be solved. I've noticed that without this kind of framing, people often overlook why something matters in the first place. Being able to lay out that causality feels extremely important to getting others on board with a design problem.

I really agree with participatory design because it's so much more effective than just assuming what people's problems are. Actually involving stakeholders in the process makes sure their needs are truly represented instead of just guessing. It feels like the best way to design solutions that will actually help the people using them, but I also understand that not everyone's issues with always be fully met and I wonder if we can come up with a technique some day that solves this problem.

Wow I love this, this is so true and I agree with it completely. I can definitely relate to this because I interned at Microsoft this summer working on mkaing Github Copilot better for our codebase using things like MCP servers and Copilot instructions, and I always expected the AI to improve after adding more, but it just wouldn't. Instead of taking it as a failure, it became a learning experience for my team about AI and its unpredictability/lack of consistency.

I agree with this statement overall, but from my experience as a software engineering intern for the past three summers, there's definitely a lot more design work than what is listed. I was the one who designed all the platforms I later built, including the websites, appllications, APIs, and much more. I also had to design testing frameworks/platforms, and design for security and scalability. This reading resonated with me because it reminded me why I wanted to go into Informatics in the first place as someone who is interested in Computer Science: to really really understand the design aspect of SWE, since there is actually so much that goes into it beyond coding.