Friday, September 12, 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.

No comments: