September 1, 2004

Gordon Rugg and the Verifier Method

In the current Wired Magazine an article on Gordon Rugg - Scientific Method Man (yes, it is the same Gordon Rugg of card sorting notoriety). The article focuses on his solving the Voynich manuscript, actually deciphering it as a hoax. How he goes about solving the manuscript is what really has me intrigued.

Rugg uses a method he has been developing, called the verifier approach, which develops a means critical examination using:

The verifier method boils down to seven steps: 1) amass knowledge of a discipline through interviews and reading; 2) determine whether critical expertise has yet to be applied in the field; 3) look for bias and mistakenly held assumptions in the research; 4) analyze jargon to uncover differing definitions of key terms; 5) check for classic mistakes using human-error tools; 6) follow the errors as they ripple through underlying assumptions; 7) suggest new avenues for research that emerge from steps one through six.

One area that Rugg has used this has been solving cross-discipline terminology problems leading to communication difficulties. He also found that pattern-matching is often used to solve problems or diagnose illness, but a more thorough inquiry may have found a more exact cause, which leads to a better solution and better cure.

Can the verifier method be applied to web development? Information Architecture? Maybe, but the depth of knowledge and experience is still rather shallow, but getting better every day. Much of the confounding issues in getting to optimal solutions is the cross discipline backgrounds as well as the splintered communities that "focus" on claimed distinct areas that have no definite boundaries and even have extensive cross over. Where does HCI end and Usability Engineering begin? Information Architecture, Information Design, Interaction Design, etc. begin and end. There is a lot of "big umbrella" talk from all the groups as well as those that desire smaller distinct roles for their niche. There is a lot of cross-pollination across these roles and fields as they all are needed in part to get to a good solution for the products they work on.

One thing seems sure, I want to know much more about the verifier method. It seems like understanding the criteria better for the verifier method will help frame a language of criticism and cross-boundary peer review for development and design.



Posted Comments

I had the same thought when I read that article. If you happen to find out more about the verifier method, I'm sure all of us readers would appreciate a post about it.

Maybe you'll present on this at DesEng? It sounds appealing, but doesn't it seem kind of, er, hard? I don't quite see how it differs from "become an expert in a field, and figure what other experts have overlooked." Other than step 5, it's very hard to see how a committed but inexperienced outsider could really get this method to work. I'm not really convinced that it's a "method" at all, at least in the breif description of it in Wired.

Comments

Comments are closed.

This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License.