Boxes And Arrows : The Design Behind the Design

I think this is badly needed. Pragmatism demands that these documents be written with the assumption of some minimum level of “wireframe literacy” on the part of the reader. Little surprise that’s often absent among many of the key approvers. In the past I’ve provided a one-page primer on wireframes explaining their purpose and notation conventions, but this sounds more like an interactive guide. Very intriguing.

Aaron, when you say that it’ll include code, do you mean that the wireframes will be presented as scripted PDF’s?

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.

At the end of the day wireframes are about communicating ideas to various stakeholders and it’s certainly true that static wireframes can only go so far in doing this. I much prefer being able to present to the client personally, but all too often this is not possible.

Annotation is a start, and bulding interactive prototypes gives us new options, but in a way that may be very time-consuming. I have produced 50-60 page wireframe docs that contain a lot of redundancy in order to communicate ideas as clearly as possible. But is it necessarily true this is a ‘bad thing’ in itself? I have found developers welcome the clarity increased redundancy brings rather than feeling overwhelmed.

But I’m certainly interested to hear more, and ways of effectively and efficiently templating documents – or creating automated processes – to enable changes to be made once that update the whole document are certainly interesting.

I would find great use in this article. It would also me nice if the roadmap included a way to communicate the changes from a previous wireframe design to a new version and how best to document the changes made.