The idea of needing tension reminds me of the design lifecycle. First, you must identify the issue that you are trying to solve with your design. If there is no apparent issue, no gap that is being filled with your solution, it may not be something desirable on the market. Although that may not be the the goal of your product, it is necessary to consider: would anyone actually use this? How is this different from the other solutions out there? Then, the other parts of the narrative are like the analytical portions of pitching your idea. How do the needs that your solution is addressing ultimately lead to the resolution of the issue. In other words, how does your solution solve the challenges you've identified. The takeaway form the narrative structure is that it can be applied beyond storytelling to anything that you want to "stick" with an audience.

Providing multiple functionalities seems like a pretty difficult task that involves taking into consideration all the other heuristics as well. In order to create a shortcut, for example, it is important to consider how the user will know to use that shortcut, what documentation will be provided to help the user identify it, as well as thinking about what shortcuts the user likely knows from their daily interactions with their operating systems. This becomes even more difficult when we take into consideration designing for Android vs iOS since they use different shortcuts for the same task. Additionally, I wonder how Android ensures consistency across their applications since iOS requires all applications comply with certain guidleines to apepar int eh App Store.

This reminds me of asking leading questions in interviews, showing the deep parallels between testing and research. it is important to ensure that the decisions made by the user were independent and did not require the researchers guidance. The researcher won't be there to help all users navigate their solution the real-world and if lots of guidance is required, it might be a good idea to re-think the design for better accessibility or provide supporting documentation such that the user can independently navigate the interface. This once again shows the overlap between the ideas of heuristic and values that are used in the design process.

Like with any step of the iterative design process, there are many considerations that go into every choice that is made. Choosing a prototyping tool carries many tradeoffs and has a variety of implications. Why would you choose a low fidelity over high fidelity prototype? What resources are you able to allocate for this? How extensively do you need to test the usability of your design? How quickly do you need to change the prototype as a result of user testing? Using the lenses that were discussed in class and identifying which are most important for your project can help you flesh out your best idea when prototyping.

I like the focus on trying to understand the intention behind the designer's choices and whether or not their design successfully conveys them. This is especially important because many designs aspects are subjective. I like that this idea of a critique is that it can go both ways, giving the designer a chance to respond to feedback and justify/ discuss their design choices. This also makes me think of the various design philosophies and how the designer articulating this explicitly could provide extra context to the person providing feedback.

This illustrates the conflicting implications of external influence. While it is necessary to surround ourself in the context you are investigating, you must consider the implications of the context itself. Why did you choose it? Who is included/ excluded? Are there any noticeable patterns? Are these patterns a result of correlation or causation? Could you be perpetuating hurtful patterns through this? That is why diversity is the key to avoiding bias. By considering a wide range of ideas and including multiple voices in a discussion, you are able to get a holistic viewpoint.

This shows the importance of testing your design on specific actions performed by the user. This allows you to consider nuanced edge cases that might occur from user interaction, ensuring that the design will meet its functional needs. This makes me think about the bias that can occur from selecting study participants and how these biases feed into the models used to perpetuate these patterns. A good example of this is face recognition software having a harder time identifying darker skin tones because it was exclusively tested on lighter skin. This also highlights the importance of representative study populations to ensure design justice.

This idea of iterative development is especially common in the software lifecycle and was discussed in great length in INFO 380. This shows how it is impossible to cover the entire scope of an issue in one attempt and emphasizes the importance of feedback and testing. As I was interviewing students for this week's assignment I realized how nuanced issues can be but this is only revealed through exploration and knowledge of a certain subject. I beleive iteration is crucial to the success of any project and it is impossible to have a perfect solution on the first release.

I think this is an integral part of the learning process that arguably teaches you more than success. Currently I'm studying for technical interviews and I find that getting a problem wrong and working through your errors until you find the correct solution is the best way to solidify a concept, even more so than getting it right on the first try. I see how this would also apply to design principles.