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.
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.
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.
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.
Sick at Heart
Really the title of this post says it all. I am choked with anger and sadness.