I guess this level of design documentation *is new to the information architecture* field, *but it isnt at all new to those of us who have been designing user interfaces for (desktop) applications*. For us we’ve had to describe the interaction and workflows for complex forms (inter page, and page level) and complex interactions for direct manipulation tools and widgets for eons. I reccommend looking at how this has been done in the past.

The real challenge faced by RIA’s is that they have to blend web-centric patterns with desktop centric patterns.

Back to your storyboard convention. I like the bubbles you have as they indicate on the screen what’s happening. The only problem is that they dont clearly indicate the ‘order’ of events and are visually heavy. I suggest you number your bubbles, and only provide a light description of what you’re trying to show. Then below the wireframe create a numbered list for the bubbles and further desribe the interaction and maybe other thigns that need to be communicated (perhaps to the development community).

This way, you can lighten up the size of the bubbles (you may want to just display a number and title), and have a place to explicity describe the step in detail in the list below (or beside) the diagram.

No use re-inventing the wheel.

In the last couple of years, I’ve started building wireframes in Flash – with the annotations and prompts to guide the user. While its a bit more work than doing it in PPT or Visio, it begins to portray more accurately the tasks and flows in the application.

The next step for us is to make our prototypes more durable – prototyping in HTML/JavaScript, and iterating right there in the presentation code. We’re going to need to build a toolkit to make it easy to get going quickly – but, I’ve seen some good examples, linked from articles like this one: http://particletree.com/features/ajax-wireframing-approaches/

My mission is to give clients a more realistic view of the application earlier in the project (in order to iterate earlier and have a more valuable list of features) while economizing the efforts spent developing IA and controls…to create a more usable/accurate/mature handoff for engineering.

Thanks for showing us how you do your wireframes…looks pretty familiar. Good to know there are lots of folks doing valuable work.

Perhaps you can see why the developers may be having problems with the bubble versions of the wireframes. The steps are not clear.

I believe its a fallacy to think that you dont have to create formal design documents. We all know that nature abhors a vacuum. So these stories become the formal UI/UX design doc.

Balancing both audiences needs (Client & Developers) in one artefact is challenging because both are looking for (almost) completely different things. But it seems like you’re already creating two sets of documents (one with bubbles for your clients, and one without for your developers).

What you’re proposing works very welly to communicate the flow of your design to your primary audience. By incorporating the suggestions, you may be able add enough detail for your other audience (and formally recognize that your developers need more

Heres what I’m thinking… [http://www.culturesculpture.com/scrap/randomize.jpg]

Last point… powerpoint sucks for writing requirements, I suggest you stick to visio, and just add in navigation buttons to go from one page to the next (slideshow like functionality). When its time to do a slideshow, turn off the ‘requirements layer’, show your story to your client.

In the C/S desktop world, prototyping means windows forms on Visio and then wait three months to look at the pre-alpha to realize that everything was wrong.

Bubble and numbering are both ineffective ways to show micro connectivity — use the hell out links once the prototyping is done and dump it in your Garage web server and you have the pre-alpha version done for the idiot boss or visually impaired client… .

Just a little frustrated there– sorry… .

Excellent site for InfoVis designers and architects — learning a lot from comments of some very smart people….

In response to The Dashboard Spy: I haven’t had much luck designing on the fly with clients. Mainly because one change that we do on the fly might have up or down stream effects that we can’t think about right there on the spot. I see the value in what you are suggesting because it would reduce time – but only the short run. In the long run, it is better to take the time to think it through than to get people excited about something that might have issues as code begins to be written. Although, it might just work for pre-developed and designed products such as yours.