Distinction between visual and interaction design in wireframes Was RE:Prototypes as documentation?
30 Oct 2003 - 11:32am
David B. Rondeau
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
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
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.