Colin Bayer-Information Architecture

The article we read from The Inmates Are Running The Asylum about User Personas was perhaps the most interesting and "newest" material I've read so far in this class. It really takes the old adage of demographics and twists it around. For the longest time, it seems as though everyone is forced into a "class-" by income, race, interests, etc; and then the marketing firms or whomever uses these general descriptions to try to appeal to "more" people at once, alienating the individual. However, user personas is the opposite, and takes the path that magazines have taken. Ever notice how there is a magazine for everyone from cigar buffs to skateboarders to eastern European street performers? User personas are similar, in that they sacrifice accommodating EVERYONE so that they might perfectly accommodate one person. This way, while the majority of a population may not read the magazine about Eastern European Street Performers, those who DO will be 100% satisfied. I liked (and understood!) the rule of thumb that the more people- or types of people- you try to appeal to, the less satisfaction level in the product you will get. It makes complete sense.
Creating user personas does seem like a daunting task...You have to create a PERSON, basically, and make sure that this person is not generic. While stereotypes are fine (it helps define a person sometimes) it takes some creativity to ensure that everyone on the development team can create a persona with character. One part I was confused about was...While over-all, we try not to get too general, it's also not a good idea to get too specific when creating a persona- as outlined in the reading, it would be too "realistic" if our personas had the quirks of a real person...How do we account for that in a persona?
For design of interfaces, skill level is always an issue- mostly because we want to ensure that users from different abilities and backgrounds can all use an interface happily. The case study about the In Flight Entertainment was a great example of how they overcame a problem. They did an impressive job of finding the lowest common denominator and designing for him, while still taking into account that users of a higher skill level might be using their interface.
Finally, it was obvious that the author had something personal against programmers.

After reading chapter 3 in Veen's book, I've found that his style of writing is a bit heavier than Krug's- however, the difference is that the topics which Veen touches on requires more in-depth discussion.
One aspect of chapter 3 that I found interesting was the references to the different styles of structural heirarchies and how they vary from site to site, and why it matters which way they are structured. This is directly related to the in class project that is on-going, as we have explored many sites with different organizational schemes while keeping in mind the LATCH theory. It's helpful to read from Veen how many sites require more than one scheme in organizing their information, and cross-referencing them is quite important. For an individual who is say, looking at a product, he should feel as though he can access everything on that site relating to that product from one page, rather than having to fish through a sea of unrelavent pages.
Veen discusses web portals and how they take a plethora of information and are faced with the challenge of organizing it all so the links relate to each other, and so users stay on their site. His anaylsis of the three portals was in depth, and served to prove that there isn't necessarily one "good" way but there are a few "bad" ways to accomplish this. I think the problem comes in with the introduction of just too much information.

After reading the handout about instructions, and also writing instructions on how to use a can opener- I see how arbitrary instructions can be, leaving users pretty much lost. We got these shelves for clothing, that you have to put together yourself. The instructions are entirely visual, and not only that, but everything is out of scale and perspective. You don't know what screw you have to use for which part, and you don't know whether you're looking at the front or the back of the drawer unit. It's still half-assembled in the other room. However, a friend gave us another shelf unit, that had to be assembled, but did not have the instructions. I was able to build it myself, through trial and error, and it was less frustrating than actually knowing what I HAD to do but not being able to do it due to poor instructions. Maybe in the process of "simplification," things are becoming too complicated. I often catch myself giving driving directions to people that are complex- even though to me, the process of getting from point A to point B is simple. I try to give them many details so they know they're on the right track, but for all I know i'm confusing them with things they don't need to know.
As far as the Krug book, I've actually been reading ahead. I find it well written, and even entertaining. Some of the more important and interesting parts include the sections about how users percieve pages vs. how we design them, how users tend to find the first best fitting answers (so you'd better make sure you write what they want), and how using the 'Net is pretty mindless- people are less apt to read instructions and more apt to blindly surf through until they stumble across what they need. It's true, too- I've found myself doing that on many occasions. Again, the whole concept of "not making someone think" is shown as a prime example right there. The site redesigns were good too (chapter 6)- it gave me an opportunity to test out the theories Krug had laid out so far.