Comments on Straight From the Horse's Mouth with Dan Brown

alsat nerahat — Fri, 07 Jan 2011 21:21:05 GMT

Spurring teams to be more creative and innovative is probably one of the most important aspects of product development that most groups miss, but wireframes, flows, and site maps don’t work against creative ideation, they document it

alsat

Michael Beavers — Tue, 17 Jul 2007 19:42:49 GMT

Dan and Tom, thanks. You touched on this, but this is really about a balancing act between what a client needs (if you’re an outie) and their relative sophistication with reviewing and presenting different forms of documentation. Most people can review a wireframe and annotations, but very few people outside of engineering and IA get excited by it. At the same time, that document will often be critical for the build/execution of a given design.

If we are outside consultants, then there is a huge dependence on our client to sell the concept and the user flow internally. This has to be simple, elegant, and quick to the point so that a non-practitioner can present it convincingly. As a consultant/IA/ID, you will probably not be present at EVERY internal meeting. The dependency on the meetings, and your equipage of simple documentation to your client, is very high. Pushing the envelope with memorable documentation forms not only helps to innovate the field of UED, but gets its practices more quickly accepted by the broader business community.

laurie kalmanson — Thu, 19 Jul 2007 05:45:24 GMT

i think this is the short answer: it depends. i’ve worked with everyon from shops that have well-developed ui/ux/ia methodologies in place and just want a fresh eye or another pair of hands, to shops that were just starting to extricate themselves from the consequences of ready/fire/aim development cycles

much like the prospect of a firing squad, wireframes, user flows and site maps are wonderul devices for focusing attention when there’s more talking than decision making, and more concern for ship dates than what you’re actually shipping. the documentation makes it exactly evident what’s been thought through … and what hasn’t.

and, yes, those tools work for even the richest applications; a user interaction is still a user interaction, and it all comes down to what happens when someone clicks

that said, i am fine with inventing new forms of documentation for new challenges: annotated mock-ups with wireframing laid on top of ui designs for shops that insist on making pretty things before the structure is built, hybrids of many varieties, etc and so forth

i am agnostic re methodology: you can call it xtreme, agile, or my great aunt matilda; we still need to know what we have and what where we are going; ideally, before the coding begins

my .025.

Austin Govella — Mon, 03 Mar 2008 00:02:20 GMT

I think the distinction between innie and outie was important, but I didn’t understand how or why Tom insisted on positing his approach as the opposite of the more traditional approach. I’m not sure why he insists it’s turning the process on its head. Or why the process has a head.