Seminar 2 Reading Notes - Jessie Pease

The reading for Seminar 2 had the bulk of information necessary to complete the design process. 

Chapter 6 taught us about Ideation and Design Principles. This chapter would have been much more helpful to read before our brainstorming process for the last two weeks.

Ideation can be broken down into a series of steps:

1. Warm-up
1. By this, they mean literally warm up your brain, hands, and mouths. In order to have a successful brainstorming session every group member need to be mentally, physically, and emotionally present. 
2. Set a Time Limit
1. Without a time limit, brainstorming can feel like a lengthy, tiring, and never ending process. By setting a fixed time, you can have a sprint of ideas. 
2. When it comes to brainstorming, things to focus on are:
1. paint points, opportunites, process moments, personas, and metaphors
2. I really liked the different exercises they suggested for us to complete:
1. Brain writing, Break the rules, Force fit, Poetry, Questioning, Laddering, Swiping, Bizarro world
3. Organize Your concepts:
1. Label and sort by criteria
4. Creating design principles
1. This is where you finally sit down and write down the concrete design requirements and potential solutions
2. This comes after the crazy mumbo jumbo of creativity above
3. These principles should be pithy, memorable, cross-feature, specific, a differentiator, and non-conflicting. 

Chapter 7 was all about refining your brainstormed ideas. I will review the things I found most applicable to our team’s design problem. 

1. Affordances: This is appearances. How does your design look? Does it imply how a user would interact with it? The appearance needs to be contextual and cultural. 
1. This is one of our biggest issues because we don’t want to put written instructions on our game, so our design must be extremely innate. 
2. Feedback: Latency is a huge issue and often frustrates users or makes them have user errors. 
1. This is also one of our biggest pain points from our interviews. Our latency needs to be immediate, which means it needs to be .1 sec or less. More than that will cause children to lose complete interest in our game. They will likely be confused. 
3. Hick’s Law: The number of choices and how the choices are presented determines the amount of time it takes a user to complete a task and make a decision.
1. This is very applicable to our game. If we gave the children too many choices for animals after they hear a sound, then it will be too difficult and they will feel defeated when they take a long time to get a correct answer. That being said, if there are too few choices, then it will be too easy and they will lose interest. 

As we continue to develop our game, it will be crucial that we also use a site map sort of thing so that we know what happens with all the different use cases. Site maps focus on initiation, activation, and updates. For us we need to focus on start, correct answers, incorrect answers, end, winning, and many more cases. As we build our site map it could be helpful to create a story board or task flow to show off these use cases. 

A large portion of this chapter talks about wireframes. Wireframes are extremely useful when it comes to websites and applications, but I think it would be very difficult to explain our game using a wireframe. It would be a lot more words than images since there is only one way the game is set up. 

Even though we aren’t making a wireframe, and it is very complex, it does pose a lot of thoughtful questions and things to think about such as:

• non traditional inputs, gestural interfaces (how do your users move? how will they interact with it?), and presence. 

Presence is something we are dealing with at this very moment. We are trying to decide whether or not we want the users to be sensed when they enter the game area in order to automatically start the game or not. The section about presence brought up a few important questions like: Will they feel like their privacy has been violated? Will they understand why they are being sensed?

Finally, chapter 8 is all about prototyping. In criticism, I would have liked if they pointed out specific prototyping tools. Although this may outdate their book, it could be quite helpful to hear what an expert thinks about specific tools. 

Luke Wroblewski gave some specific advice about prototyping that are very applicable to our design: 

• use audio cues sparingly 
• instructional text is rarely read
• visual design shows importance and relationships between content
• personality of the design should reflect the designers
• common mistakes overstatements of visual contrast, too much emphasis on everything (basically simplicity is good!)

When making a prototype, there are different types. Ours will likely be a low fidelity prototype because we do not have the resources to create our large technical game. When we do testing, we can try A/B Testing. I think it will help us make our final complicated design decisions. One of our problems for testing is because our sub group is children, and we might have a hard time getting children to test our product, we might have to use some heuristic evaluation of our final prototype. 

The end of the chapter spoke about agile development. Agile development is not something I am familiar with because I normally work on Security and Privacy engineering teams. If I ever work on a design team, it is now helpful to know how the agile development works. 

Questions:

- Is it always necessary to make a wireframe?

- Did we do waterfall development for our project?