The final three chapters of the book were great because it explored more into the design aspect of everyday things. They also talked about human error which is an important part of how the entire design system works. If someone makes an error, be it a slip or a mistake, it can cause problems with the system they are interfacing with. A wrong key press can wipe your entire hard drive out, a misplaced figure can mess up an order for a business, even a wrong transfer can send you to the other side of the city (Its happened before). It was humorous reading Norman’s examples of each form of slip and it helped figure out what each different slip was. Associative Activations Errors and Loss of Activation errors are common with me because most of the time I will forget to do part of or the entire activity. I’ve walked out of my room and 12:30 in morning, going for a midnight snack, and then find myself in an dark empty kitchen. Also, I’ve had times where I’ve said the wrong thing at the wrong time, like answering “What Up, G?” on the phone with my grandmother, pre caller ID. I think designs should implement features that cover mistakes and human error. Computers have most of that covered with the often extremely annoying “Are you sure?” dialogs that come up. Cars have a warning when doors are open and headlamps are still active after the engine is off. However, I found out that my car’s warning only works on the driver side. After a conversation with my mom where I appeared to be a complete idiot, not according to her, I made sure to listen out for the noise. Also, I did agree with Norman’s ideas on social pressure and mistakes. The Korean Air situation is a good example of both social pressure induced mistake and a fairly bad interface. If the inertial navigation system could be reset from within the plane, that problem would not exist. Also, the fault of the INS failure shouldn’t fall on the pilots or at least don’t tell the pilots that they would reprimanded. I would rather not know something like that, already piloting a big steel, gasoline powered cylinder, several thousand feet in the air.
The design process chapter I enjoyed because I’ve always like designing things. Letters were always cool to me; hence the graffiti and then the graphic design major. Cars were always something I adored and I really wanted to design cars but I sucked at drawing around that time. Norman makes a great point in the heading on pg 155 “Designers are not typical users”. It speaks volumes for all the horrible designs that pass as user friendly. The expertise of the designer and the user are two different criteria. Designers think about aesthetics, comfort, usability , ease of use, and many other parameters when designing something. While those parameters are relevant to the user, the ability to use the product is the most important aspect of the design. Sure a phone can be a beautiful design aesthetically but if you can’t dial a number without becoming increasingly aggravated over the action itself, it isn’t a good design. Designs should be suggested not by the clients but the users themselves. Even though, most of the current phones are legitimately user friendly and not difficult use, sometimes you get a phone that will make you question why in the world would some one think that this would be profitable. Things like false imagery and creeping featurism are temptations easily succumbed to. I once had an organizer that could play polyphonic ringtones. It couldn’t place calls but I could play ringtones on my organizer. I understand creeping featurism but I just don’t get how piling on so many features into a device or software. I enjoy this temptation because I usually end up using all the features, even though I have no need for them.
User centered design was a good wrap up because it gives you the building blocks for great design. Norman reiterates his design principles on 188 which helps put the system and process of design into perspective. Simplifying the structure of tasks, especially complex ones, is important because no one like difficulty. For example, I’m going to use the token vs. Metrocard argument again as an example of such. The token was easy to use for the rider, but an arduous task for the MTA as they had tabulate their sales based on the sheer volume of copper tokens, minus all the counterfit tokens that made it through. The metrocard is supposed to be easier for both the rider and the MTA. The rider gets the card and swipes it. The city now has electronic systemt to tabulate revenue from the fares. The technological aspect can be circumvented by counterfeiting as well glitches with the ID strip (Fares don’t work, errors). The city made their tasks simpler while making the riders just a bit more complicated. The constraints created by designers is important because they can help the user determine the appropriate action. It is a shame that appropriate constraints aren’t used more often.
No comments:
Post a Comment