Boxes And Arrows : The Design Behind the Design

Great Interview! Dan & Tom do a good job of illustrating some of the differences between External/Contract/Consulting efforts and Internal efforts. When you are a consultant you have to set certain expectations about what you’ll deliver even to the extent of what it will look like.

They’re going to be paying you by the hour so you have to be more prescriptive at the outset because you’ll use these examples to sell your services and gain the business. You’ll decide what examples to promote based on your assessment of the client’s level of interest and sophistication.

Dan’s comments also suggest that you have to assess their level of imagination as well. If they don’t understand a prototype but they can wrap their brains around a wireframe well…the prototyping tool goes back in the toolbox unless…after you’re engaged and you’ve learned more about the environment, you see an opportunity to get it out and sell the notion.

No single artifact is right for every client and every situation. You don’t get paid because you use a hammer, you get paid because you know whether or not to use it and where to hit!

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.

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.

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.

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.