Norman Blog 1 - Andrew Lane

Chapter 1:

While I thought this chapter was mostly a lesson in common sense complicated by adding fancy buzzwords such as “Conceptual Model,” I did get one lesson out of it that hits somewhat close to home. I’m a software developer by trade. Most of my development is improving an existing product. Many times I create an innovative new solution to a problem that is intended to make things more transparent and easier to use for the end-user. My latest was a scheduling feature that allows customers to schedule services based on different times of the week. It’s taken years to get a comprehensive structure to handle the kinds of requests we take due to the enormous complexities of time, and once I finally created a working solution, creating an intuitive front-end control for it was no small task. It took me weeks to design this one webpage to control scheduling. There are around 100 options on the page that users can use if they need, but only 5 are visible up front, and many of the options should very rarely ever need to be used. Everyone who sampled and tested the page before it was released to the public was very impressed with the flexibility, new features and clear instructions, so it didn’t take too long to get it implemented (I was also facing a November 4 deadline because the new scheduling system was necessary for daylight savings time). Once the system went in however, it was a totally different story. We had always had a complicated scheduling system before this, but the new array of controls amplified the visibility of the complexity, and everyone was terrified to use it. Several users had problems with it, doing operations I had not anticipated. They were able to do them, but it wasn’t straight-forward exactly how to do it.
Chapter 1 in the text goes through many such examples where something may be brilliantly designed by one person, but when it comes to actual usage, it’s not as brilliant after all.


Chapter 2:

I don’t believe I’ve had too many issues with false causality, wrong human explanations, or naïve physics, but the beginning of the chapter reminds me of something I did right with the web page mentioned above. Once the user drills past all the easy, quick-configure options on the page, they can enter manual values. I purposely made this section more difficult to reach because common operations can be done with just a few clicks instead of manually entering start and stop times for each day of the week. This final control set can have anywhere between 4 and 400 options to configure. You can probably imagine how that has the potential to get very complicated very quickly if the user doesn’t know how to use it. This ties in with the first part of the chapter where it talked about anticipating user error. The control set checks itself, reports a graphical interpretation of the user’s commands, and will even highlight user errors. If a user over-complicates a schedule, they can also click a “simplify” button that aggregates like schedule sessions together and minimizes the amount of controls they have to deal with. No lessons learned on this chapter, but at least I have some justifications for what I’ve done.

Chapter 3:

This chapter was an interesting read. It didn’t inspire any great revelations like the last two, but it did remind me that I need to get a program to store my hundreds of passwords for bank accounts, credit cards, work accounts, email accounts, social networking sites, and this blog site.