November 2004  
Designing a Design Vision

One of my classmates was just asked in a job interview what his design vision was. It's a rather odd question, but strangely enough, one I've been asked before as well. Apparently, we designers are supposed to have vision. And since I have several interviews coming up myself, I should probably design one for myself in case I'm asked about mine.

Descending as I do from plumbers, factory workers, railroad men, coal miners, and potato farmers, I'm a fairly practical sort, so talking about vision seems a little quaint. I don't have no visions, guv'nah. I just do the work! I'm much more comfortable talking about the work and the process of design than I am about a design vision. Visions are ephemeral, work is tangible. And while I have my thoughts on what Interaction Design with a big I and a big D is and should be about, I'm not sure that constitutes a vision. A vision implies a picture of the end-state, and I'm too much of fan of chaos theory and design to be certain of those.

To me, a vision also implies bringing a lot of yourself into products, imposing your "vision" onto them. And while I certainly have an ego, I don't have a fixed set of things that I think every product should be. Each product should arise from its circumstances. In fact, I suppose that could be my design vision: design is about being appropriate. Creating the appropriate thing for the appropriate time and for the appropriate people.

Few of the things I've designed work, feel, or look the same. Although like every designer, I have my bag of tricks, I don't have much of a personal design style that I impose on my projects. I feel like that's not, erm, appropriate. The result of the design process should be products whose characteristics have sprung up organically from the research, examined and molded by the expertise of the designer.

Now certainly, I think some of my personality is going to influence the products I create (as I've written about before). And I don't think this is a bad thing. In fact, it's probably desirable. To paraphrase what Kevin Lynch said about cities, we don't want to make things that are alien to us. But we don't make things that are inappropriate (unless they are deliberately, disruptively so--sometimes the most appropriate thing is the least appropriate) just to fit a designer's vision. That's not ego, that's hubris. And while that can get you far, it can also cause some hellish things and events to be designed. Vision can be a dangerous thing.

So I'm going to stick with this appropriate thing for a while. It's a modest vision for individual products, but broadly a very powerful one, I think. If every tool, every experience, was appropriate for you, perhaps especially for you, the whole system of the world would be less frustrating, less cold, and less cruel.

Originally posted on Wednesday, November 24, 2004 | Link | Comments (1) | Trackback (0)

 

Help Where It's Needed

The pilot light of my boiler keeps blowing out, often at the most inopportune times. Like in the middle of the night. Since I live in a city where the temperature is currently in the 30s and 40s F, I've occasionally found myself in a very cold house.

Lighting the pilot light is a fairly simple procedure of about five steps. However, if, like me, you've seldom done this and are confronted with this massive metal box filled with gas, hot water, and electricity in a dark and cold basement, it can be an intimidating thing. Even for the son (and grandson) of a plumber like yours truly. But there, on the side of the boiler, right above where the pilot light and the ignition are: instructions. Clear, single line instructions on how to light the pilot light, with even an arrow pointing to where to stick the match. Thanks to these instructions, it can be done even in the dark.

How many products do we use that you can say such a thing about? Usually the documentation is in its own (easily-lost) booklet or an owner's manual, or tucked away on its own web page somewhere. That is, far away from where you are when you need it the most. I'd love a car with some diagrams and basic instructions printed on the underside of the hood. Or an application with some really fantastic help attached right to the pieces of functionality.

Yes, I know we're supposed to build products that don't need help files, and while that is a great goal, it's sometimes unrealistic, especially for things that are tricky but happen infrequently. And sometimes what is simple for one user (obviously a heating guy wouldn't need the instructions to light a pilot light), isn't for another (me). We should just be mindful of when and where we provide help. We don't want to be Clippy, but we also don't want to be that stereo manual that can never be found when we want to add a new component either.

Originally posted on Friday, November 19, 2004 | Link | Comments (0) | Trackback (0)

 

Follow the Money...then Destroy Them Too

Comment spam has gotten out of control here at O Danny Boy, so I've disabled most comments except on main pages. Please send me email if you want to comment on posts until I can figure out another solution.

But here's another solution (in addition to this one) to the spam problem: we typically try to prosecute or disable the spammers themselves. Why not implement the Bush doctrine of destroying those that harbor and fund evildoers? Go after the online casinos, the peddlers of online drugs and pictures of Hot Asian Girls directly. Spam the hell out of them. Fine them. Hack the living shit out of them. Make them stop. They abuse the common good, which, more than servers, routers, and clients, is what the internet really runs on.

Originally posted on Tuesday, November 9, 2004 | Link | Comments (2) | Trackback (0)

 

Role-Directed Design

One of the reasons designers do things like personas is to get into the head of the people they're designing for, to understand their goals. But as Marshall McLuhan told us 40 ago, people are focused on roles, not goals. And yet there's almost nothing about role-directed design, everything is about goal-directed design.

Which is not to say that GDD is faulty or wrong. Indeed, it's very useful in that it lets designers not get bogged down in the minutia of tasks, as we are wont to do. But GDD is problematic in that goals, especially long-term, big-picture goals, are difficult to determine and easy to get wrong. Indeed, some have moved away from the term "goal", instead focusing on the more tangible "intent." What does the user intend to do, not what is the user's goal (which might be very broad--too broad for use inside a particular project).

Maybe it would be good to start including some role information into our personas. Asking people not what their job titles are but what their role is, in an organization, community, or even household. And what role they'd eventually like to have. Since roles will likely have a cluster of tasks surrounding them ("I take the product specifications to the engineers"), the gap between the role people currently have and the role they want could be fertile ground for interaction designers.

This might be semantics, but could also be another means of design research.

Originally posted on Sunday, November 7, 2004 | Link | Comments (2) | Trackback (0)

 

Sick at Heart

Really the title of this post says it all. I am choked with anger and sadness.

Originally posted on Wednesday, November 3, 2004 | Link | Comments (3) | Trackback (0)

 

 

« October 2004 | Main | December 2004 »

 
Archives
February 2009
December 2008
November 2008
October 2008
September 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
 
 
  O Danny Boy is About Me, Dan Saffer, and has my Portfolio, Resumé, Blog, and some Extras. It also has the blog I kept of my graduate studies and ways to Contact Me.  
 
 
 
  Blog RSS Feeds
Blog Excerpts
Full Entries
Design Entries Only
Atom Feed
 
 
 
 
  Search