Next Time, What Say We

Next Time, What Say We Boil a Consultant: “Take a pot of hot water and a frog. Throw the frog into the pot. What do you think will happen? The obvious, of course: the frog will jump out. Who likes hanging around in a pot of hot water? Now … [t]ake a pot of cold water, put the frog in it, and place the pot on the stove. Turn on the heat. This time something different will occur. The frog, because of the incremental change in temperature, will not notice that it is slowly being boiled. Unfortunately, many organizations, as they grow, begin to resemble the boiled frog.”
Fast Company’s investigative team, the “Consultant Debunking Unit”, put the frog story to the test. ”

More hilarious stuff from Fastcompany’s Consultant Debunking Unit.

Charlie Brown writes about XFML:

Charlie Brown writes about XFML: “This looks promising for publishing meta data that can be used by other web sites and/or user client software. After reviewing the information on the site it does not appear that they borrowed anything from the Zthes DTD for xml representation of a thesaurus. It seems to me that creating linkages between the two could make both standards stronger. ” Good point – I’m looking into this for version 0.3 of the XFML spec.

RSS 1.0 Modules: Taxonomy: a

RSS 1.0 Modules: Taxonomy: a way of adding taxonomy information to an RSS feed, using RDF and DC. Interesting. I’m looking in to how this can be combined with XFML. Ah, I know: just use a link to an XFML document and add #topicname to identify the topic with the taxo:link element. There you go, done, we just combined RSS 1.0 news feeds containing the last x articles on a website with their (simple) metadata, with an XFML document containing the entire (more complex) metadata map of a website. Imagine the possibilities. You could automatically generate a list of related articles to these latest articles from the RSS feed combined with the XFML document.

I read professional XML Meta Data on the bus and now I think I’m finally starting to get this stuff. Recommended.

Cooper ( Interaction Design: “The

Cooper ( Interaction Design: “The aim of this exercise is to help us determine how well you might fit the Interaction Designer role. Your response should exhibit the strength of your design skills and your ability to communicate your design decisions. This test has two parts: one that tests your general interaction and interface design abilities, and one that tests your high-level product conceptualization abilities.” (via Webword) Patently Absurd. This is Patently Absurd. This is crazy.

“After IBM’s presentation, our turn came. As the Big Blue crew looked on (without a flicker of emotion), my colleagues–all of whom had both engineering and law degrees–took to the whiteboard with markers, methodically illustrating, dissecting, and demolishing IBM’s claims. We used phrases like: “You must be kidding,” and “You ought to be ashamed.” But the IBM team showed no emotion, save outright indifference. Confidently, we proclaimed our conclusion: Only one of the seven IBM patents would be deemed valid by a court, and no rational court would find that Sun’s technology infringed even that one.

An awkward silence ensued. The blue suits did not even confer among themselves. They just sat there, stonelike. Finally, the chief suit responded. “OK,” he said, “maybe you don’t infringe these seven patents. But we have 10,000 U.S. patents. Do you really want us to go back to Armonk [IBM headquarters in New York] and find seven patents you do infringe? Or do you want to make this easy and just pay us $20 million?”

After a modest bit of negotiation, Sun cut IBM a check, and the blue suits went to the next company on their hit list. “

More from the CHI-WEB archives:

More from the CHI-WEB archives:

“So you have to ask: how do other kinds of designers define “conceptual models”? If you look at how GUI designers document their designs, or architects their floor plans, you’ll see other ways to define and describe interaction, and define production. […] I’ve said before on this list that I think the definition of information architecture is dangerous in misguiding the focus of the real mission: helping people. The word “user” is gone, and the connection to the larger heritage of HCI is lost. “

CHI-WEB archives: (via Best of

CHI-WEB archives: (via Best of CHI and sigia-l)

“In summary, I think one key to success is to enable a very small set of folks to drive the design thinking. I would much rather have one product designer that has medium proficiency in information design, visual design, and interaction design, than three individuals each contributing only those independent perspectives. You want a small number of people to be able to go and iterate quickly, trying out lots of ideas without hoops, bureaucracy or design by committee, but balanced by input or contributions from all of the
disciplines you need.”

Usability Testing: You Get What

Usability Testing: You Get What You Pay For: “Also, if you have multiple distinct user categories, then you must test 6-8 of each type.”


She illustrates the point with a story of someone using developers to test a site. Now, I think most people know they shouldn’t use developers to test a consumer site, but the idea that your sample has to be part of your target audience when doing usability testing is wrong. It all boils down to how you’ve defined your target audience. Usually this is defined as the audience you want to reach with the website (the people that will make you money), which is not the same as the audience that you can do usability testing with, that’s usually a lot larger. I’m not saying you can test with anyone. But depending on what exactly you’re testing, you can do cheap and cheerful testing of generic interface properties with most people.

“i.e., have the same set of key characteristics, such as job experience level, computer experience level, age, gender, expected frequency of use, etc.) ” I mean, come on. How much difference will those characteristics make in most cases? That’s just wrong.

Defining your target audience is done for a purpose. Usually for marketing (who do we sell to and how?). The better developer does it again for design (marketing profiles don’t contain a lot of useful info when designing a solution). But 99% (a Nielsen-esque exaggeration) of usability problems can be uncovered by testing with almost anyone.

I guess it depends on the type of projects you work on. One of the examples shows “doctors, nurses, technicians and receptionists” – of course those are very specialized audiences and you should test with them. Again a bad example.

I just don’t like the tone of the article, the false examples, the “I’m an expert therefore I only can test” tone.

I think the flaw of the article is that the author seems to assume a “one time fix it all” type of testing, ignoring iterative design practices where you test things, say, three times a week. I’m all for in depth testing but it doesn’t mean quick and dirty testing is useless.