An odd reflection on some good design

I am currently entering my last two weeks of being an undergraduate student at Carnegie Mellon University. Knowing that the time between graduation and work is the last uninhibited vacation for a long while, I am planning a Eurotrip to Greece and Italy with a friend from highschool. Among the travel plans, i needed to get a watch (i do not want to lose my pocket watch in europe). Knowing all I need is a cheap digital watch with an alarm, my father purchases and sends me a watch that he found. He sends me the Casio F91. Now I am sure the people who know that model by name are numbered, so here is a pretty picture.


After opening the package these were the thoughts that went through my mind:
"wow, i havent seen this watch model in years"
"i remember the band snapping off"
"its sort of the 'my first real watch' watch for young children"

In short, I remembered having this exact watch when younger. When putting it on, I felt how light and inexpensive it was. Then, i went to navigate the three buttons on the unit. In less than a minute, I had exhausted every function of the unit. This is said in respect, not insult to the device. The fact that a system I have not experienced in well over a decade comes back so naturally is an achievement of the designers. Granted the watch only has three buttons - but I have seen many systems that take simplicity of form for granted in an ever confusing hierarchy of actions. The ease of use of the watch is an impressive feat for any designer, especially considering this watch was probably designed well before interaction methods and usability had the buzz worhtyness they do today.

So in the end, this is just a tip of the hat to the designers and engineers of the Casio F91 digital watch. A beginner watch no doubt, its interface shows simplicity and function very well.

A rant on computer's memory and my own...

I remember a lot of things. I can tell you about an argument five years ago, or what the weather was that day in the second grade that I realized clouds shouldn’t be drawn blue to save crayon. When it comes to computer systems though, I could not tell you what the warnings are for different applications and what the repercussions of ignoring them are. When confronted with these stop signs, I generally ignore them knowing that the outcome, in that particular case, is acceptable. Having said that, the next time I use the application it might be different. This brings up the issue of the modal dialogue box:

“Warning. If you continue such and such will occur.”

Your options are to continue or cancel. You also have the small radio button to never show this warning again. Now, I recently started choosing the never show me this again option because, when exporting a series of files, it gets very annoying to constantly see this window. The system should remember my choice, shouldn’t it? (Thanks Alan Cooper and the authors of About Face for this insight). Still, when I return to the application a day later, I might be working on a different project and I do want this warning. From this point onward though, I have essentially shot myself in the foot. No longer will I receive the warning that the transparency will not transfer or that the hidden layers will print. This must forever be stored in my memory.

As I said at the opening, I have a good memory. Ask me what your favorite color is after not seeing you for four and a half years, I will probably remember. Ask me what the repercussions of ignoring a computer warning? I will probably make a joke about the nostalgic blue screen of death or the more topical beach ball of death. The system needs to be able to realize when a command is being ignored during a specific instance and when a warning is being ignored for ever. It should not expect me to remember things that are written in such an obscure manner that, well, only a computer can understand. Systems need to learn and be programmed with a certain amount of logic and persistence, beyond the standard on/off switch we have all been forced to submit to.

Mechanical Age versus Informational Age in Learning

Coming home for my spring break vacation, I had many things planned: visit friends, relax in the warm Miami weather, rework some design projects and get some additional work done on my current design initiatives. I also knew I had the prestigious honor of reformatting my parent’s computer. Having been on the fritz for some time, I often suggested that my father reformat the system but my parents were comfortable in waiting for me to get back in town. This is based not on the comfort I have with technology but my willingness to hit buttons and see what happens. I do not have any more technical knowledge when it comes to setting up computers, I just hit functions until it does what I want and I get a large mental list of what went wrong in the process.

It wasn’t until I got the computer functioning again today that I realized this hesitance to format the computer is the same as my friend’s hesitance to use power tools. Back at school, I am involved in construction for our Spring Carnival. On a team with a handful of students who have never used power tools, I have become a sort of teacher in the way of power drills and the glorious dremel. No expert, I simply approach the problem and play with the materials until I get the desired outcome. The obvious physical risk of power tools aside, some of the others in the organization are afraid of the tools much the same as my parents don’t want to reformat their computer. The curse of the beginner, they have simply never used the tools or carried out the function and due to some perceived barrier they delegate it to someone who is deemed more skilled, even if I just button mash (my generation got something out of Nintendo).

In this way, I find it interesting that the mechanical tools and the digital world have this similarity. It shouldn’t be any sort of surprise, people hate being novices and looking inept at a task. Still, there should be a way in designing interactions and experiences that makes it easy for the novices to step up and feel confident in using the application. It is too easy to forget what it was like being a beginner at something, especially if you learned it at a young age. Although people are novices for a short time and learn quickly, a poor introduction to a system, interface, or physical product might turn them off from using the system any further.

(no big closing, here ends my observation.)

Meeting Consensus

An interesting thought came up at a lecture recently. It was stated that it is better for the ultimate design if everyone leaves a meeting slightly unhappy than if everyone is happy, or if one specific team always wins. Having never thought of this before, I was curious to the rationale. Once provided though, it made a lot of sense.

The reason behind this is simple. Say there is discussion between the designers and the programmers. If the designers always win, it was mentioned the code will suffer. Conversely, if the programmers always win and implement the easier method, the design will suffer. To expand beyond the lecture, I can see this happening for many reasons. To use the cliche, you lose the forest in the trees or the trees for the forest, whichever you prefer. A more imminent threat through is a loss of stake in the product. If your team finds they are consistently getting steamrolled into submission, the ideas that come out of the department will quickly suffer and the entire project will be of a lower value.

For this reason, I believe it is important to "air your laundry" so to speak when in a group dynamic so that negative energies do not build up to explode later. On the same note though, there must be compromise and the ability to move on once a disagreement has been aired, addressed, and reasonably solved. This will not only allow the design process to move forward but will also spur additional creative thought as all ideas are valid and there is no ultimate iron hand that makes all the final decisions.

Affinity Diagram IceBreaker

Blame it on my being overly involved in Orientation, Pre-College and Admissions. Maybe I participate in too many ice breakers getting to know complete strangers in a relatively short manner of time. I found a new metaphor for the literature review and affinity diagram stage of a project.

These steps are the Icebreaker. In a social setting, icebreakers are used to introduce strangers and to facilitate trust in a short period of time. It is much the same with affinity diagrams and literature reviews. Both of these methods facilitate trust among the team members as well as providing an overdose of information very quickly. Even in teams that have worked together in the past, there is the new “member” of the project space that must be introduced and this is a vita part of the project to lose inhibitions and truly embrace the project.

An Introduction...

I've held many blogs in the past. None of them have ever lasted, and none of them have ever amounted to much more than a compilation of strange stories or listing of information I don't really care to keep. More often, I find myself writing in personal journals. Much of what I write I have never wished to share, being a self inspection of my actions.

As I start to look beyond my existence as a student of design and look for a position to practice it as a professional, I find myself discussing methods and techniques with others that warrant a certain amount of criticism. Unable to achieve that in my own journals, I plan to use this blog as a means to express my various editorials on design in an attempt to better understand my process as well as my needs in the upcoming years.