But is it haunted?

While on an only semi-hokey ghost tour of Old Town, Virginia, the tour guide mentioned a ’spite house’ nearby. Being a Texan and unfamiliar with the term, I elegantly removed the stalk of wheat from my mouth and asked the question, “What’s that?”

A spite house, it seems, is a design solution to an interesting conflict.

Problem: Dubious persons and sailors on shore leave would conduct business with other shady types as well as ladies of the night in the alleys between houses.

Solution: Fill the alley with a house.

Pictured is the spite house, which is roughly eight feet wide and two stories tall (it’s only as wide as the blue brick). And with D.C.’s amusing real estate, it’s worth nearly half a million dollars. A little piece of history, all to yourself.

This ain’t like dusting crops, boy

It’s funny how in science fiction everything is so advanced, but looks incredibly complicated. Prime example: the infamous Millenium Falcon, which is noted for making the “Kessel Run in less than twelve parsecs.” Despite it’s speed and agility, the dashboard of the space craft looked horrendously muddled. Was it because the ship was simply “the fastest hunk of junk in the galaxy”, or that sci-fi props are rarely built with an eye to UI?

Granted, the creators of sci-fi are obviously trying to impress us with all the flashing lights and beeping sounds, but are they not thinking of the UI utopia of the future? That things will get easier and will more often than not follow the psychology and goals of the user? One would hope that with a simple push of a button, Han Solo and Chewbacca could be jumping into hyperdrive. Instead it’s a process that seems to take awhile and cause them quite a bit of stress- especially when they’re being chased by a Star Destroyer.

Alright, so I am kind of cheating. The Star Wars saga actually takes place a long time ago in a galaxy far, far away, but everything else just looks so futuristic I just figured they had a user interface designer or two lying around in that vast galaxy. Surely a Jedi would excel at the profession.

And with that I will make a note of hitting my Star Wars pun quota for 2008.

Uncomplicated

More and more I’ve been checking out Cooper’s blog. It’s all very brilliant, but I especially love how they break design theory down into bite size chunks. They create an ongoing dialogue about design theory for those of us who want to learn more, but don’t necessarily have the time to sit at a coffee shop and contemplate dense design discourse.

My recent favorite is a simple explanation of personas by Chris Noessel. It combines two of my favorite things: the Simpsons and straightforward communication of ideas (is that too specific to be one of my favorite things?). Beyond giving me a great way to talk to clients/co-workers about proper use of personas, Noessel highlights how important it is to find a common language with those you work with. Too often we become wrapped up in our own little corner of the world with our special vocabulary, and we forget that people may not be familiar with all of the concepts and techniques that we cite. We have to find strong examples and illustrations of our ideas in order to get our point across, lest we find ourselves looking across the table to find an assortment of blank faces, glazed-over eyes and, in extreme cases, drool.

Beyond boardroom embarrassment, it’s a shame when good ideas and simple solutions are thrown to the wayside because people can’t understand what in the world you’re talking about. And we certainly shouldn’t look at finding ways to clearly explain our ideas as a chore or as ‘dumbing it down’ for the masses. It’s our job as designers to be clear communicators- whether verbally or visually. Indi Young in her book Mental Models notes that we design types tend to flaunt the scholarly language. She suggests keeping an eye on this and returning such vague phrases as ‘Implement written culinary method’ to colloquial language, which would go something along the lines of ‘follow the directions on the back of the macaroni box.”

Design, much like life, does not have to be complicated.

Activity Theory, Goal-Directed Design, and you

There are several issues that are arising in my work projects, so I’m going to try to talk about the theories that are swirling around in the research world in order to puzzle out my own design dilemmas…

Lately I’ve been doing a little research on the best practice for researching and creating GUIs for software. One such method is goal driven design. It’s discussed in-depth by Alan Cooper in About Face, and is design based upon what goal the user is trying to achieve. Writing a script, finishing his tax return, creating a digital work of art; these are all goals that a user might desire to accomplish and use software to achieve. To Cooper, goals are a collection of activities, and activities are transient and change with time. Goals are forever. For example, it may be your goal to go to Montana. In the old days, that meant climbing in the wagon with the family for an arduous trip that may or may not include cholera and scalping. In modern times, getting to Montana might simply mean getting on a plane after being harassed by airport security. But the goal of heading to the hills of Montana- oh, that remains the same. The techniques employed by GDD include interviews, personas, user stories, and other methods to get to know the user in-depth. It is a process that is very user-centric, and strives to create exactly what that user wants.

On the other hand, there’s Activity Centered Design, which is based on Activity Theory. The cited article explains the theory, though I think it has some double speak that makes the theory more difficult to understand than it should be. Basically, an activity is a motivation which is composed of actions. Actions are guided by the activity, and that action is a culmination of operations. For example, if one wanted to build a house (activity), they would need to transport building materials to the work site (action). In order to complete that action, one would start by loading the truck (operation). Similiar to the scientific method, this process is an unconscious one. But, it is the basis for the previously mention Activity Centered Design (ACD).

Perhaps the happy medium between the two can be found in Designing for the Social Web by Joshua Porter. In it, he suggests focusing on the primary activity and asking ” what are people using your software doing?” I like this question a lot because it has the implied question of who the people are, without getting too entrenched in the details of personas.

Porter goes on to say that the focus should be on the primary activity the user is trying to finish, because while knowing your user is important, you should really hone in on the specific activity you’re supporting with your design. Ultimately, activities reveal the steps involved in people reaching their goals.

The underlying goal of all this theory and practice is to keep in mind the overall desire of the user without getting caught up in the small minutiae of technology. Because, in the end, the use of technology is merely a pragmatic exercise for the user- it is only the means to an end, and rarely do they marvel at its awesome UI. They only want to know what it can do for them, and how easily they can accomplish their goal with this software.

Adding to that, I think it’s important to keep in mind this note from Designing the Obvious by Robert Hoekman, jr.

“When you start imagining how a fictitious character would respond to a hypothetical situation using an imaginary interface, it’s probably time to put down your little plastic army men and crack open the sketchbook.”

Theory, and a process, are wonderful things to help you along. But at the end of the day you’re a user experience designer, not a novelist.