Preparing for the HCI 440 final exam

I have always wanted to be different. While many other bloggers will rant about the historic elections, I will move on to more pressing personal topics, such as my upcoming exams. I had (last few weeks in play) the privilege of attending a HCI 440 course this Fall, as it is winding down, it is fitting I write about my User Experience (pun not intended or intended) this Saturday morning.

Design Theory: My bachelors degree many moons ago was in Architecture, this course in many ways was a rehash of design theories I learned and have forgotten since. There has been a lot of progress in 30 years in the field of design. But the essential fundamentals remain the same. ie. you are designing FOR USERS. The big difference this time around was the amount of involvement of users in the design process. There has been a significant body of research that has gone into cognitive studies understanding why and how we do things. This in my opinion has greatly enhanced the design process. I highly recommend this course to those of you who started out many years ago as I did.

The largest impact in my opinion is the application of design principles, processes and cognitive research that has gone into making what HCI (Human computer interaction) and UCD (User centered design) is today. There are many heavy weights who have contributed to this discipline. Names such as Jakob Nielsen, Bruce Tognazzini are just a few to scratch the surface.

So what exactly did I learn in these 11 weeks? The material we covered in class came from the book: "Beyond Human-Computer interaction" by Yvonne Sharp, Helen Sharp and Jenny Preece. Lots of great material in the book that spans Requirements gathering, Analysis, Design/Prototyping, Iteration, Evaluation and testing. Iteration by far was the most powerful concept that I latched on to. We also worked in a group of 6 to collaboratively design a Mobile application that replaces your remote controls around the house. It appears we will have a fairly decent final prototype by the 11th week.

We also covered various Theories, models and Frameworks that was a segway into Agile and SCRUM methodologies. I got a chance to watch what Jeff Sutherland did at google on the Adword project and what Jensen Harris did with the User Experience team at Microsoft as they developed the ribbon user experience for office 2007. Included here are links for your viewing pleasure if you are into that sort of thing.

Usabilty and User experience goals along with design principles and how cognitive theories tie into these, was fertile fodder. Use of metaphors was a fascinating study as you look around and see the rampant use of metaphors in design these days. Trashcan, desktop, Search engine, Browsing and exploring are all great examples of how metaphors have been used in todays design world.

I will leave you folks with these three thoughts:

The Architects of yesterday will really enjoy and benefit from this course, for it explains many approaches we gravitated to intutively years ago. The medium of design has certainly changed, and so has the process. Yet innovation, creativity and immagination are attributes that we will always strive to in our designs in years to come.

November 13th is World usability day. A lot of good events are planned around the world on this day, a testament to how far we have come. If you are inclined and wish to make time explore the world usability day event map is a great place to start

If you get an opportunity, try out Mozilla labs Ubiquity. It told me that there are some really sharp folks out there creating and innovating. All we have to do is be there to enjoy the USER EXPERIENCE.

That folks, is my Saturday Morning Rant for this Saturday November 8th 2008.

Validating Truths every so often

If you are a Project Manager, one of the things you do as you run the project is to review the requirements at certain intervals to make sure your project produces a product that will be used when complete.

It happens in real life as well, take our school system for example. I remember when I was in the 6th grade, I did something I should not have done, I got called into the principles office, where this nun pulled out a long narrow flexible cane, made me stick out my palm and whacked me a few times across it. We don't do that any more in most schools. At least I think we have validated our truth about discipline and use other methods to discipline our children. I don't think we do this enough, because if we did, we would have evolved faster or at least we would have shed some truths that need shedding very badly. Perhaps I should make a list like Earl on his hit show My Name is Earl.

What made me write about this today?. Well as you know I am taking a HCI class at DePaul this quarter. The first assignment was the proverbial usability experience analysis of an "Alarm Clock". It is a cliche in the UX (Usability eXperience)world to use the alarm clock and usability in the same breath because of the ubiquitous nature of the device and the ubiquitous nature of the fact that we wake up every morning to do something. As I set down to write this paper, I realized that we never validated the truth about the the alarm clock. Is it a time keeper or is it a device to wake me up?.

If I were asked to design a device to wake people up today, from scratch as Google did with the new browser, what would I do? What would you do?

Here is what I came up with:

Having used an Alarm clock for over 30 years now, I never once had to validate the truth about Alarm clock design, until I got to this HCI class. As a designer, I believe in validating design requirements often, hence this approach. Consider this is an academic/design exercise and I start with validating the truth as follows:

In my years of using the Alarm Clock, I have come to associate an alarm clock to have 3 major components:

1) Alarm/Alerting mechanism;
When an event occurs, send out an alert indicating it occurred.

2) Time displaying mechanism:
A device that displays universal time that is adjusted for time zones represented by geograpic locations

3) Setup/Configuration process: The user is given hardware and instructions on how to program the Alerting mechanism as well as the Time displaying device.

Validating Truth behind the purpose of the device:

The question is what are we trying to accomplish? If the mission is to be woken up at a specific time, then we need a device to wake us from slumber/sleep/state of rest at at a time we specify before that state or have specified as a recurring event. The whole object is to to be awakened from Sleep. That is the purpose, the object, the criteria we should design for.

Through time and iterations of industrial design, we have arrived at the modern day alarm clock. When I was growing up, my Mom or my sister used to wake me up. I always woke up as they persisted until I woke up. In essence my job was to wake up and the job of reminding me to wake up and persisting till I woke up was removed from me in a state of slumber. The closest that any "Wake up" method of today comes to that effective way of being woken up at a specified time is the Wake up call, where you call into a system, be it the front desk of a hotel or a wake up service and it automatically calls you at a specified time.

If I were given a fresh start were asked to design a Alarm clock today, that is exactly what I would do. with this method, I am not investing in a Clock, but more in a Wake up device.

So my truth (validated) today amounts to this. If I need a Wake up call, I should use the most efficient way of doing just that. If I need a clock, then look for a device that provides the most Accurate time for you and your current state. If you are blind, you should get a audible time display device, If you are deaf you should have a Visual or sensory display and so on.

Should Alarm Clocks be designed as a combination Alerting mechanism + Accurate Time keeper + interface for Users to configure Alerting and Time?
Perhaps they should and if so let us design for each of the 3 parts and then consolidate them to arrive at a good design that fits our UI and UE (user interface and experience needs). Following are guidelines for each of these components:

1) Keep it simple: means using known, stable methods and technology that consistently provides alerts, keeps correct time and provides a simple UI. Failure is within six sigma limits.
2) Keep it redundant: means making sure in case of failure, a back up plan kicks in, keeping Failure with the six sigma limits.

Keep on Validating your TRUTHS, that's my Saturday morning Rant for this week.