A cursory glance at my portfolio reveals my preoccupation with methods. I’m currently in the middle of my third course meant to instill methods of eliciting software requirements, usability aspects, work process breakdowns, and everything else HCI. And while I do love having more Methods in my toolkit, I’m learning very quickly what constitutes a good method, and I think it comes down to a tradeoff between formality and quality of information, with clarity of use being something of a confound.

The first bit is the obvious part that I picked up in the HCI Methods course. If a method doesn’t give you as much quality information, then it’s not worth being as formal about it: Get the worthwhile information and move on.

I thought it was cut-and-dried, but my Software Engineering Methods course has taught me otherwise. Enter Problem Frames. The idea behind Problem Frames is that the practitioner scopes out the problem by identifying real world domains and relevant interfaces or communications between them. By incorporating the requirement of the problem at hand, you can start to get a good grasp on a problem in less time than it would take to do a full round of Contextual Inquiries.

The trouble with Problem Frames is the way it’s written: strictly in prose, with figures occasionally interjected. Examples abound in the book, which is a plus, but it’s still missing something that I couldn’t quite put my finger on until my second run through Beyer & Holtzblatt’s Contextual Design. Not only do Beyer & Holtzblatt give examples of their methods, but they have grey box explicitly outlining how to do a method. When it comes to diagrams, every bit of notation is explained, as is every bit of text. They also give a step-by-step approach of how to complete the method.

I didn’t realize the importance of being so thorough until I was spent 30 minutes in a meeting yesterday where my group members argued about which direction an arrow should be pointing. Please understand the triviality of this situation - we all agreed on what was happening conceptually with the problem. We just didn’t agree which way the arrow should point to convey our meaning. Since Use Cases (the method of the moment) are so horridly inconsistent in style (one author finds 24 different ways of creating them), our only remedy was to erase the arrow all together and try to work around it using other notation.

Now, I am not the scholar who came up with Problem Frames, nor do I have any claim to Use Cases. I simply take issue with the fact that they are touted as formal methods when (1) they don’t have so much information to offer in the first place, and (2) there is no clear guide for the practitioner to follow in implementing it. Admittedly, the formality I perceive might just be the professors stressing the importance of everything they teach, but the fact remains: If the development team spends more time deciding how to use the method than actually using it, then they aren’t learning about the problem, which is what really counts.