Andrew_5_I

As far as designing goes I agree with Saffer concerning wireframes. When I design a website I think wireframes help out a ton when it comes to mapping out a site. They give you a sense of direction and allow you to see the flow of the webpage before it is created. Essentially you can see the webpage before it is actually designed, which allows you to target any problem areas that might arise during the designing phase of the website's construction. Wireframes/sketches are a huge help when it comes to designing a site.

Taylor_5_1

I think in any project you have to plan well to get exactly what you want. As i work on a project, I take my ideas and write them down. once they are on paper i think of all the different ways the idea can be expressed in the project. I think once you have a general idea or plan, you can just throw your creativity in and that's when the project takes shape. Sometimes you have many different projects from the same idea.

Justin_5_I

I thought the part of the chapter on Research Models was very good.  Creating a model or rough draft of something is a good way to begin creating a project.  It was interesting to see a good amount of different models that can be used for projects.  When I start projects I tend to try to make a rough copy of what I want as a final project and seeing these kinds of figures will help with projects.

Bryanna_5_I

I think that planning in interaction design is much like planning in any other discipline.  A lot of times, when I'm writing a paper for an English class, I just kind of dive into it, without planning.  This works for me, but a lot of people cannot put cohesive thoughts together without first making a detailed plan and outline.  The same goes for design work.  Some people find it easier to just start messing around in the software and work out the kinks from there, where other people need to put what they have in their head down onto paper.  In my opinion, it just depends upon the kind of person you are.  

Frye_5_I

I thought that the last section on testing was key. Without properly testing a design, it's easy for the designer to think that their design is finished. By testing a design, It allows the designer to realize the shortcomings of a design at to improve a design upon them. For instance, I've had web pages that I thought looked great. But when I had others check them out from their own computer at home or work, they didn't look that good or they found problems that I didn't see happening. I was then able to take what they had given me and correct the problem.

Christian_5_I

The part I liked from this chapter was about sketches and models. When I am doing any project, especially something like a website, I always go into Photoshop and mock something up just to have something to look at. I think you can learn a lot just by putting your ideas down on paper or a computer or some other medium. Having that visual to learn from can be very useful. After you get some of your ideas down, the project can really take life. I often find my end product to be completely different than the initial idea, but it develops over time and is a good place to work from.

Chris_5_I

I liked the section on personas. I think it is quite important to have some sort of idea who may be using your product. If you are designing for a large number of people, it is important to know their interests or preferences for a better understanding of how one will design a product. The author mentions that recording these behavior patterns may help in directing a product design. Saffer also mentions that personas are useless unless you have scenarios. These scenarios provide a sense of how the design will be used.

Evan_5_I

It was interesting to read this chapter because I've used some of these diagrams or models to plan out a project. However, they were just to help me out. I never thought about actually using them to present to people as part of a proposal. Usually if I have have a project to do, I just do it. But when you think about it, after we graduate most of us will probably be required to present diagrams like the ones in the book to clients before we start working on getting the actual project done. I'd actually like to see this more in some of our classes. I know some classes require a proposal and/or beta versions of projects to be turned in (like Dr. Dailey's class). It might be a pain for students, but I think if more classes required it, we'd have more practice in how to present interfaces to people/potential clients who aren't as experienced with interaction design as we might be.

Patrick_5_I

I think storyboards are great.  They definitely help you plan out your ideas.  When I have trouble thinking how a website is going to work, I just storyboard it all out and I can visualize how it would work on the computer.  It's just one more step to completing the project and testing out your ideas before they go into the program.  Like Justin said, you can see how it is going to work from a number of perspectives.  Storyboards and other types of planning on paper are great ways to work out some kinks.

Jacob_5_I

I am pretty familiar with task flows.  They work well to convey the logical connections between actions and states in a design.  However, what I was not aware of before reading this book is what Saffer calls Use Cases (Saffer 107). I thought it was pretty interesting, and it actually parallels something else I am familiar with called notecarding from a book called Big Java (3rd Edtion) by Cay Horstmann.

The idea of notecarding is to identify the verbs and nouns inside the system you need to design.  Once you do this, you can group nouns inside of other nouns (where it makes sense to do so) and then associate all actions with the appropriately corresponding nouns.  (You can also put actions inside of other actions: i.e. the action of running may require the action of moveLegs.)

The Use Cases idea seems a little more focussed than note carding, or rather more structured.  Where the notecarding is very general, the notion of Use Cases seems to mimic the task flow - it sort of plugs the designer into any given point in the design and says "what happens here?"

The other nice thing is that a use case seems to be generalizeable.  In other words, I can talk about a very specific use case or a very broad use case (i.e. the entire use of the system from beginning to end),  albeit I think in the broader use of the notion of use case one might run into some problems with Poka-Yoke, but I think that's the fun of design.  E.g. You might say that "At the beginning, the user sees the Web site and can access all of his tax information.  At the end, he has filed his taxes."  This is an informative use case to me; it describes in general what the design should accomplish.  But for more complex Websites with many possible beginnings and ends, it gets a little fuzzy.

So, I think it just depends on your style and how you want to approach designing the "hows" of the design.

Justin_Shimp_5_I

I almost always use storyboards to help me plan out how sequences will form and work out. I like using storyboards because it allows me to better understand how something is going to work from the viewer/user perspective and from the director/designer perspective. I think using a variety of these different brainstorming models helps a lot in gaining perspective on how things should not only look, but how to create it in that specific way, and how the user will interact with it.

Scott_5_I

I think the personas and scenarios discussed in the book could turn out to be something that is very useful. It allows you to focus your work on specifics rather than just generalized things. It allows to design for a specific person or rather a type of person alot better than just saying the users, because you need to know how your users think in order to be able to create something that they would want to use.

Kujo_5I

The wireframe part of the chapter is good. I think that a wireframe is one of the best examples of a final product till something tangible can be produced. It is something that can be quickly changed and shown to a client rather quickly. I tend to keep a stack of papers and notebooks with a bunch of my own idea's around and constantly refear to them and add to them. One notebook I draw and write out how everything is going to look and work. If you think about it many people use wireframes, Da Vinci had tons of note books with his thoughts and drawings. Many other people did too! Even though we're growing with technology I still think that it's important to write and draw idea's.

Kirk_5_I

I enjoyed this chapter the most out of all the chapter's we've read so far. If I had to choose which research model I like best, I'd have to go with wireframes and storyboards. I think that a successful wireframe can provide all the information used in a graph, task flow, and task analysis, and put into an easily understood visual model. There would be no use for personas, because each user will ultimately be using the same interface. I also like storyboards because it's an easier way of visually showing the logic behind certain user actions than a wireframe can provide.

Also, does any one else think the "mood board" is a bizarre method for making a research model?

After reading the the end of the chapter about prototypes, I started to think about cell-phone displays. When I have to choose a new phone, I'm much more likely to choose a model that has a fully functional phone on display, rather than the plastic ones with static screens that are typically on display. I wonder why cell phone companies still use the plastic fake phones when cell phones are so cheap already, and people are more likely to purchase a phone they can actually play around with before they buy.

Tetta__5__I

In the chapter, the writer talks about how wireframes work in interaction design. The chapter explains in details about wireframes, and it talked about dummy text that I always have been wondering about whenever I saw them in Adobe Dreamweaver templates or Apple’s iWeb, but now I know that they are just dummy text that do not mean anything. I can apply this knowledge about wireframes whenever I am going to design a website from now on.

Seth_5_I

I liked the section on mood boards. I think I have my own type of mood board (digital or on paper) with almost every project I make. It really helps to flush your ideas out for the emotion you want to convey.