The readings this week focus on prototyping and information architecture. The blackboard reading discusses information architecture. The first thing it describes is navigation and how understand how users navigate websites. The authors bring up information scent and information foraging which is something we referenced at the beginning of the class. There are many different approaches and views regarding navigation and not one particular approach can be the best every time. Like so much in human computer interaction field, the motto for making decisions is once again, “it depends”.
There is a very nice chart on page 126-127 explaining the various navigation models that I found very helpful. The chapter then goes into explaing how to develop and initial architecture. I am not so certain about the usefulness of the card sorting activity as a method of determining architecture. It seems like a very large amount of time to waste to have participants group categories. If the designer already knows the categories and what is in them, surely they have a good idea of what goes where. I would rather see it more as a double checking the designers work than as the initial construction. I suspect that often the authors of HCI books think HCI groups have a lot more time and money than they actually do.
There is another useful and simultaneously specific and yet somehow broad checklist about reviewing the architecture of your site on page 144 and 145. This chapter keeps iterating the motto “it depends” in a variety of other roundabout ways. I wish there was a chapter that actually gave examples and defended the decisions because a lot of what we read is along the lines of “choose what best suits your needs! “or “Not too many and not too few!” Which I would liken to my mother telling me to just swim faster when I was competing. (Rather than telling me how to do so) I would like some definite answers and if there are none, then barrage me with examples and explain why they made those decisions so I can get an understanding of it.
That being said, I did enjoy the variety of charts and lists in this chapter. It seemed pretty thorough without being really wordy or getting in too deep for each category. I think if I were going to create a webpage, I would look through this and use the checklists and make note if I covered in some way every topic they mention.
1. How do you choose between the different types and fidelity levels of prototypes?
This is dependent on who you are showing and what you want to learn. A low fidelity prototype should probably not be shown outside the project team as it will confuse outsiders with its missing parts. High fidelity prototypes should be made after a majority of the design decisions have been finalized as it will likely be time and money consuming to create. Overall, you should know who you are showing the prototype to and what you want to learn. You don’t have to show them everything if you only want to know a particular part.
2. What are some pitfalls to avoid when prototyping?
Don’t make it too detailed too early. Also, don’t fall in love with early designs. They will likely be destroyed or should be destroyed. Also, don’t worry about how it looks too early on, it will change and the most important thing is the overall functions, not the aesthetical choices.
I found the part about getting out the WD-40 underneath the How to make an effective Paper prototype section amusing. Also that fact that he mentioned “Scotch” Tape again as well as “Sticky” note pads. (With Post-it in parenthesis) The UX book is back to being oddly specific in its directions without giving examples which would have been helpful.
I am not certain about the purpose of the decoy buttons. They seem silly to me. If you’re testing only what you have…then you test what you have. Otherwise, don’t test. I don’t see the benefit in letting the user “click” buttons that go nowhere. It would annoy me and make me wonder what the point of the testing was if there wasn’t something to test.
The chapter ends with a wish list from the authors of what an ideal prototyping software would have. It almost seems like they essentially have the design requirements already, maybe we will soon be seeing prototyping software from the authors?
Katie Cissell 