Aaron Mooney — Fri, 13 Jun 2008 17:47:38 GMT

John,

Thank you for your comment and the request. I’ve found that when presented with a static wireframe deck, especially one with different design options or different task paths, clients can’t make the logical jump between interface selections and the associated effects, unless we provide a click-by-click page flow. Also, clients are not understanding that sometimes we need to present them design options within the same task flow, and they get confused when those different options are presented.

To help the client understand the different design options, or even different use scenarios, we may try to create a wireframe deck which walks clients through each separate scenario from the beginning. In order to do this effectively, we may need to duplicate wireframe pages before we get to where the scenarios or design options differ. The downside of this is that the wireframe deck becomes very large, and when printed by developers, they feel “overwhelmed” by the number of pages.

So given that some work environments are limited to a static presentation medium, I’ve come up with a method which may help clients make sense of the different scenarios and design options, and reduce the number of redundant pages for the developers. Gathering the information to create the roadmap can be quite tedious, so the code is intended to automate this tedious step.

Aaron Mooney — Wed, 18 Jun 2008 14:27:31 GMT

Chuck,

I find the topic and the description you provided intriguing. I may be working on a topic which is very similar. One of the struggles I have had is how to get project stakeholders to think outside of the screen, and to look at how users perform work while interacting with the tools in their work environment. I have been working on a method to help project stakeholders take environmental considerations into account, which should lead to a more usable interface. Does this sound similar to what you are working on?

Boxes and Arrows: Comments by Aaron Mooney