I would like to repectfully disagree with the rejection of added
realism as whole. I would like to split this argument in two: 1)
information architecture and over arching interaction design and 2)
activity or task design, layout and low level interaction design.
I am going to agree with Larry on number 1: information architecture
and over arching interaction design does not need a high fidelity
prototyping tool. I would even argue that is impossible to do since
you are still in an ideation and analyis phase. This is a where you
are trying to figure out the vision for the project. More on that later.
As part of the agile process I will speak of number 2: activity or
task design, layout and low level interaction design. In Agile
methodologies, high fidelity wireframes/ UIs are very useful. I am
making a few assumptions.
First, you (UI designer) are a customer/user surrogate and need to
represent the users and be intimate with their stories
Second, you have defined information architecture and over arching
Third, you have a well defined set of guidelines/ code for the UI
design catalogue. In other words, you know what widgets you are using,
the components they form, the collection of components, and standard
page templates from which you will be working.
Fourth, these guidelines should be part of the reusable code library
the developers are supposed to be factoring out.
Fifth, if you are working in HTML, you can use Dreamweaver and create
HTML and CSS snippets that are the same as what the developers use in
the code library presentation layer.
Sixth, any additional page or addition will take fractions of an hour
to mockup and attach with the other designs.
Now that my assumptions are out of the way, I can say that I have used
this successfully. This allows you to mock up UIs, interactions, data
and provide users with a clickable design in short time. This all can
be performed before iteration planning.
- the users give you input to iterate on
- you get a better understanding to represent the users
- you have the html that the product should emit (this could be one of
the tests development has to pass as part of acceptance)
The high fidelity wireframes give users a tangible tool to use to
explain what they need to do their work. If the activities/ stories do
not align with what you have done you can get feedback and iterate.
Two to three weeks later you can put the real code infront of them and
iterate again if needed.
My 22 cents (cost of inflation),
--- In email@example.com
, "Larry Constantine"
> I'm with David on this. Added realism may appeal to users and
> that does not make it a good thing in terms of driving the process
> faster or toward better designs. The main advantage of wireframe
> and other more abstract prototypes is that it allows working out
> issues of layout, organization, navigation, and interaction without
> introducing the complexities and distractions of details of
> behavior. This actually benefits users and other feedback resources by
> focusing their attention on the most important matters. It also serves
> designers by helping them get the big stuff right first before
> details of color-scheme, alignment, and the like. The design
> process is thus simpler, clearer, and much less messy. This
> may have other payoffs, as I have repeatedly seen the way abstraction
> actually inspires designers to innovation that leads to
> Whether it takes more time or less time to develop abstract
> figurative (representational) ones is partly a matter of practice
> a matter of available tools. ("Real" wireframes are, of course, just
> low-to-medium-fidelity prototypes--nothing revolutionary there.) Once I
> started using CanonSketch (a shareware abstract prototyping tool for
> OS), I was able to crank out usable canonical abstract prototypes
> formalized version of wireframes) in a fraction of the time. In many
> the next step after an abstract prototype can be the implementation,
> high-fidelity prototype.
> At LabUSE (my research lab at the University of Madeira), we are
> software tools that allow rapid construction of CAPs that will even
> behaviors, so designers can experiment with alternative interaction
> and users can actually try them out, again, without worrying about color
> scheme and the shape of buttons, etc. (We are making progress. No
> of talent but hampered by a shortage of funds.)
> --Larry Constantine, IDSA [mailto:lconstantine@...]