experience matters

Speaking of “method cards”, we had them at the IA Summit – by nForm – http://www.nform.ca/tradingcards/ – 2nd year in a row.

I believe methods are a great way to provide structure and focus, but I’ve often seen many people get caught up in the ‘process’ that they lose sight of the end objective/goal. Things often get overcomplicated and spontaneity / serendipity is lost. The end result is often too safe, stale and uncompelling to achieve any real results and it’s then back to biz as usual.

It’s important to embrace methods for the structure, but keep perspective and not become too rigid. It’s about balance – structure with the opportunity for a dose of whimsy.

I have often replied to questions regarding methods with “There are no rules, including this one!”. I am firm believer that the methods are in no way written in stone, isn’t that the whole point of the IDEO cards in any case? To make us aware of how flexible we can get while designing.

Design is not science and therefore to have a set formula just doesn’t work. Having said this however, I find it extremely hard to sell this idea of being flexible and adapting depending on the problem at hand. How do we communicate this? Just words aren’t enough unfortunately.

The problem is that these methods kind of become like buzzwords, something like “personas” or “wireframes” and its hard to convince people that those things might have worked in the past but are not applicable to the current problem.

To sum up, I feel that a lot of creative opportunities are lost in trying/forcing us to follow these “established” methods. Lets use them wisely, with discretion!

Hmmmm. I don’t get it.

I think Methods are Tricks or Techniques from the other side of Jared’s diagram (slide 19 from your link).

You should certainly ask yourself: why are we using this particular method? If the answer is “because we always use this method” than perhaps you should examine the underlying motivations.

Stringing Methods together in a particular order might lead you to a “process.” Stringing processes together to form an end to end solution framework gets you a methodology, and believing the methodology your follow is the only way to do things is Dogma.

Regarding intuition — how else do we draw conclusions/decisions from the methods we use as designers?

I’ve participated in a lot of user research and I can count on one hand the amount of times I felt like my conclusions were based on solid scientific method or statistically significant findings. Am I alone?

The danger of course is that there is a thin line between intuition and rationalization.

As Jess McMullin pointed out in his talk, it’s really important to make a distinction between “methods” and “methodology.”

From Dictionary.com:
Usage Note: Methodology can properly refer to the theoretical analysis of the methods appropriate to a field of study or to the body of methods and principles particular to a branch of knowledge….In recent years, however, methodology has been increasingly used as a pretentious substitute for method in scientific and technical contexts, as in The oil company has not yet decided on a methodology for restoring the beaches….But the misuse of methodology obscures an important conceptual distinction between the tools of scientific investigation (properly methods) and the principles that determine how such tools are deployed and interpreted.

I believe that Jared’s point was that we need to move forward and let go of the rigid principles we’ve been upholding for no reason other than to say we have rules, when in fact they get in the way of progress and innovation. In its place, we acquire more tools (methods) and techniques, tips and tricks, to accomplish our goals in a “fuzzy” way. I think you’d agree that that’s a faster, and more fun, path to success.

Whitney,

I thought about that distinction quite a bit as I wrote this, which is why I pushed it farther from methodology to methods themselves. What I’m trying to point out is that even with a flexible “tool box” of them, we have to be careful not to fall in love with the tools themselves vs. what we can do with them.

Or even use the wrong ones.

Chris said:

“Stringing Methods together in a particular order might lead you to a “process.” Stringing processes together to form an end to end solution framework gets you a methodology, and believing the methodology your follow is the only way to do things is Dogma.”

Nicely put. In retrospect what I’m doing is going to the root. If dogma is the result of methodology which is the sum of specific methods then it’s worth examining the methods themselves. Why do we use them, when and how? And again, do we leave enough room for messy creativity?

The flipside of methods is mindfulness. It takes experience and maturity to know what to apply when. And just coz you have a swanky new method (a new toy) that might be applicable that doesn’t mean that it should be used.

I think Gary Klein’s work on expertise, intuition & patterns are important here: http://www.ara.com/offices/OH.htm

Dogma = Methods + Mindlessness

Useless Fact Moment: The root of the words “Technique” & “Technology” is the Greek word “techne” – which translates as both science AND art.

Not really, methods are useful waterfall is not.

“Dogma = Methods + Mindlessness”

Matt, I think that pretty much nails it. I guess like any tool, it’s how you use it that really matters. Guess I’m looking at this in a similar way that I view Flash. Really powerful tool in the box. Sometimes developers want to use it for everything. It’s about fitness to purpose I guess. And remembering that they are just tools—not the final product.

David

“The first question I asked myself was this. Could a fighter pilot boil down how they functioned into a neat and tidy set of methods? I doubt the answer is yes.”

The answer is, in fact, yes. They have a neatly boxed set methods called air combat maneuvers – here’s a list of the basic ones:

http://www.clowns-of-death.com/ACM.htm

Air combat training is focused on teaching these maneuvers so that they can execute them from instinct. Many pilots try create new air combat maneuvers in the hope of being recognized by name for their contribution.

Sorry – you’ve overextended the fighter pilot analogy.

Dave,

I’ve seen documentation on fighter pilot maneuvers. Think the best pilots follow them play by play?

You said

“Air combat training is focused on teaching these maneuvers so that they can execute them from instinct. Many pilots try create new air combat maneuvers…”

Are we leaving enough flexibility to create our own? No matter how unorthodox?

I’m not sorry. I think these questions are worth asking.

Chris, regarding the thin line between intuition and rationalization, I completely agree.

Too often I see big pieces of user/customer research that are not designed to provide insight, but instead validate what is already known. One of the things I get out of David’s argument is that we constantly need to be hyper-aware of why we choose an approach, and the risks we need to accept with that choice.

We’ve all done waterfall, and I’ve been on successful waterfall projects. The key was that the risk/reward ratio of that approach was known at the onset, and then the team was able to think effectively through the work with that model as the guide. Similar with design and design research methods, my take is that we need to be aware of the good and bad about each method before we use it. In the end it’s about knowing the method, applying it properly and using it to drive the intended results.

Methods aren’t waterfall, but if we don’t use them intelligently they could end up perceived as being as inappropriate in all cases just like waterfall development. The waterfall does work in certain contexts, but good luck convincing anyone of that who only has a cursory exposure to development processes.

I think the end goal for a practitioner should be a level of comfort with methods in general that allows them to “roll their own”. That’s a powerful capability that (IMHO) contributes to you to solving for the adaptability piece that we’re often seeking in contemporary design work.

Fighter pilots actually do follow the rules closely, especially early in their career. Nearly 90 years of air combat have proven that if you don’t get the basic air combat maneuvers right, you get shot down.

Notably, during the Second World War, the RAF had made the error of dispensing with their prior air combat tactic books assuming that they had little or no value in a battle involving the relatively high speed fighters of the time. They were wrong and their casualties in the air reached crisis proportions early in the war. During the Battle of Britain, a British officer named Douglas Bader re-introduced his own variations on air combat tactics from World War I, very successfully.

Perhaps, there’s an important allegory here.

Quoting his wikipedia entry: “Bader attributed his success to the belief in the three basic rules that had been tried and tested by earlier fighter pilots:

If you had the height, you controlled the battle.
If you came out of the sun, the enemy could not see you.
If you held your fire until you were very close, you seldom missed.”

These tactics are now standard air combat maneuvers that you might witness in movies, etc. The masters, of course, improvise, but their fundamental skill is build on the basic tactics and their special talent is how they link them together. You can see this “linking” in aerobatics displays. Very “chess-like”.
There’s a lot more to his tactical thinking and how he arrived at it than this, but I won’t bore you with the details.
However, the point of this is your opinion about process. I agree in principle, but you’re using very broad strokes. Personally, I view my HCD process to be more interpretative in the same way that one might compare jazz or jazz fusion to classical music. I have a theme that employ, I follow the rules of music theory, but I construct the process based on who I’m working with and pass the solo to whoever’s ready. I like the structure when I working with less experienced teams. I’m less tied to it when I have more experienced teams.
Sounds like nit-picking, but I have a thing for precision.

Actually, John Boyd (who I posted about the other day) reinforces this perspective. It’s his pattern library of maneuvers that pretty much every air force in the world uses today. The evolution of his worldview was the creation of the OODA loop, in which existing knowledge (methods) is one of the inputs into decision-making in the fly. It’s this on-the-fly capability (which methods feed into) which leads to fluid execution of the methods in an agile manner.

Dave,

I love the fact that you bring up Jazz as it’s probably a better analogy for what we do. A combination of discipline and improvisation. Jazz music is known for it’s musicians “riffing” of each other. But at this point, I won’t be surprised if someone digs up method cards for that too.

Some people think/learn/live vertically, others horizontally, most in combination. It’s not a matter of right or wrong. It just is. Those who function at the extreme ends of either spectrum are often labeled autistic. It is when vertical mandates horizontal as “truth”, or vice versa,
that process and methodology freeze-dry change.

Fingers = Eat = Method

Fork(Tool) = Eat (use) = Dogma

Fork (Tool) = Hair comb (use) = (not)Dogma

ciao, my friends,

betaBonnie

I have a philosophy background, which is non traditional to my mind and those I have encountered in the design field. Try to get a job in a climate that demands methods and methods training. The social climate proclaims that you “need” to go “get credentialed” at a place like ID.IIT.EDU first. Lack of methods seems to have become a reason to reject… reject others, reject ideas, reject newbies. Yes, it feels to me that methods have become a dogma.

However, doesn’t dogma give us what we all want to some level, security? There has to be some litmus test, right? “Informed Fuzziness” and “Structured Chaos” are not bankable. People don’t really want just the results of our work, they want the comfort and warm feelings of knowing what you’re going to do to solve their problem. That is how a deal gets papered, show them what you’re going to do and how it works on a spreadsheet. People don’t just need solutions, they also need emotional and psychological management when they are doing new things. Is that what methods are for designers?

Isn’t this, as Roger Martin describes the current right and left brain climate, a designers own “reliability” issue? Designers, the people who trumpet validity, harp on the left brain thinkers because they demand Reliability. However the designers themselves have their own reliability needs, e.g. methods.

So, how do you “gut-instinct” it when the structures around us and the ones we have created oppose it? Do you have to tear your own structures down first?

Check out Martin’s right and left brain concepts here: http://tinyurl.com/5ablf2 

Joseph,

Great thoughts here. I think you’ve validated why we need methods in a very honest way. Sometimes they are very effective in informing solutions and other times they are effective in helping people validate their own feelings.

BTW, I saw Roger speak twice at the Strategy conference. Great talk. On thing I always remember aside from his excellent visual is the fact that he wore sneakers to go along with his formal jacket and pants.

I dunno, symbolically that speaks to me.

[...] Abduction deals with a “method” (that should make the critics somewhat calm) in which a hypothesis if it were true would BEST Explain the relevant evidence regardless of methods. It starts by building a set of facts and infers explanations for them. Account planners have recently been batting around the value and use of “methods” in part provoked by this post. [...]

Wow. An amazing number of comments and an AWESOME article. And a much needed slap in the face right when I’m scrambling to tag and consume any new models mentioned at the MX conference that I’m unfamiliar with. So thanks for that! (as I order my IDEO cards… grin…)

One things is being discussed quite a bit here at the MX conference and that is innovation. But when I squint and peer around the edges, I see that we are really struggling with “fidelity” and “embrace the messy”. Identifying the fidelity by which we select and implement a method and ensuring we tackle those parts of the problems we are least experienced with or feel least up to the task of taking on. ie: having to select methods for those parts of the problems that are the messiest versus ignoring them.

I might so far as to suggest we ask the question at the start of any method selection, “If an experience is unique to the individual, then how can this be best represented in this case/model/process?”

I loved this quote and thought it quite pertinent to this conversation:

“The myth of methodology, in short form, is the belief that a playbook exists for innovation…”

Scott Berkun, The Myths of Innovation (by way of Kim Lenox of Adaptive Path)

[Scott Berkun's book rocks! It took me 2.5 hours to get through 25 pages because it generated so many new ideas.]

As I tweeted during the IA conference, there are specific ‘certifications’ known for instilling dogma in their unsuspecting, paying patrons. Such certifications are a ‘flag’ to me — to assess how much I have to ‘undo’ to make use of their skills. They want to use references as ‘checklists’, rather than as points to consider, based on the circumstances of the situation.

They are not taught to do real “design thinking”. But then one of my favorite stories to tell is one told by IDEO that I use as a classic example of what NOT to do (a case of redesigning a water bottle), becuase the team at IDEO never reframed the problem statement to its lowest common denominator — a true case of design arrogance.

Paula, & Sean

Thanks for these last two comments. I was really unsure about writing this one, but thoughts like yours help me with my own thought process.

Scott’s book is pretty solid.

[...] Experience Matters – Are Methods The New Waterfall? Comment: betaBonnie: “Fingers = Eat = Method / Fork(Tool) = Eat (use) = Dogma / Fork (Tool) = Hair comb (use) = (not)Dogma” Tagged: design PD [...]

[...] these questions and getting their UX teams to act on them. As a footnote to this I discovered this post by David Armano from the Critical Mass blog. Possibly related posts: (automatically [...]

This is pretty late-coming, but what a great post, and I wanted to add something I always liked as an application strategy for the IDEO method cards, from Brian Eno and Peter Schmidt’s 1975 Oblique Strategies.
(http://www.rtqe.net/ObliqueStrategies/)

From the second card in the deck:

“[These cards] can be used…by drawing a single card from the shuffled pack when a dilemma occurs in a working situation. In this case, the card is trusted even if its appropriateness is quite unclear.”

In other words, imo, methods are supposed to be used when messy creativity fails, and not before. Our brains all seize up from time to time. That’s why fighter pilots have a stock of maneuvers, jazz musicians have a stock of licks (http://jazzlicks.blogspot.com/), and restaurants have a book of recipes.

Because you’ve got to work /every day/.

Obviously, anything that makes that easier can become a crutch, qua Matt above.

Good perspective. As a design student i really admire this one since most of the times even in a design school where thinking is supposed to be free minded is rested between some sort of method. Such a method when superseded by any student in an effort to try new ways is mostly criticized.