Could be a good model for going forward with the IA/ID application.
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: >>http://www.boxesandarrows.com/archives/the_devils_in_the_wireframes.php >>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 >documentation. > >-- >David B. Rondeau >Design Chair >InContext Enterprises >http://www.incent.com > > >_______________________________________________ >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) >http://interactiondesigners.com/announceList/ >-- >http://interactiondesigners.com/ -------------- next part --------------
An HTML attachment was scrubbed...