Jeffrey Veen

I think whether you say "derived" or "inspired" by research depends on how you think of research :)

Not all research is performed by performing experiments using the scientific method; rather, much of research is -choosing- which experiments to do, at which point it becomes more like routine -- for your analogy, that's when you sit down and start implementing the design you've just come up with.

Great article, though; I think it expresses how many people go about their work, whether designers or researchers or where-ever you draw the line.

Could it be that taking in all that information leads to your brain forming specific paths and relating the information, out of which the idea emerges?

Hmm, some very good points. While doing a design for a client of mine, I got stuck. It was just dead. And it was too boring. I asked friends of mine what to do, but I got few replies that were actually useful (stuff like 'just drink a couple beers over it'). So I figured I'd do best in acting like I was looking for something, a role I easily forget--us web developers are pretty unlike the usual customer/visitor. After two days of doing research on my own, it dawned on me that I just wasn't thinking clearly. Back to the drawing board. Needless to say that it worked out well ;)

This is great stuff Jeff and very much in keeping with the approach I take.

I heard you speak at SXSW and you touched on a few of these thems on your panel and I made note of them. In particular I like the analogy to method acting.

I also attended Jason Fried's session and found that this method acting concept was missing from his model. I felt that Jason was on the right track but stopped short by saying "build something for yourself, or people like you, or build them the way you think you'd like them".

This works if you want to be a web developer developing for other developers, but might not be useful if you are building a site designed for seniors to archive war memories (for example).

Do you think that there is a need to formalize this "method acting" concept? I fear that many will look at it and say "I know what my users want because I'm empathetic, so screw researching stuff".

Ken, I do believe in the Method Acting approach. However, when we built Basecamp we didn't have to act because we'd been living the role for 6 years.

But, if you are building something you don't know much about, you should live in it to get a better understanding of it. This definitely works with our Getting Readl approach -- living in it is getting real. Readng about it and making assumptions based on what people *say* instead of what they *do* is not getting real.

It seems like the "method acting" approach works especially well when the target audience is specific and homogeneous. But for broader, more heterogeneous groups, it might become impractical. What happens, for example, when instead of just understanding the taxi driver, you also have to get inside the head of a plumber, a stock analyst, a physics professor, and a host of others? Just a thought.

"But for broader, more heterogeneous groups, it might become impractical."

Groups of users aren't always based on profession, age, gender -- often they can be defined by task. That is, all of those people are trying to Upload A Photo or Buy A Plane Ticket.

And what I find is that use cases, functional specs, and requirements documents are mostly useless to my design solutions. Those artifacts may list the various features that need to be in a product, but they do nothing to help me how those features should be organized, explained, and designed. I need to upload a photo on two dozen services, or hang out at Circuit City for an afternoon, or print out a bunch of Web apps and paper my wall with them...

Interesting. I think, though, that Gladwell would argue that you're actually doing yourself harm by going through all of those steps... particularly step 2. A large part of Blink argues that the mere act of even exposing yourself to every possible bit of information hinders your ability to make the right decision. In other words, you are more likely to make the right decision if you *only* know the few bits that are absolutely central to the question at hand.

I'm not saying whether or not I agree with this, but that's the thesis.

This is definitely how I design (websites, knitting, anything). Research, percolate in the background, pop.

About commercial proposals: I don't find that clients are really bothered by the stewing, as long as I warn them up front. It can work really well if you are booking ahead-- "I will be starting on your project (i.e., physical mockups) in x weeks, but let's do your needs analysis NOW so I can percolate in the meantime."

;_; I didn't read the book yet (I'm #9 on the waiting list at the library)

Would exposure to "every possible bit of information" cause indecisiveness?

Mike D is right -- Gladwell says that the best snap decisions are made when we don't have too much information. We need just the bits that are central to the problem we are trying to solve.

But I think there is a distinction (in general and in Blink) between information that comes as preparation and the information you are faced with at the time of the decision. In the original post, Veen says that the general and the art historian were able to make good snap judgements because they had a lot of preparation. Maybe Veen's step 2 is the preparation, but the actual design decisions are made in the presence of little information.

I'm the same. I sometimes write into proposals that I need to leave gaps for 'thinking time', which helps.

I think one of the bigger problems is how we teach others about this - it looks like a process, but it clearly isn't. If you don't have the background experience, there is no way that the answer will pop out ;)

This sounds similar to what I recall reading in John Cato's "User-Centered Web Design." He essentially outlined a process that was three steps, based on a previous designer’s method or statement on how “he” designs, may have been an architect, I don't recall specifically. But it's basically a higher level description of the iterative process we are all more or less familiar with.

This process begins with the discovery phase in which you study your subject, user/task analysis etc. and then before you move into your design phase you go through all of the data, analyzing it and so forth, then you chill, sit on all of the data, in order to allow yourself to absorb it, allow your subconscious to chow it down if you will. And then you begin the design process, this is often followed by a "eureka" moment, similar to the "blink" idea.

I think it's a great way to go. I often have my "eureka" moments when driving home sitting in traffic. It's one of the reason I stopped taking the train, the simple act of "driving" helps me think through concepts.

Anyway, thanks for reading, sorry for rambling.

Justin

I find that I work in a very similar fashion on creative projects -- (for me it's mostly writing and occasional web work and t-shirt art). One difference between us -- I have found that a little sleep goes a long way.

When writing papers for college, I would often compress the steps you outlined into a single nights' work, and despite my efforts would always fall asleep pre-epiphany, often with my face on my notes and books. Invariably, I would wake up several hours later, and just a couple of hours before the start of class without the aid of an alarm, and immediately start typing the essay. The papers turned out well, despite my hard to control methods.

Although the ideas generated under these types of scenarios arrive suddenly, the process is not quick. In fact, the passage of time is central to the process, which seems quite a departure from what Gladwell discusses. Although experience plays a role in Gladwell's examples, the judgment happens in seconds (or less). In the creative process you outlined, the judgment is similarly hard to define, but it is protracted and based on gathering a great deal of new information.

It seems to me that if we made snap judgments about site design without user research, based solely on our instincts and knowledge of past designs, that would be Blink design.

Blink is not all about "snap decision-making". For me, Gladwell does not suggest "less is more" approach like Barry Schwartz does.

For example, Pepsi Blind Test, Aeron Chairs - they show us that snap decisions (judgements) are wrong. These examples show us that when we judge something (or solve a problem or make a decision), we have to use more than one method (Spool's toolbox approach). Other thing is we cannot use one particular method for every problem. You might have to use different method depend on the problem and the situation that we might be in.

Yeah, I agree Melik, but I think a lot of what the book says isn't necessarily "snap decisions are always better than long deliberate decisions" but rather "a lot of times we think we are making deliberate decisions, we are actually making snap decisions, and in light of that, we should get as accurate as possible with our snap decision making".

Subtle difference, but an important one.

If I am not mistaken, it is the same colleague at Adaptive Path who every now and then shows people a slide featuring a cartoon where one researcher points at another researcher's scribbles on a blackboard, especially the "then a miracle occurs" part ("I think you should be more explicit here in step two").

Yes, this is a creative profession because there is an element of design in our work: we create a new solution to a new (or old) problem. The research, if done well, brings down the number of potential solutions and diminishes the size of the solution space, but there's still a creative process at the core.

I think the "derived from research" part comes into play when you evaluate and finetune the "blinked out" design using the results of the research.

Question: how often do you find an answer to a problem (an inspiration from a predicament) by jotting things down, making sketches, notes and the link? That is my usual source, but having a needs analysis completed allows me to check that my inspiration matches both what the customer expects and the end user NEEDS.

Peter, here's the cartoon you're making reference too:

http://www.acad.sunytccc.edu/instruct/sbrown/pic/miracle.jpg

Nice observations... and i think you've gotten to the crux of one of the challenges of interaction design..

Where i work (Cooper), we do loads of research, and while we endeavor to express the value of this to our clients, what i often tell clients and folks in the practicum is that going from problem to solution always requires a bit of a leap over the gap (the creative spark, whatev), and good research and analysis helps shrink that gap down to a mangeable size.

As many folks observe above, good research helps you know where to look and helps you recognize when you've found a good solution, and the Blink/Sources of Power comparison seems apt from my experience. If you sat in a design meeting staring at all your research (or Personas you've derived from the research), you'd end up like the Blue team...

And funnily enough, we use that New Yorker cartoon in our Practicum materials, too..

I've worked in many agencies in the past, big and small. In the bigger ones like the now defunct marchFIRST, design is often just the next step after information architecture, and the teams are split IAs vs. designers. I find that when given a stack of wireframes, I lack any of the research that the IAs may have done. There is no context nor opportunity for me to become the audience. I always try to get in on the research, but project managers and planners usually don't allow for that. And then I am stuck having just one or two days to do visual research and having to crank out 3 directions by the end of the week. Those designs usually aren't as good as I'd like them to be.

I have also had the chance to work on projects where I _was_ involved early on in the research and even participate in the IA discussions. Those projects always turned out very nicely.

Coming from an Architecture background, now in a Software Engineering profession. I find that the most successful solutions that I've come up with, have followed a very similar path (I just never get to sleep for 3 days afterwards).

You're right in that the stewing part is probably the most important. Basically design is a complex problem, no matter the domain. You've got an infinite number of variables (your research) that need to be used and assembled in some manner to formulate a solution. The act of stewing is really a matter making your brain understand the whole problem domain. Generally speaking, once the problem is fully understood, the act of 'cranking out the product' becomes very mechanical - simply because the problem has either become a series of simple/smaller problems with known solutions or your digestion has assembled a simplified variant of the problem. Often the solution that comes out of this methodology is generally simple, straight-forward, and often made up of a lot of common sense.

This is often why probably these solutions either succeed or fail. The final solution either is too narrow, due to over-simplification, too fragmented because of a piecemeal approach, or the problem domain is just never entirely fully digested and understood thereby giving way to a solution that is probably missing critical elements.

What about the part where you have to justify to the client how much all of this "stewing" is going to cost? Then the follow up - why they should pay you for your snap judgment? A body of work certainly helps, but what about the noobs to the field?

That's exactly the point, Seth. I have no idea how to quantify the time I spend "stewing." I'm off on my bike, cycling through the hills of Marin, while my mind churns away on the problem. I am working as actively as if I were at my desk poring over interview transcripts. But have you ever tried to justify that to a paying client? "I know I was at the beach, but I was thinking about your Web application!"

But the alternative is true too -- I may spend 90 minutes pounding out a solution after all that stewing. Does that mean I bill for an hour and a half, even though the problem has consumed me for three days?

The hardest part of consulting, for me anyway, is that I don't get to choose when I work on my client's problems. The inspiration comes to me in a way that I have yet to be able to control. And when you're charging an hourly rate -- well, it's tough.

I won't easily advise flat rate projects, though. Not unless you're an expert project manager. Flat rate projects require both a ton of experience in bidding as well as extremely honed client skills for keeping things under control. Else, you'll find yourself doing "one more version" of the docs until you're completely broke. So careful with that...

Thanks again for this great post, Jeff. It's got me thinking (stewing) about the creative process for days!

I've recently become hooked on the HBO show "Deadwood." In watching all the behind-the-scenes materials on the DVD, the cast and crew of the show extol the genius of the creator/writer/producer David Milch.

Normally in television series production, you have overriding story arcs from which you produce scripts for individual episodes. But Milch doesn't do that.

He outlines the beats for the characters, and then he writes the script on-set, reacting to what the actors are doing. Milch himself says that he likes to work this way because he feels that he's done all this research of the history of Deadwood, he has decades of series television writing experience, and that he wants to let the characters drive the story. He's done all his research and he lets his instincts take over.

I've been struggling with this same concept recently while writing 3-4 proposals in the last month. I've just settled on a flat rate around the amount of time I think it'll take to come up with a design decision and not scare of my potential clients.

Most of the time my stewing is done when I should be sleeping. Do I charge overtime for that? It seems to me the process is a lot more art than science most of the time. I find myself going through the same process while making music or painting.

I read something interesting the other day. It was along the lines of "sell the vision, sell the solution, not the process". That's what I've been trying to do lately, and it seems to be working well for me. Anyone else do this as well?

"sell the vision, sell the solution, not the process"?

I'd rather educate the client until he agrees with your vision, then sell the process and have the client figure out the solution.
That's what consulting is all about, if you ask me.

And yes, the education part is hard, and even harder to sell as part of a project (but well worth it!).
And yes, you are allowed to hold the client's hand while he figures out the solution (and that's worth money too).

I couldn't agree with JK's comments more. This is how I design at both my jobs, one doing infoviz/interaction design, the other doing graphic design. After I hear the problem for the first time, I can't just sit down and start churning away at it, I need to let my brain take in as much as it can before I start working. On graphic design problems, I have the best luck when I walk around the city with a camera and sketchpad, making notes of any cool patterns/textures/typography that I see. By the time I've walked home, the influences have meshed in my mind, and out pops the solution like a nicely browned piece of toast.

As a part time documentarian this is pretty familiar ground and nicely articulated for those of us who have a helluva time trying to explain ourselves.

Currently I am collecting about sixty hours of shooting for a feature length doc about a youth theater exchange. The process of arriving at the insight to what the material has most powerfully to say is to do the due diligance. Log all the tape with copious notes, added writing and mind mapping. Put lots of it on cards and pin up on the wall. Take anything and try out some cutting of a scene or two. Hate it. Fall in love with it. Likely hate it once again. Give myself a deadline to force the question. Then wake up when there is practically no time to get it all done, with a thirty second edit from disparate parts of the clip base which I think of as the lightning seed. Everything spins out from there into a film. It is all love again. Then comes finishing with all the tedium. But that is another mentality.

To the point of not taking in all the information - I think the issue is how we get access to the best sense of the work. One way is to overload ourselves with structured info. That is sub-optimal for me - surely it is a delusion/illusion that all the info which can be codified is really all the info.

The scarier path, as you have so well stated, is to trust that by using a little bit of juicy info to inspire us, get us raising questions, we charge up the collective unconscious and have access to something far richer, more three-dimensional, more passionately focused, and unencumbered by thinking and structure.

I still have to log all the footage. But I work with bright bits and wider impressions and use mind mapping and writing to charge up the void. Eventually, something pops out which seems to embrace insights that other people involved in the project have, without ever having mentioned them to me or written them in their blogs or notes.

While studying children learning to program, Seymour Papert and Sherry Turkle noticed different styles of approach to problems. They made a distinction between structured programmers and bricoleurs. I believe you're describing a design process similar to that of a bricoleur. I design (live) like this too. Its always a struggle to convince others to be comfortable with this sort of approach. It's not they way most of us were taught as an acceptable way to think.

http://www.bricoleur.org/archives/000033.html
http://home.cc.gatech.edu/je77/uploads/3/mbd-icls2004.pdf

I dunno, I think that sleep is an essential part of stewing.

That's really quite interesting. Thank you :)

I appreciate your honesty in presenting your method. When arguing for a particular position people are often most swayed by concrete examples but after all the data is consumed, it's not always easily accessible for presentation.

Why can't the SME merely be trusted to pull his/her own weight and given the green light to "make the call" without having to bring crucial documents to the bench or fear the repercussions?

Ok, rant done. Not that I feel better. ;^)

I actually wrote on a classic book on advertising called "A Technique for Producing Ideas" that follows a similar process. In fact, I'd be particularly surprised if Gladwell hasn't borrowed from it.

The only possible solution I've been able to find to shortening the painful part of the process has been to be constantly brainstorming and bouncing around ideas. Not ideal, but at least it keeps you in practice.

Since HTML seems to be stripped out, if you're at all interested in my summary, you can check it out here: http://www.thefantasticos.com/andrew/index.php/20/get-ideas/

Khoi Vinh, in his article The New New Methodology (http://www.subtraction.com/archives/2005/0316_the_new_new_.php) says it well when he writes:

"Of course, there's a caveat to this: to get to a position where a designer can begin almost immediate work on the final design and to be successful at it it helps to have deep experience doing things the long way. It takes someone who has been through the process of political deliverables, who has watched the pain of user testing, and who has accumulated a history of design successes and failures to be able to make instinctive decisions in short order"

Khoi speaks about starting with design before indulging in a lot of research, whereas you do mention user research performed specifically for the project at hand, but the 'blink' is apparent in both views.

So maybe it's not the stewing, but the experience? (that would make it harder to justify the time necessary to reach the 'blink' moment in a proposal...)