Sanjiv Sirpal — Fri, 26 Jan 2007 14:52:48 GMT

Interesting article.

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.

Sanjiv Sirpal — Fri, 26 Jan 2007 14:52:49 GMT

More ramblings…

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.

Boxes and Arrows: Comments by Sanjiv Sirpal