Distinction between visual and interaction design in wireframes Was RE:Prototypes as documentation?

31 Oct 2003 - 5:18am
846 reads
CD Evans

Dan Brown (greenonions.com) came up with a solution to this
wireframe/visual problem years ago and I commented on it in my book
'Usable Shopping Carts'.

I believe he calls them Page Description Diagrams (though I was
trying to call them Wireframes 2.0)

The basis is that they list the elements (as usable bits) on a
gradient of importance, and the visual designers take it from there.

It's a great model of Wireframing. There's more info on it here:


Could be a good model for going forward with the IA/ID application.

CD Evans

At 12:32 pm -0500 30/10/03, David Rondeau wrote:
>On Tuesday, October 28, 2003, David Heller wrote:
>>Are others finding themselves in the quandry that was expressed in a recent
>>article on B&A about how wireframes have become the final source of
>>documentation for design, engineering, and quality assurance?
>>Here's the link:
>>I know I am facing this problem.
>>How are people dealing w/ this? What do people think of Liz's solution?
>>-- dave
>I agree with the main premise of the article that wireframes should
>be simplified. One thing that I think is missing from the discussion
>though is "what are the wireframes being used for"?
>Are they being used to recommend that this "design" should be
>implemented? And more specifically that this "interaction design"
>should be implemented? Or are they being used to test the design?
>Are they testing the functions and concepts, the interaction, the
>visual design, or some combination? In any case, it is true that we
>must have the ability to separate the interaction design from the
>visual design (of look and feel).
>What I have been struggling with in my work, is this whole idea of
>separating interaction and visual design. We typically use
>wireframes as paper prototypes to test the concepts of our design
>with users before even thinking about visual design and even then
>only thinking minimally about interaction design. I would say this
>is the simplest state of wireframes.
>This minimal wireframe then evolves through successive prototype
>testing and iterations, until the interaction design is worked out.
>Of course this also means that *some* level of visual design must
>also be done. This would include things like fonts sizes and styles
>(e.g. Title headers are larger than other text and bold), screen
>layout (relationship of elements), and simple graphic elements to
>reinforce that layout (e.g. gray bars around headers to make them
>more prominent). I also think there are two levels of interaction
>design- interaction which is independent of time and interaction
>which is dependent upon time. But I think this can be saved for a
>later discussion.
>The final phase would be to then take the design which has been
>tested for function and interaction and then create a wireframe
>which can be delivered to the client. This is only done when the
>client does *not* want a visual design. Otherwise, a fully rendered
>visual design is created and tested, at which point it is no longer
>a wireframe.
>I find it difficult to cleanly separate out the visual
>representation of these three levels of design- function,
>interaction, and visual. In my experience, I find that information
>about the function and the user's work practice will affect the
>interaction and visual design. It will drive which UI widgets to
>use, how to lay out elements on a page (using prominence and
>relationship to reinforce the user's work practice), and how much
>information your user needs or can even tolerate on a screen.
>The visual design aspects of layout or information presentation (the
>prominence and relationship of elements, as mentioned above) must
>also be considered when creating the interaction design. How can you
>present or test the interaction of a design if the layout confuses
>the user, if items are difficult to find because they are not
>prominent enough, or if the relationship of elements goes against
>the user's work practice? I don't think you can. In these examples,
>I think interaction design and visual design are so tightly
>connected, I don't see how they can be separated.
>Of course there are other aspects of visual design that can be
>cleanly separated, such as the use of color to convey meaning and
>emotion. But what interests me is this space where visual and
>interaction design overlaps. Is this a different category of design?
>Does it make sense to dissect design in this way or should we just
>accept the fact that everything is intertwined and come up with a
>reasonable way to discuss and describe it?
>I think that if we can better understand this distinction, then we
>could create the right wireframe for the right purpose. If it is
>clearer what the different levels of design are (function,
>interaction, visual, and maybe something else?), how those different
>levels are perceived by different audiences, and what each one does
>and does not communicate, then we can gain the maximum benefit from
>the wireframe, whether it be for designing, testing, or as
>David B. Rondeau
>Design Chair
>InContext Enterprises
>Interaction Design Discussion List
>discuss at interactiondesigners.com
>to unsubscribe: discuss-unsubscribe at interactiondesigners.com
>Questions: lists at interactiondesigners.com
>Announcement Online List (discussion list members get announcements already)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.interactiondesigners.com/pipermail/discuss-interactiondesigners.com/attachments/20031031/cfd51c39/attachment.htm

Syndicate content Get the feed