What I really like about this graph is how it shows that tension rises across the three-act structure—the idea that tension doesn’t appear right away, but is “introduced at the end of the first act,” then keeps climbing until it peaks in Act II. I agree with this way of mapping stories because it makes the relationship between time and emotional intensity really clear; seeing it graphed like this helped me understand why the middle of a story always feels the most chaotic and full of movement. It also made me realize that the release of tension in Act III isn’t just a wrap-up, but an intentional structural payoff that depends entirely on how well the earlier acts were built.

I really resonated with the author’s point that “artifacts have politics,” as we directly discussed this quote in my digital law and policy class at UW. I feel like this is a strong quote that isn’t just theoretical, it describe how design choices in technology quietly shape agency, accountability, and justice in everyday life. In the digital law course, we examined how we talked about acting through technology rather than with it: when we act through technology, we interact within systems where values and affordances are invisible, guiding our behavior without us realizing it. The TSA scanner’s binary gender interface is a clear example of this, its pink and blue buttons encode cis-normative assumptions that determine how people are treated. Just like predictive policing algorithms that reinforce racial bias, these systems redistribute power by embedding social norms and inequalities into technical infrastructure.

I really agree with the reading’s point that there’s nothing like watching a real person struggle to use your design. I’ve experienced this in group projects where our design seemed perfect on paper, but once we saw users getting confused or stuck, we realized how many assumptions we had made. It’s such a valuable reminder that analytical evaluations and heuristics can only go so far—real user interaction reveals issues we’d never anticipate ourselves. This reinforces why usability testing with actual users is irreplaceable for meaningful feedback and improvement.

I found the discussion of recognition versus recall really interesting because it highlights how design can either support or burden users’ memory. I notice this difference a lot when comparing apps that use clear icons and menus versus those that rely on hidden commands. For example, some mobile apps require you to remember specific swipe actions, which can be frustrating when they’re not visible on the screen. This reading reminded me how much easier it is for users when designs rely on recognition—showing options directly—rather than expecting people to recall invisible steps from memory.

I completely agree with the reading’s point that the goal of usability tests is to uncover “breakdowns” — moments when users fail to complete a task even though they’re following the right steps. I’ve noticed this myself when building projects: everything seems fine until people outside the team start using it. That’s when I realize there are small, even silly mistakes that I never noticed because I was too familiar with the design. Just like the reading explains, observing these breakdowns helps me understand where users get stuck and how I can redesign the interface to make it clearer and more intuitive.

I really agree with the idea in this passage about affordances — it makes so much sense when thinking about how we interact with interfaces every day. The point that affordances are not just about what something can do, but whether the user recognizes what can be done, feels super relevant. It’s one thing for a button to be clickable, but it’s another for users to know it’s clickable. I also like how the passage connects affordances to signifiers, like visual or sensory cues that guide users. It reminds me of how modern apps use animations, color changes, or shadows to make buttons feel “touchable.” It’s a small detail, but it really changes how intuitive something feels.

I used to think prototyping was something you had to do in every design process, but this made me realize it’s more about thinking strategically than just building for the sake of it. The idea that prototyping helps you decide what to learn instead of just testing something random really stood out to me. I also find it super useful that it points out how sometimes it’s better to just go ahead and build the final version if it saves time or effort. Not every project needs multiple rounds of prototypes — it really depends on your goals, skills, and the level of uncertainty. Overall, I think this perspective helps designers (especially students like us) use their time more wisely and make smarter decisions about when and why to prototype.

I agree with this conclusion and find it highly practical, especially given how saturated the modern market is. In most industries today, there are already countless products and services competing for users’ attention, so understanding what others are doing is essential before proposing something new. Conducting a competitive analysis helps designers identify what works, what doesn’t, and where the gaps or pain points exist that could make users choose your design over existing ones. I also think this approach is efficient because learning from similar products is a low-stakes but high-value way to begin the design process. It allows you to avoid repeating mistakes that competitors have already made while also inspiring better, differentiated solutions.

I partially agree with this statement. From a professional perspective, it’s true that having a critic with expertise in the subject often leads to more meaningful and targeted feedback. Experts can identify deeper design issues, point out technical limitations, and suggest informed improvements that align closely with the problem being solved. Their insights usually help refine the project at a more advanced level. However, I also think that feedback from non-experts can still be valuable, even if it doesn’t directly address the substance of the problem. Sometimes, people outside the field can highlight user experiences or emotional reactions that experts might overlook. For example, in a UX design project, a non-expert user might not understand the interface logic or find a certain feature confusing. While this feedback might not tackle the technical side of the design, it still reveals accessibility or clarity issues that are crucial for improving the user experience.

I agree with this point, because without faith in the design process it becomes very easy to give up—even on an idea that has the potential to solve a real problem! Discouragement from external voices or internal self-doubt can make us abandon designs too early. That’s exactly why practicing the strategies mentioned in this chapter (finding the essence of something, building analogies, and training ourselves to notice details and externalize it) matters so much. I find this chapter useful because now I know how there is practical strategies to give me the confidence to push forward, refine ideas, and discover new possibilities. I feel like having faith is not blind optimism, but an essential mindset for transforming challenges into meaningful designs.

I see the value in the author's point about personas, but I also find myself disagreeing with this approach to a certain extent. While personas can be a useful design tool to capture a specific user group, I think that creating "fictional people" risks being too abstract or even unrealistic. Sometimes these imagined profiles might not align with the real needs of users. In my opinion, instead of relying on fictional constructs, designers should gather insights through methods mentioned in previous chapters--interviews, observations, surveys... These methods help ensure that design decisions are based on real experiences and evidence rather than assumptions. Personas could serve as a way to organize and communicate findings, but they should be built on genuine user research, not imagination alone.

I agree with this idea because it highlights that design is not about finding the “correct” or "best"method but about adapting flexibly to different constraints like "time, skill, or resources". What I find especially useful about this is how it extends beyond design itself. In many other fields (like health, law, engineering, etc), the ability to understand context and adapt methods accordingly often determines the success or failure of a project. This chapter really encourages me to value context awareness and adaptability as much as technical knowledge.

I agree with this point, and it really speaks to me as an iSchool student because our field emphasizes the importance of diversity, equity, and accessibility. Connecting this idea with the previous chapter, I see value in recognizing that design power can shape whose voices and needs are prioritized. At the same time, I think the alternative to this issue could be creating multiple designs that meet different needs/serve various user groups. For example, designing a single interface that tries to accommodate everyone can become overly complex, whereas separate, tailored designs can provide more direct and meaningful support to specific communities.

I find this idea striking because it reframes design as not just a creative process, but also as source of influence over what people use daily. This also makes me wonder: does concentrating design power (for example, in a visionary leader like Steve Jobs) lead to more innovative products, or just more personal bias? I believe this question is addressed in the next section to a certain extent because a good designer must hold the essential skill of " maintaining emotional distance from ideas." This skill prevents design decisions from becoming too connected to personal ego or subjective preferences. Instead, it encourages designers(even powerful ones) to step back and evaluate ideas critically.