Just 1000 word

Reflection #1 300 word. Clams analysis This week, rather than write one of our standard reflections, I want you to conduct your own claims analysis. Write me three scenarios in which human-human/human-system interactions are prominently featured in a narrative of usage, and conduct a design rationale and claims analysis on a minimum of 3 interactions/designed features from that scenario, each containing at least 3 "pro/con" analyses to them. For extra credit, link at least 3 of your points of analysis to bodies of theory we have discusses thus far in class. Again, requirements: 3 Scenarios Each scenario has at least 3 design features/elements analyzed Each analyzed element of design has 3 pro/con bullet points 1 point of extra credit for linking your analysis accurately to theory we've discussed Reflection #2 350 Word Argument We discussed at length this week the basic components and perspectives on prototyping, and introduced the topic of evaluation that we will continue to explore in future lectures. Furthermore, we have repeatedly tried to drive home the concept that there are a plethora of user needs activities, ideation activities, approaches to prototyping, and methods of evaluation (both formative and summative). The chosen approach depends most fundamentally on the context in which you are engaging in HCD. Therefore, this week I want you to reflect on the material by proposing a basic design scenario. Similar to your Persona assignment, you are just making this up for the purpose of the exercise. Write me a paragraph in which you include: The type of company you are working for (Office software, video games, household appliances, smart car interfaces, etc) The size of the company and size of your design team How significant are the time allotments and resources for solving your problem? Are you under significant time and financial restraints? What is the problem you are attempting to solve? Then, you will discuss the ideal prototyping and evaluation approaches for your given scenario/context, and explain why. Which methods are appropriate to the product and context you selected? Why might other approaches have not been better? Maybe the product you're developing doesn't really need low-fi prototypes because of a universal language (say you're developing a game for an existing console) or maybe you're less interested in basic concepts and more in expertise development (maybe you're developing highly specific software that requires a notable amount of pre-existing information and skill on the part of the user)? No minimum word count on this, but be specific in discussing your scenario, and give at least 1 argument for and 1 argument against a prototyping approach, and 1 argument for and 1 argument against an evaluation approach. Brief conceptual example: I am working for a small start-up developing a new app for recording video in cases of police abuse that is automatically shared to social media and activist groups with geo-location. It also will contain features in-app to simplify contacting local representatives, smart technology will identify social media accounts and contact information for police officials in your current area, and it backs up video to the cloud. The problem I am trying to solve is that people want to help keep police accountable and lend their voice to an argument, but they don't know how they can be most effective in the least amount of time. Good method of prototyping: Physical Mock-Up Why? - The core functionality we are designing for is an in-situation physical response to an observation. We need to evaluate if the user understands the basic interactions of our designed product in terms of simple task-execution. A physical mock-up can emulate the physical action of pulling out a camera in a scenario and pointing it at the action, as well as reflect the basic low-fidelity buttons that link to our core features. Poor method of prototyping: True Programming Why? - Programmatic functions and the act of streaming/sharing is a conceptual piece of understanding for our users. The ability for them to engage with a prototype that actively shares their videos is not as important as their understanding of the core interaction we are designing for. If we had more resources as a start-up, we could have multiple phases of prototyping, but testing "functionality" is less important to us than testing user comprehension. Good method of evaluation: Cognitive Walkthrough Why? - When we have a working high-fidelity prototype, what we really want to understand is how our users cognitively process their actions with our product. What do they think is happening when they open the app? When it automatically starts recording, what are they thinking about? What do they think they know about what happens with their content? Do they have any thought processes or halting points that we did not predict? Poor method of evaluation: Heuristic Evaluation Why? - We are less concerned with direct usability evaluation in terms of specific button presses, mapping tasks to interactions, etc. Additionally, the core tasks and processes behind our tool is very simple conceptually and does not involve significant modularity, multiple needs to satisfy, or active saving, sharing, content management, or other smart device manipulation. Reflection #3 Word 350 Evaluation Design This week we dove into a bit more detail about the broad picture elements of evaluative research. We broke down each major component of conducting evaluative projects, from variables and hypotheses to criterion and participant management. For this week's reflection, I want you to select 2 solutions, the basic components of a research study in HCD, and break down all of the things you would measure and control for as follows in this example: Sample Structure Solution: Bluetooth Device Swapping in Smart Headphones Independent Variable(s): Press-and-Hold Pairing vs. Menu Navigation Dependent Variable: Speed, Error Controlled Variables: Prior Experience with Bluetooth Devices, Age Hypotheses: H1: Pairing speed will be significantly higher for Press-and-Hold Pairing than for Menu Navigation. H2: Error rate will be significantly higher in the Press-and-Hold Pairing condition than the Menu Navigation condition. H3: Prior experience with bluetooth devices will lead to more speed and fewer errors in the Press-and-Hold condition. Methodology: In this evaluation study we will be having participants in a lab environment complete a series of tasks around pairing, un-pairing, and swapping control over Bluetooth devices (our menu navigation prototype vs. standard push-to-pair functionality). We will measure along metrics of speed and error to determine how successful our intervention is in simplifying the process of managing multiple smart devices in their interconnections. Participants will be debriefed post-experiment to gauge their opinions, frustrations, and preferences. Analysis & Commentary: What are some of the issues you might predict? What elements to be aware of? Remember our discussions over stakeholder characteristics such as a fear of making a mistake, frustration, desire to please the experimenter, etc. How are we ensuring a smooth, efficient project? How are we comparing these measurements to one another. What values in our chosen variables will be able to confirm or reject our hypotheses? What do these hypotheses mean for the design and development of this solution?