True or False: In a perfect world we'd all create html clickable wireframes after the static ones have been done

30 Aug 2007 - 6:42pm
6 years ago
28 replies
1405 reads
Akanowicz Ron
2005

Same format at (static) wireframes, but done in html with all
clickable navigation and intra-copy links leading to the appropriate
pages.

Ron Akanowicz
Usability Consultant
786-853-1666

ron at softerwareconsulting.com
www.softerwareconsulting.com

Comments

30 Aug 2007 - 7:33pm
Dave Malouf
2005

I think you assume a lot in that statement.
If I did wireframes as a first step I would agree w/ you, but often I
do interactive prototypes as a step before more definitional type
wireframes and often I don't do wireframes at all. I just keep
iterating in the interactive space.

-- dave

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=19952

31 Aug 2007 - 11:00am
Stew Dean
2007

On 31/08/2007, Akanowicz Ron <ron at softerwareconsulting.com> wrote:
> Same format at (static) wireframes, but done in html with all
> clickable navigation and intra-copy links leading to the appropriate
> pages.

Having done all different kinds of approaches, including this one, it
goes back to the old favourite of 'it depends'.

I have created a navigatable version of a site with copy and release
notes using Dreamweaver but only because we where working as close
team and with a limited time frame. I wouldnt say it had that many
advantages.

I have also created wireframe and sitemaps using flash and made them
clickable (something I first did about 6 years ago) - great if you're
again working in a close team and you are the only IA.

Both methods are good if you have the skills to throw around flash or
dreamweaver (mine have got rusty over the years).

Ultimately often a diagram is better than even a 'click through'
prototype as it communicates all the paths in the application rather
than have to have them discovered, after all one of the first things I
have done of the years when redesigning a site is to do an 'asis'
sitemap of the service so I know how it works, a clickable set of
wireframes without the right diagrams, explainations and overview
woudl be as useful as a having the final site, it woudl have to be
pulled apart again by anyone implimenting it to understand how it
works.

--
Stewart Dean

31 Aug 2007 - 11:05am
SemanticWill
2007

Idea to make money: Anytime one of us types "It Depends" we have to donate
$10 to IxDA :-)

On 8/31/07, Stew Dean <stewdean at gmail.com> wrote:
>
> On 31/08/2007, Akanowicz Ron <ron at softerwareconsulting.com> wrote:
> > Same format at (static) wireframes, but done in html with all
> > clickable navigation and intra-copy links leading to the appropriate
> > pages.
>
> Having done all different kinds of approaches, including this one, it
> goes back to the old favourite of 'it depends'.
>
> I have created a navigatable version of a site with copy and release
> notes using Dreamweaver but only because we where working as close
> team and with a limited time frame. I wouldnt say it had that many
> advantages.
>
> I have also created wireframe and sitemaps using flash and made them
> clickable (something I first did about 6 years ago) - great if you're
> again working in a close team and you are the only IA.
>
> Both methods are good if you have the skills to throw around flash or
> dreamweaver (mine have got rusty over the years).
>
> Ultimately often a diagram is better than even a 'click through'
> prototype as it communicates all the paths in the application rather
> than have to have them discovered, after all one of the first things I
> have done of the years when redesigning a site is to do an 'asis'
> sitemap of the service so I know how it works, a clickable set of
> wireframes without the right diagrams, explainations and overview
> woudl be as useful as a having the final site, it woudl have to be
> pulled apart again by anyone implimenting it to understand how it
> works.
>
> --
> Stewart Dean
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org
>

--
~ we

-------------------------------------
n: will evans
t: user experience architect
e: wkevans4 at gmail.com

-------------------------------------

31 Aug 2007 - 11:28am
Anne Hjortshoj
2007

Prototypes work best for demonstrating functionality to clients and
giving a real "sense" of the application, and paper/static wireframes
(or screenshots) work best for documentation.

Not every audience is going to be able to parse wireframes (we've all
had clients look blankly on as we present our beautifully rendered
documentation); not every developer or business analyst is going to
want to click through a prototype to dig out a functional spec.

There is no One True Solution. We're always going to have to do some work twice.

-Anne

On 8/31/07, W Evans <wkevans4 at gmail.com> wrote:
> Idea to make money: Anytime one of us types "It Depends" we have to donate
> $10 to IxDA :-)
>
>
>
> On 8/31/07, Stew Dean <stewdean at gmail.com> wrote:
> >
> > On 31/08/2007, Akanowicz Ron <ron at softerwareconsulting.com> wrote:
> > > Same format at (static) wireframes, but done in html with all
> > > clickable navigation and intra-copy links leading to the appropriate
> > > pages.
> >
> > Having done all different kinds of approaches, including this one, it
> > goes back to the old favourite of 'it depends'.
> >
> > I have created a navigatable version of a site with copy and release
> > notes using Dreamweaver but only because we where working as close
> > team and with a limited time frame. I wouldnt say it had that many
> > advantages.
> >
> > I have also created wireframe and sitemaps using flash and made them
> > clickable (something I first did about 6 years ago) - great if you're
> > again working in a close team and you are the only IA.
> >
> > Both methods are good if you have the skills to throw around flash or
> > dreamweaver (mine have got rusty over the years).
> >
> > Ultimately often a diagram is better than even a 'click through'
> > prototype as it communicates all the paths in the application rather
> > than have to have them discovered, after all one of the first things I
> > have done of the years when redesigning a site is to do an 'asis'
> > sitemap of the service so I know how it works, a clickable set of
> > wireframes without the right diagrams, explainations and overview
> > woudl be as useful as a having the final site, it woudl have to be
> > pulled apart again by anyone implimenting it to understand how it
> > works.
> >
> > --
> > Stewart Dean
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://beta.ixda.org/guidelines
> > List Help .................. http://beta.ixda.org/help
> > Unsubscribe ................ http://beta.ixda.org/unsubscribe
> > Questions .................. list at ixda.org
> > Home ....................... http://beta.ixda.org
> >
>
>
>
> --
> ~ we
>
> -------------------------------------
> n: will evans
> t: user experience architect
> e: wkevans4 at gmail.com
>
> -------------------------------------
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org
>

--
Anne Hjortshoj | anne.hj at gmail.com | www.annehj.com

31 Aug 2007 - 12:57pm
Andrei Herasimchuk
2004

Here was Henry Dreyfuss' answer to the question...

----------

Too much emphasis cannot be placed on the importance of three-
dimensional models. We come to this step after we have analyzed and
evaluated hundreds of designs and blueprints, trying to bring some
quality to the product that will make it easier to use without
increasing the cost, more pleasant to look at without any drastic
changes in the factory routine. When our ideas have been formulated,
we design in clay, then plaster, finally in a material that will
simulate the material to be used in manufacturing the actual product.
Wherever possible, such models are done in full size. In developing
the exterior of a train or a ship, accurate scale models must suffice.

The cost of a model is more than compensated for by future savings.
It not only presents an accurate picture of the product for the
executives, but it also gives the toolmakers and production men an
opportunity to criticize and to present manufacturing problems.
Models of some products can be made for a few hundred dollars. Full-
scale models of ship or train interiors can cost many thousands of
dollars. A mock-up of a modern passenger airplane cabin may cost
$150,000 but it will be worth it, for it permits engineers and
designers to develop techniques of installation that would not be
otherwise possible. Furthermore, sales executives can bring potential
customers into a faithful, full scale fuselage to see what it offers,
long before production begins. It is far more effective to sit in a
chair that judge its comfort by a picture of it.

Henry Dreyfuss, Designing for People, 61-62.

----------

Some key words to not overlook: He uses "accurate scale models" to
mean a models that reflects the real design, something wireframes can
never do in our line of work. Also, the toolmakers and production men
equate to engineers and developers for us.

As I've mentioned before, I think one has to build a functioning
prototype of what you design for any project. How we can make any
claim to being software or digital product designers if we don't do
the same sorts of things that so many designers in other fields do as
an assumed part of their craft?

If one lacks the skills to do so, either get back to school and learn
them, grab some books and dive in on, or get a bigger budget to hire
people who can help them build prototypes. Whichever path one takes,
I don't think one can ever underestimate the value and importance of
building functioning prototypes. Ever.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

31 Aug 2007 - 4:15pm
Victor Lombardi
2003

Andrei wrote:

RE>I think one has to build a functioning prototype of what you
design for any project...

Amen. Wireframes follow a workflow that architects use that is
inappropriate for what we do. As the Henry Dreyfuss quote
illustrates, industrial design is a much better metaphor. Industrial
designers have 'works-like' prototypes and 'looks-like'
prototypes, but non-interactive wireframes are neither, and lacking
vital usefulness.

RE>If one lacks the skills to do so, either get back to school and
learn them, grab some books and dive in on...

But that's hard! Or at least it has been. The thought of writing
code or wiring hardware is a threshold that's difficult to break
through for most of us, either because it's a different way of
thinking or simply a giant distraction from our core skills. But now
with recent versions of tools like Dreamweaver, Fireworks, etc. that
allow interactive prototypes to be generated from the beginning,
there's no reason to keep using static diagramming tools.

2007 should be the year the wireframe dies.

Furthermore, we would be well-served to work with technologists to
enhance tools that are almost usable by us (the Processing
programming language and Arduino hardware comes to mind) to put
designer-friendly interfaces on them, yielding the kinds of powerful
tools that technologists themselves have.

Victor

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=19952

31 Aug 2007 - 4:59pm
Dan Saffer
2003

On Aug 31, 2007, at 2:15 PM, Victor Lombardi wrote:

> Andrei wrote:
>
> RE>I think one has to build a functioning prototype of what you
> design for any project...
>
> Amen. Wireframes follow a workflow that architects use that is
> inappropriate for what we do. As the Henry Dreyfuss quote
> illustrates, industrial design is a much better metaphor. Industrial
> designers have 'works-like' prototypes and 'looks-like'
> prototypes, but non-interactive wireframes are neither, and lacking
> vital usefulness.

Really? In the world I live in, where I don't always get to hook up
prototypes to live databases and where I have neither the time nor
resources to build prototypes that replicate every use case I can
think of, wireframes are still important. Why? Because they can
document detail that a prototype, unless it is absolutely working
(which is to say, it is the final product) cannot. I can also link
decisions in a design to earlier decisions and show how logic flows
within an application in a way that is not apparent in a prototype.
Unlike analog objects made by industrial designers, the "works-like"
prototypes to demonstrate digital behavior are extremely challenging.
I'd argue that is what wireframes really are: the "works-like"
prototypes.

> there's no reason to keep using static diagramming tools.
>
> 2007 should be the year the wireframe dies.
>

Actually, there are a lot of reasons. Paper has been shown time and
time again to be an excellent communication tool. The time it takes
to diagram (and revise that diagram) on paper is considerably less
than the time it would take to mock it up (unless we're talking some
really basic product). Paper is easily transportable and simple to
edit and draw on. On paper, unlike a prototype, I can document:

- Logic flows
- Constraints
- Conditional states and their triggers
- Changes to the design over time
- Notes on the hows and whys something is to be built to the
developers/engineers/industrial and graphic designers.

Paper documents can be read of sit beside my teammates as they
work to make my design a reality without forcing them to launch a
prototype and have to re-engineer it themselves from what they are
seeing. Wireframes show how a product is to be built--information
that can be used to build a prototype as well. But digital products
are no better than another product--and perhaps worse than analog
ones--in that you can't see what the constraints and specifications
are from simply looking at a prototype of a final product.

In my mind, wireframes and prototypes are two sides of the same coin.
Both serve different purposes and one shouldn't substitute for the
other, except in some cases. Both are important and I'd never confuse
one for the other, or substitute one for the other if I could help it.

Dan

ps. I do know that there are some people who do hybrids--mixing a
prototype with annotations. That is kind of cool.

31 Aug 2007 - 7:04pm
Andrei Herasimchuk
2004

On Aug 31, 2007, at 2:59 PM, Dan Saffer wrote:

> Really? In the world I live in, where I don't always get to hook up
> prototypes to live databases and where I have neither the time nor
> resources to build prototypes that replicate every use case I can
> think of, wireframes are still important.

That sounds more like a problem of technology as it stands today, and
should not be used to dismiss the need to create prototypes. I deal
with the same thing. I have to often get creative and it's a pain,
but that's just the way it is. But it's simply a hurdle, not a reason
to negate the purpose and outright necessity to build a functioning
prototype in some form or fashion.

> Actually, there are a lot of reasons. Paper has been shown time and
> time again to be an excellent communication tool. The time it takes
> to diagram (and revise that diagram) on paper is considerably less
> than the time it would take to mock it up (unless we're talking some
> really basic product). Paper is easily transportable and simple to
> edit and draw on.

I'm not suggesting that paper or wireframing is useless and should be
tossed away. We still do all of that on our projects. Dreyfuss wasn't
saying that either. In fact, the relevant part of the quote is at the
beginning:

"We come to this step *after* we have analyzed and evaluated hundreds
of designs and blueprints..." [Emphasis added.]

He states clearly this is the part of the design process that comes
after the other parts. The problem I have is that too many people in
our craft stop cold at the paper part of the process and never
proceed to the next step. As Victor pointed out, this has as much to
do with the cost of building a prototype, the skills it take to
build, and the time it takes. All poor reasons to avoid attempting to
build a prototype in my opinion.

Again, to quote Dreyfuss:

"The cost of a model is more than compensated for by future savings. "

In my experience, this is 100% true. While prototypes seem expensive
(both in the amount of time it takes to build them and the financial
expenditure to invest in them) they absolutely save over the entire
course of the product's lifecycle. Including the amount of time
things take to design and build.

> In my mind, wireframes and prototypes are two sides of the same coin.
> Both serve different purposes and one shouldn't substitute for the
> other, except in some cases. Both are important and I'd never confuse
> one for the other, or substitute one for the other if I could help it.

They aren't two side of the same coin. One comes before the other,
but neither replaces the other. Paper and wireframing and all that is
the same in other design professions. Fashion designers do lots of
sketches (Project Runway anyone?), architects paint or draw buildings
in an environment as conceptual sketches to a get a idea of the
building in context, movie directors storyboard, industrial designers
do many concepts sketches and blueprints before they ever enter the
prototype stage. And they all do it for the same reason we create
wireframes and use paper sketching: It's fast and you can iterate
very quickly at the front part of the design process.

But once you get past the paper part, you have to get into the
prototyping part. All other design crafts build prototypes. I think
it's about time we stop tossing out all sorts of logical reasons why
so many of us don't and just own up to that is where the field is
headed and start making it happen. The more our field keeps avoiding
this issue and doesn't tackle it head on, the more we will continue
to deal with issues that put us as an afterthought in the digital
product design process.

"Too much emphasis cannot be placed on the importance of [functioning
software prototypes]."

In fact, Dan, I'd love to see you to take your Charmr project to the
next logical step. Prototype it! If you can't get the hardware
technology in place to make a prototype work, then get creative and
find something that approximates the experience of using it day to
day. Prototyping the software side of the Charmr isn't that hard
though, so I think you'd have a good chance there to make that part
work. But find some way to build something and get people to use the
prototype for a few months and figure out how the thing really works
and what needs to be tweaked. The Charmr is an excellent product
idea, extremely well researched, with great visual and excellent
interaction design. It's begging you to sit down and make it. Yes, I
mean the Charmr is sitting there, drawn out on the posters on your
wall and it's saying...

"Dan! Prototype me! You know I'm worth it!" 8^)

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

31 Aug 2007 - 7:29pm
Elizabeth Bacon
2003

TRUE! I am dying for more IxD prototyping! The paper wireframe/mockup
can only go so far when it comes to communicating digital systems to
large groups of developers & business stakeholders. Especially if you
have any questions of performance, evaluating the impact of time on
the interaction...nothing but an active system will do. And usability
testing really necessitates an interactive prototype when there are
tough questions of workflow involved. Although visual responses and
impressions are valid research on the mockup/wireframe level, what
people say and what people do just don't necessarily align.

I'm excited by some technologies like Ruby, a dynamic programming
language may make code comprehensible to the non-programmer. I never
ever wanted to write code, but I am working on being more capable
when it comes to prototyping. Thankfully I have a partner who's an
engineer! We are looking at the possibilities of going from Fireworks
-> Flex, in the future. Clickable HTML wireframes can be pretty
sweet, though, just by themselves.

Although, in direct answer to the stated question, I think it's kind
of perfect if I personally could stick to the IxD, and somebody else
could build the prototype. :) But bring on the tangible interaction!

Cheers,
Liz

> On Aug 31, 2007, at 2:59 PM, Dan Saffer wrote:
>
>> Really? In the world I live in, where I don't always get to hook up
>> prototypes to live databases and where I have neither the time nor
>> resources to build prototypes that replicate every use case I can
>> think of, wireframes are still important.
>
> On Aug 31, 2007, at 5:04 PM, Andrei Herasimchuk wrote:

> That sounds more like a problem of technology as it stands today, and
> should not be used to dismiss the need to create prototypes. I deal
> with the same thing. I have to often get creative and it's a pain,
> but that's just the way it is. But it's simply a hurdle, not a reason
> to negate the purpose and outright necessity to build a functioning
> prototype in some form or fashion.
>>

31 Aug 2007 - 8:22pm
Dan Saffer
2003

On Aug 31, 2007, at 5:04 PM, Andrei Herasimchuk wrote:

> But it's simply a hurdle, not a reason
> to negate the purpose and outright necessity to build a functioning
> prototype in some form or fashion.

I agree with you. Wireframes don't replace a prototype.

>
>> In my mind, wireframes and prototypes are two sides of the same coin.
>> Both serve different purposes and one shouldn't substitute for the
>> other, except in some cases. Both are important and I'd never confuse
>> one for the other, or substitute one for the other if I could help
>> it.
>
> They aren't two side of the same coin. One comes before the other,

Actually, for me, they are, as I find that one (wireframes)
instigates the other, then the prototype influences the wireframes
and round and round it goes. Ideally, at the end of the design
portion of the process, I would have both a set of wireframes and a
working prototype. Possibly several prototypes and certainly several
revisions to the wireframes.

> But once you get past the paper part, you have to get into the
> prototyping part. All other design crafts build prototypes. I think
> it's about time we stop tossing out all sorts of logical reasons why
> so many of us don't and just own up to that is where the field is
> headed and start making it happen. The more our field keeps avoiding
> this issue and doesn't tackle it head on, the more we will continue
> to deal with issues that put us as an afterthought in the digital
> product design process.

We are in violent agreement. But I don't think it's a question of
tools, but one of will. We have plenty of tools to prototype now,
from Flash to foamcore. Waiting for some supertool that will build a
prototype for you is a waste of time. I've built crude prototypes as
animated gifs, for heaven's sake. The tool almost doesn't matter--the
ability to demonstrate timing, animation, screen flows, and
connection between controls and display is what is most important. As
I am fond of saying, "The poor workman blames his tools."

> In fact, Dan, I'd love to see you to take your Charmr project to the
> next logical step. Prototype it!

We're trying to. We're looking for/talking to partners--either
industrial design firms or medical device companies--to take the next
steps with it. Ensuring the medical part (which is to say the
industrial design and mechanical engineering part) is feasible is the
next priority. Which of course means prototyping.

Dan

31 Aug 2007 - 9:24pm
SemanticWill
2007

Prototyping for thick clients as opposed to wireframing in html are
two very different beasts - timewise, cost wise and resource-wise - a
college intern with most of their frontal cortex intact could
prototype an html interactive prototype from paper wireframes in
little time at little cost. In the real world - that is the world with
limited budgets, limited time, and limited resources where most of us
are just happy they have actually budgeted for IAs and IxDs to begin
with - prototyping a thick client application is very difficult to
justify. In my company we could - could - and maybe even will -
prototype in WPF for .Net3. And if we do this - the real world will
slip back in and that prototype will get tweaked and shipped as a
beta. Thats just the way it is. Product managers have deadlines to
meet - development managers will be loath to give up some developers
to work on prototypes that are throw-away, even though that is what
prototypes should be - and no one will give IxDs the 3-6 months to
learn xaml/wpf + c# necessary to do the prototypes themself. Sorry to
rain on the parade of theoreticians and consultants that like to posit
platonic ideas about how we should design and develop software on Mt
Olympus. Some of us have to design, build and test in the real world
limited by money, time and resources.

On 8/31/07, Dan Saffer <dan at odannyboy.com> wrote:
>
> On Aug 31, 2007, at 5:04 PM, Andrei Herasimchuk wrote:
>
> > But it's simply a hurdle, not a reason
> > to negate the purpose and outright necessity to build a functioning
> > prototype in some form or fashion.
>
> I agree with you. Wireframes don't replace a prototype.
>
> >
> >> In my mind, wireframes and prototypes are two sides of the same coin.
> >> Both serve different purposes and one shouldn't substitute for the
> >> other, except in some cases. Both are important and I'd never confuse
> >> one for the other, or substitute one for the other if I could help
> >> it.
> >
> > They aren't two side of the same coin. One comes before the other,
>
> Actually, for me, they are, as I find that one (wireframes)
> instigates the other, then the prototype influences the wireframes
> and round and round it goes. Ideally, at the end of the design
> portion of the process, I would have both a set of wireframes and a
> working prototype. Possibly several prototypes and certainly several
> revisions to the wireframes.
>
>
> > But once you get past the paper part, you have to get into the
> > prototyping part. All other design crafts build prototypes. I think
> > it's about time we stop tossing out all sorts of logical reasons why
> > so many of us don't and just own up to that is where the field is
> > headed and start making it happen. The more our field keeps avoiding
> > this issue and doesn't tackle it head on, the more we will continue
> > to deal with issues that put us as an afterthought in the digital
> > product design process.
>
> We are in violent agreement. But I don't think it's a question of
> tools, but one of will. We have plenty of tools to prototype now,
> from Flash to foamcore. Waiting for some supertool that will build a
> prototype for you is a waste of time. I've built crude prototypes as
> animated gifs, for heaven's sake. The tool almost doesn't matter--the
> ability to demonstrate timing, animation, screen flows, and
> connection between controls and display is what is most important. As
> I am fond of saying, "The poor workman blames his tools."
>
> > In fact, Dan, I'd love to see you to take your Charmr project to the
> > next logical step. Prototype it!
>
> We're trying to. We're looking for/talking to partners--either
> industrial design firms or medical device companies--to take the next
> steps with it. Ensuring the medical part (which is to say the
> industrial design and mechanical engineering part) is feasible is the
> next priority. Which of course means prototyping.
>
> Dan
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org
>

--
~ we

-------------------------------------
n: will evans
t: user experience architect
e: wkevans4 at gmail.com

-------------------------------------

31 Aug 2007 - 11:15pm
Andrei Herasimchuk
2004

On Aug 31, 2007, at 6:22 PM, Dan Saffer wrote:

> Actually, for me, they are, as I find that one (wireframes)
> instigates the other, then the prototype influences the wireframes
> and round and round it goes. Ideally, at the end of the design
> portion of the process, I would have both a set of wireframes and a
> working prototype. Possibly several prototypes and certainly several
> revisions to the wireframes.

This is where we differ it seems then. I do everything I can to get
out of constantly updating wireframes once the prototype starts
reaching critical mass. I find maintaining wireframes and other types
of static deliverables to become more busy work when it's getting
addressed at the prototype level at a certain point in the design
process.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

31 Aug 2007 - 11:27pm
Elizabeth Bacon
2003

> Prototyping for thick clients as opposed to wireframing in html are
> two very different beasts - timewise, cost wise and resource-wise - a
> college intern with most of their frontal cortex intact could
> prototype an html interactive prototype from paper wireframes in
> little time at little cost. In the real world - that is the world with
> limited budgets, limited time, and limited resources where most of us
> are just happy they have actually budgeted for IAs and IxDs to begin
> with - prototyping a thick client application is very difficult to
> justify. In my company we could - could - and maybe even will -
> prototype in WPF for .Net3. And if we do this - the real world will
> slip back in and that prototype will get tweaked and shipped as a
> beta. Thats just the way it is. Product managers have deadlines to
> meet - development managers will be loath to give up some developers
> to work on prototypes that are throw-away, even though that is what
> prototypes should be - and no one will give IxDs the 3-6 months to
> learn xaml/wpf + c# necessary to do the prototypes themself.

Thanks for bringing this up! I was going to ask, do people here find
it hard to convince development to keep the prototype a prototype
when you're starting to use code that's theoretically shippable? I
mean, using a prototype language that's identical to the shipping
language. (But I didn't want my first email to dive into negatives.)
I think that there's a chicken-and-egg issue for product management
in that case, definitely...they feel that you have to refine the real
software instead of a prototype to justify the expense. And yet it
could be the prototyping process that really lets IxD get ahead and
support each iteration.

I've actually found that low-res prototypes are easier to justify in
very thick client situations. If the code is esoteric or dangerous,
then you have to step outside the build process to test it
conceptually. But that's my medical device experience talking!

> Sorry to
> rain on the parade of theoreticians and consultants that like to posit
> platonic ideas about how we should design and develop software on Mt
> Olympus. Some of us have to design, build and test in the real world
> limited by money, time and resources.

Design is design because it exists in the real world. I'm not on Mt
Olympus, though maybe I'm a tad jealous of those who reside there....

Cheers,
Liz

On Aug 31, 2007, at 7:24 PM, W Evans wrote:

>
>
>

1 Sep 2007 - 10:57am
Dan Saffer
2003

On Aug 31, 2007, at 7:24 PM, W Evans wrote:

> and no one will give IxDs the 3-6 months to
> learn xaml/wpf + c# necessary to do the prototypes themself.

Why do you have to prototype in the language it will be built in? I'm
sure that would be ideal (and occasionally necessary) and does work
well on the web, but for desktop apps, mobile, and devices, because
of the barrier to entry that the language/mechanics/materials cause,
it's often impractical. You just need to be aware of what the
language/mechanics/materials constraints are when prototyping in
another format/form. During development/pre-manufacturing you can
make any design choices that are caused by the building in the actual
language/materials.

> Sorry to
> rain on the parade of theoreticians and consultants that like to posit
> platonic ideas about how we should design and develop software on Mt
> Olympus. Some of us have to design, build and test in the real world
> limited by money, time and resources.

Looking down from Mt. Olympus on the real world, I have to say this
isn't theory. This is how I work, and I've been both a consultant and
in-house. If you don't think consultants suffer the same real world
considerations that in-house designers do, you are mistaken. The
constraints, in fact, are often worse, since we typically only get a
percentage of in-house's money and time, and we have to supply our
own resources.

Dan

1 Sep 2007 - 12:31pm
Dave Malouf
2005

Will, if I'm mistaken, from your writing above, it sounds to me like
you are not just in the design role, but also in the engineering
role. Is that correct? Are you responsible for implementing the GUI
into production code? Are your prototypes really just then early
iterations of the production code?

I think Dan and probably some others might be living in a world where
there is a thicker line between design and development/engineering
resources. I don't think this is something "high and mighty" and
exists both within in-house and within consulting avenues.

I think we have to realize that tools, methods and processes are
always going to be appropriate within specific contexts and not
within others.

There are good reasons for separating design & development processes,
but the workflow of the organizations we work in may not allow that.

There is also a auxiliary path being created by tools like Expression
Blend which either do 2 things: empower designers to create production
software GUIs, the same way Quark empowers designers to create
pre-press ready publications. But this still won't work in many
contexts as well.

I do think Will, the snarky remarks about theoreticians on high was a
tad, well, much. Just b/c a theory doesn't work in your world
doesn't mean it isn't being applied in other contexts successfully.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=19952

1 Sep 2007 - 1:49pm
Mark Schraad
2006

We prototype in odd assortments of html, axure, flash and even linked
pdf's. In the end we do hand over the css, but never really expect it
or our html to be used. But those files carry critical style, size,
color and positioning information that helps us to avoid excess
documentation.

BTW - while a grad student, we found that ID and IX folks were not
always motivated to learn a systems approach to design. They were,
however, anxious to learn css. In the end, they learned a lot about
the systems approach.

Mark

On Sep 1, 2007, at 11:57 AM, Dan Saffer wrote:

>> and no one will give IxDs the 3-6 months to
>> learn xaml/wpf + c# necessary to do the prototypes themself.
>
> Why do you have to prototype in the language it will be built in? I'm
> sure that would be ideal (and occasionally necessary) and does work
> well on the web, but for desktop apps, mobile, and devices, because
> of the barrier to entry that the language/mechanics/materials cause,
> it's often impractical. You just need to be aware of what the
> language/mechanics/materials constraints are when prototyping in
> another format/form. During development/pre-manufacturing you can
> make any design choices that are caused by the building in the actual
> language/materials.

4 Sep 2007 - 9:24pm
Todd Warfel
2003

Ah yes, the real world of prototyping.

This gets to one of the things, which should be done at the beginning
of prototyping - establishing goals. If you know the goal of the
prototype is to reuse it for production, then that drives the method
and tools you will probably use when prototyping. This is very
different from creating throwaway prototypes (different language than
production, less attention to detail and cleanliness in coding).

On Aug 31, 2007, at 10:24 PM, W Evans wrote:

> And if we do this - the real world will slip back in and that
> prototype will get tweaked and shipped as a beta. Thats just the
> way it is. Product managers have deadlines to meet - development
> managers will be loath to give up some developers
> to work on prototypes that are throw-away, even though that is what
> prototypes should be - and no one will give IxDs the 3-6 months to
> learn xaml/wpf + c# necessary to do the prototypes themself. Sorry
> to rain on the parade of theoreticians and consultants that like to
> posit platonic ideas about how we should design and develop
> software on Mt
> Olympus. Some of us have to design, build and test in the real
> world limited by money, time and resources.

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

4 Sep 2007 - 9:30pm
Todd Warfel
2003

On Sep 1, 2007, at 11:57 AM, Dan Saffer wrote:

> Why do you have to prototype in the language it will be built in?
> I'm sure that would be ideal (and occasionally necessary) and does
> work well on the web, but for desktop apps, mobile, and devices,
> because of the barrier to entry that the language/mechanics/
> materials cause, it's often impractical.

We rarely prototype in the same language the final product is built
in. In fact, in most cases we prototype and/or advocate using a
different language to emphasize the throwaway nature of the prototype.

Again, this depends on the goals established up front. If the goal is
to recycle, we'll do it in the same language.

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

4 Sep 2007 - 9:54pm
Jason Richardson
2007

I\'ve also prototyped in a different language and send it out to pasture after we move into development. That\'s why I think wireframes can be valuable, they\'re harder for clients/colleagues to get attached to whereas prototypes can cross the line into production. Additionally, I feel low fidelity wireframes can help keep people focused on the content, details etc rather then colors and graphics at this stage.

Also, anyone prototyping using rails? I tried out a usability study using Rails as the prototype and feel it has some benefits and wanted to see if anyone else has any thoughts.

28 Sep 2007 - 5:45pm
David Walker
2007

I agree that wireframes are useful. I also think that prototypes are critical if we are to advance our trade. I use my own wireframes to build working prototypes, because I need the discipline that comes from doing the wireframe. Prototypes are a lot of work and that work can be wasted if you haven't already put process behind it.
This is especially true if you are delivering XAML directly to a dev team. The XAML can be a prototype, but because it is also the actual design, wireframes help refine the vision before creating the XAML. Wireframes are a lot easier and it's just easier to toss my darlings into the wastebin and start over. If I go directly to the XAML, inevitably I invest too much and I try to hard to rescue early explorations from the cutting floor.
Dave

>-----Original Message-----
>From: Dan Saffer [mailto:dan at odannyboy.com]
>Sent: Friday, August 31, 2007 05:59 PM
>To: 'IxDA Discuss'
>Subject: Re: [IxDA Discuss] True or False: In a perfect world we'd all create html clickable wireframes after the static ones have been done
>
>
>On Aug 31, 2007, at 2:15 PM, Victor Lombardi wrote:
>
>> Andrei wrote:
>>
>> RE>I think one has to build a functioning prototype of what you
>> design for any project...
>>
>> Amen. Wireframes follow a workflow that architects use that is
>> inappropriate for what we do. As the Henry Dreyfuss quote
>> illustrates, industrial design is a much better metaphor. Industrial
>> designers have 'works-like' prototypes and 'looks-like'
>> prototypes, but non-interactive wireframes are neither, and lacking
>> vital usefulness.
>
>Really? In the world I live in, where I don't always get to hook up
>prototypes to live databases and where I have neither the time nor
>resources to build prototypes that replicate every use case I can
>think of, wireframes are still important. Why? Because they can
>document detail that a prototype, unless it is absolutely working
>(which is to say, it is the final product) cannot. I can also link
>decisions in a design to earlier decisions and show how logic flows
>within an application in a way that is not apparent in a prototype.
>Unlike analog objects made by industrial designers, the "works-like"
>prototypes to demonstrate digital behavior are extremely challenging.
>I'd argue that is what wireframes really are: the "works-like"
>prototypes.
>
>
>> there's no reason to keep using static diagramming tools.
>>
>> 2007 should be the year the wireframe dies.
>>
>
>Actually, there are a lot of reasons. Paper has been shown time and
>time again to be an excellent communication tool. The time it takes
>to diagram (and revise that diagram) on paper is considerably less
>than the time it would take to mock it up (unless we're talking some
>really basic product). Paper is easily transportable and simple to
>edit and draw on. On paper, unlike a prototype, I can document:
>
>- Logic flows
>- Constraints
>- Conditional states and their triggers
>- Changes to the design over time
>- Notes on the hows and whys something is to be built to the
>developers/engineers/industrial and graphic designers.
>
>Paper documents can be read of sit beside my teammates as they
>work to make my design a reality without forcing them to launch a
>prototype and have to re-engineer it themselves from what they are
>seeing. Wireframes show how a product is to be built--information
>that can be used to build a prototype as well. But digital products
>are no better than another product--and perhaps worse than analog
>ones--in that you can't see what the constraints and specifications
>are from simply looking at a prototype of a final product.
>
>In my mind, wireframes and prototypes are two sides of the same coin.
>Both serve different purposes and one shouldn't substitute for the
>other, except in some cases. Both are important and I'd never confuse
>one for the other, or substitute one for the other if I could help it.
>
>Dan
>
>ps. I do know that there are some people who do hybrids--mixing a
>prototype with annotations. That is kind of cool.
>
>
>________________________________________________________________
>Welcome to the Interaction Design Association (IxDA)!
>To post to this list ....... discuss at ixda.org
>List Guidelines ............ http://beta.ixda.org/guidelines
>List Help .................. http://beta.ixda.org/help
>Unsubscribe ................ http://beta.ixda.org/unsubscribe
>Questions .................. list at ixda.org
>Home ....................... http://beta.ixda.org
>

28 Sep 2007 - 7:15pm
SemanticWill
2007

Hi Dave,

So are you using MS Expressions Blend for your XAML prototyping? Have you
gone to a Remix07?

I think alot of people on the list are very interested in interactive
prototyping - and if you are using XAML pad, MS Visual Studio, or
Expressions Blend - I think alot of people here would love to hear about
your experience so far.

Could you write something up?

PS - for those in the Boston area - I can get you into Remix07 for free for
sessions on User Experience w/Silverlight and Blend (must be karma points I
accumulated somewhere). Just drop me an email.

--
~ will

IxDA Interaction 08 | Savannah
http://interaction08.ixda.org/
-------------------------------------------------------
will evans
user experience architect
wkevans4 at gmail.com
-------------------------------------------------------

On 9/28/07, davewalker at interfacevisuals.com <davewalker at interfacevisuals.com>
wrote:
>
> I agree that wireframes are useful. I also think that prototypes are
> critical if we are to advance our trade. I use my own wireframes to build
> working prototypes, because I need the discipline that comes from doing the
> wireframe. Prototypes are a lot of work and that work can be wasted if you
> haven't already put process behind it.
> This is especially true if you are delivering XAML directly to a dev team.
> The XAML can be a prototype, but because it is also the actual design,
> wireframes help refine the vision before creating the XAML. Wireframes are a
> lot easier and it's just easier to toss my darlings into the wastebin and
> start over. If I go directly to the XAML, inevitably I invest too much and I
> try to hard to rescue early explorations from the cutting floor.
> Dave
>
> >-----Original Message-----
> >From: Dan Saffer [mailto:dan at odannyboy.com]
> >Sent: Friday, August 31, 2007 05:59 PM
> >To: 'IxDA Discuss'
> >Subject: Re: [IxDA Discuss] True or False: In a perfect world we'd all
> create html clickable wireframes after the static ones have been done
> >
> >
> >On Aug 31, 2007, at 2:15 PM, Victor Lombardi wrote:
> >
> >> Andrei wrote:
> >>
> >> RE>I think one has to build a functioning prototype of what you
> >> design for any project...
> >>
> >> Amen. Wireframes follow a workflow that architects use that is
> >> inappropriate for what we do. As the Henry Dreyfuss quote
> >> illustrates, industrial design is a much better metaphor. Industrial
> >> designers have 'works-like' prototypes and 'looks-like'
> >> prototypes, but non-interactive wireframes are neither, and lacking
> >> vital usefulness.
> >
> >Really? In the world I live in, where I don't always get to hook up
> >prototypes to live databases and where I have neither the time nor
> >resources to build prototypes that replicate every use case I can
> >think of, wireframes are still important. Why? Because they can
> >document detail that a prototype, unless it is absolutely working
> >(which is to say, it is the final product) cannot. I can also link
> >decisions in a design to earlier decisions and show how logic flows
> >within an application in a way that is not apparent in a prototype.
> >Unlike analog objects made by industrial designers, the "works-like"
> >prototypes to demonstrate digital behavior are extremely challenging.
> >I'd argue that is what wireframes really are: the "works-like"
> >prototypes.
> >
> >
> >> there's no reason to keep using static diagramming tools.
> >>
> >> 2007 should be the year the wireframe dies.
> >>
> >
> >Actually, there are a lot of reasons. Paper has been shown time and
> >time again to be an excellent communication tool. The time it takes
> >to diagram (and revise that diagram) on paper is considerably less
> >than the time it would take to mock it up (unless we're talking some
> >really basic product). Paper is easily transportable and simple to
> >edit and draw on. On paper, unlike a prototype, I can document:
> >
> >- Logic flows
> >- Constraints
> >- Conditional states and their triggers
> >- Changes to the design over time
> >- Notes on the hows and whys something is to be built to the
> >developers/engineers/industrial and graphic designers.
> >
> >Paper documents can be read of sit beside my teammates as they
> >work to make my design a reality without forcing them to launch a
> >prototype and have to re-engineer it themselves from what they are
> >seeing. Wireframes show how a product is to be built--information
> >that can be used to build a prototype as well. But digital products
> >are no better than another product--and perhaps worse than analog
> >ones--in that you can't see what the constraints and specifications
> >are from simply looking at a prototype of a final product.
> >
> >In my mind, wireframes and prototypes are two sides of the same coin.
> >Both serve different purposes and one shouldn't substitute for the
> >other, except in some cases. Both are important and I'd never confuse
> >one for the other, or substitute one for the other if I could help it.
> >
> >Dan
> >
> >ps. I do know that there are some people who do hybrids--mixing a
> >prototype with annotations. That is kind of cool.
> >
> >
> >________________________________________________________________
> >Welcome to the Interaction Design Association (IxDA)!
> >To post to this list ....... discuss at ixda.org
> >List Guidelines ............ http://beta.ixda.org/guidelines
> >List Help .................. http://beta.ixda.org/help
> >Unsubscribe ................ http://beta.ixda.org/unsubscribe
> >Questions .................. list at ixda.org
> >Home ....................... http://beta.ixda.org
> >
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org
>

28 Sep 2007 - 7:32pm
Ari
2006

In a perfect world, yes, I would also employ prototypes as much as possible.
As others have mentioned, they are time-consuming for anything beyond very
simple or routine tools and modules - regardless of the application you use
to actually create them. This is especially true when you're dealing with
RIA or AJAX-enabled applications and different use cases.
I can point to personal examples where taking the time to develop a fairly
interactive prototype helped me find several flaws in my design and saved my
company $$$ in vendor fees by identifying problems before they hit
development. I can also point to situations where they could have just as
easily been mocked up in wireframes without sacrificing quality or losing
the intent of my interface.

On 9/28/07, W Evans <wkevans4 at gmail.com> wrote:
>
> Hi Dave,
>
> So are you using MS Expressions Blend for your XAML prototyping? Have you
> gone to a Remix07?
>
> I think alot of people on the list are very interested in interactive
> prototyping - and if you are using XAML pad, MS Visual Studio, or
> Expressions Blend - I think alot of people here would love to hear about
> your experience so far.
>
> Could you write something up?
>
> PS - for those in the Boston area - I can get you into Remix07 for free
> for
> sessions on User Experience w/Silverlight and Blend (must be karma points
> I
> accumulated somewhere). Just drop me an email.
>
> --
> ~ will
>
> IxDA Interaction 08 | Savannah
> http://interaction08.ixda.org/
> -------------------------------------------------------
> will evans
> user experience architect
> wkevans4 at gmail.com
> -------------------------------------------------------
>
> On 9/28/07, davewalker at interfacevisuals.com <davewalker at interfacevisuals
> .com>
> wrote:
> >
> > I agree that wireframes are useful. I also think that prototypes are
> > critical if we are to advance our trade. I use my own wireframes to
> build
> > working prototypes, because I need the discipline that comes from doing
> the
> > wireframe. Prototypes are a lot of work and that work can be wasted if
> you
> > haven't already put process behind it.
> > This is especially true if you are delivering XAML directly to a dev
> team.
> > The XAML can be a prototype, but because it is also the actual design,
> > wireframes help refine the vision before creating the XAML. Wireframes
> are a
> > lot easier and it's just easier to toss my darlings into the wastebin
> and
> > start over. If I go directly to the XAML, inevitably I invest too much
> and I
> > try to hard to rescue early explorations from the cutting floor.
> > Dave
> >
> > >-----Original Message-----
> > >From: Dan Saffer [mailto:dan at odannyboy.com]
> > >Sent: Friday, August 31, 2007 05:59 PM
> > >To: 'IxDA Discuss'
> > >Subject: Re: [IxDA Discuss] True or False: In a perfect world we'd all
> > create html clickable wireframes after the static ones have been done
> > >
> > >
> > >On Aug 31, 2007, at 2:15 PM, Victor Lombardi wrote:
> > >
> > >> Andrei wrote:
> > >>
> > >> RE>I think one has to build a functioning prototype of what you
> > >> design for any project...
> > >>
> > >> Amen. Wireframes follow a workflow that architects use that is
> > >> inappropriate for what we do. As the Henry Dreyfuss quote
> > >> illustrates, industrial design is a much better metaphor. Industrial
> > >> designers have 'works-like' prototypes and 'looks-like'
> > >> prototypes, but non-interactive wireframes are neither, and lacking
> > >> vital usefulness.
> > >
> > >Really? In the world I live in, where I don't always get to hook up
> > >prototypes to live databases and where I have neither the time nor
> > >resources to build prototypes that replicate every use case I can
> > >think of, wireframes are still important. Why? Because they can
> > >document detail that a prototype, unless it is absolutely working
> > >(which is to say, it is the final product) cannot. I can also link
> > >decisions in a design to earlier decisions and show how logic flows
> > >within an application in a way that is not apparent in a prototype.
> > >Unlike analog objects made by industrial designers, the "works-like"
> > >prototypes to demonstrate digital behavior are extremely challenging.
> > >I'd argue that is what wireframes really are: the "works-like"
> > >prototypes.
> > >
> > >
> > >> there's no reason to keep using static diagramming tools.
> > >>
> > >> 2007 should be the year the wireframe dies.
> > >>
> > >
> > >Actually, there are a lot of reasons. Paper has been shown time and
> > >time again to be an excellent communication tool. The time it takes
> > >to diagram (and revise that diagram) on paper is considerably less
> > >than the time it would take to mock it up (unless we're talking some
> > >really basic product). Paper is easily transportable and simple to
> > >edit and draw on. On paper, unlike a prototype, I can document:
> > >
> > >- Logic flows
> > >- Constraints
> > >- Conditional states and their triggers
> > >- Changes to the design over time
> > >- Notes on the hows and whys something is to be built to the
> > >developers/engineers/industrial and graphic designers.
> > >
> > >Paper documents can be read of sit beside my teammates as they
> > >work to make my design a reality without forcing them to launch a
> > >prototype and have to re-engineer it themselves from what they are
> > >seeing. Wireframes show how a product is to be built--information
> > >that can be used to build a prototype as well. But digital products
> > >are no better than another product--and perhaps worse than analog
> > >ones--in that you can't see what the constraints and specifications
> > >are from simply looking at a prototype of a final product.
> > >
> > >In my mind, wireframes and prototypes are two sides of the same coin.
> > >Both serve different purposes and one shouldn't substitute for the
> > >other, except in some cases. Both are important and I'd never confuse
> > >one for the other, or substitute one for the other if I could help it.
> > >
> > >Dan
> > >
> > >ps. I do know that there are some people who do hybrids--mixing a
> > >prototype with annotations. That is kind of cool.
> > >
> > >
> > >________________________________________________________________
> > >Welcome to the Interaction Design Association (IxDA)!
> > >To post to this list ....... discuss at ixda.org
> > >List Guidelines ............ http://beta.ixda.org/guidelines
> > >List Help .................. http://beta.ixda.org/help
> > >Unsubscribe ................ http://beta.ixda.org/unsubscribe
> > >Questions .................. list at ixda.org
> > >Home ....................... http://beta.ixda.org
> > >
> >
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://beta.ixda.org/guidelines
> > List Help .................. http://beta.ixda.org/help
> > Unsubscribe ................ http://beta.ixda.org/unsubscribe
> > Questions .................. list at ixda.org
> > Home ....................... http://beta.ixda.org
> >
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org
>

--
--------------------------------------------------
www.flyingyogi.com
--------------------------------------------------

29 Sep 2007 - 6:30pm
Michael Lisboa
2007

We never, ever, *ever* prototype in the language of the application
the product is developed in. in fact, we'll rarely go beyond image
mapping JPG images of schematics or visual design or, at the highest
fidelity, coded html or WPF/Silverlight/Flash. There's no point
really, because prototyping has limited usefulness in the big picture
of the design/development life-cycle and should be "throw away".

1) Testing. We'll build out prototypes for internal reviews, testing
and discussion as well as usability research.

2) Rapid/Agile UI prototyping (paper, schematic, or design) gives us
the ability to quickly work through complex task flows to solve
interaction problems.

3) Buy in. Prototyping is an excellent tool to get buy in from
clients and stake holders. Quickly producing a rough-around-the-edges
prototype to explain how we're solving a major interaction/usability
problem saves time and begets buy in from the business and
engineering side. Spending 30-minutes in Blend or Flash to show how
the application will fade, flip, wiggle or pop will get the client/
business team excited.

Michael Lisboa

30 Sep 2007 - 2:20am
Nicolas Cohen
2007

We use OmniGraffle for the wireframes, and sometimes use its hot spot
functionality, that allows to link any object to another canvas or
layer, or even a url,
With that functionality we are able to show most basic functionality.
We would love to have an export to flash feature there... but its
usually enough.

When complex interactions need to be demonstrated, we draw 2 or 3
steps and work with in-house javascript or flash developers to make a
prototype of just that feature.
In most cases that actionscript/javascript code probes to be really
valuable for developers of the final application.

We call this tests "tracer bullet" after the "The Pragmatic
Programmer" book (check http://www.artima.com/intv/tracer.html).
Usually this complex interactions change a lot through real testing,
and we also get to demonstrate that the solution poses no development
issues .

Nicolas Cohen
RANLOGIC
BA +(54 11) 4855 9371
http://www.linkedin.com/in/nicolascohentarica

1 Oct 2007 - 9:45am
.pauric
2006

Elizabeth wrote: "do people here find it hard to convince development
to keep the prototype a prototype when you're starting to use code
that's theoretically shippable?"

Let me answer your question with how I've been working for the last
5 years. Back in '02 we went through a redesign, created a
traditional wireframe to annotated webspec deliverable. The engineers
in turn gave me back the presentation layer -without- the underlying
db hooks.

Since then I have kept all major releases, product variants and
individual features in a shelf library.

When I have to design a new feature I wireframe the design and place
those screens in to the latest code. Engineers render that in to
code. I put it back on the shelf.

For new products I do the IA and edit the menu system to reflect the
design, then pull code off the shelf along with wireframe images
for new aspects. It gets rendered and goes back on the shelf.

This is all copy and paste, I cant code for crap.

I cant describe how much easier my job is when I have 360 degree
control of presentation layer. First I can fully mandate designs
through to release, secondly I can slice lead times to a fraction of
what they were when I did not own the presentation layer code.

Dan Saffer wrote: "I do know that there are some people who do
hybrids%u2014mixing a prototype with annotations. That is kind of
cool."

About a year ago I started combining flow diagrams with wireframes in
clickable pdfs, in omni of course. The flow diagram essentially
becomes a table of contents for mockup and explains the design in
more detail that annotations. There are simple annotations on
individual pages. All comments are on a separate layer which can be
switched off before export to pdf.
Here's a really simple/basic example, note that I dont need to try
to animate the map blind up/down, there's a link to the
http://wiki.script.aculo.us/scriptaculous/show/CombinationEffectsDemo
effects embedded in the pdf.

http://web.mac.com/pauric_ocallaghan/clickable_annotated_wireframe.pdf
For user testing, this isnt cool, for developers - no need to do
more.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the improved ixda.org
http://beta.ixda.org/discuss?post=19952

1 Oct 2007 - 10:54am
lois lewis
2007

HI all,
Glad we've picked up this thread again. I myself can't stand
writing long detailed specifications that are required for some thick
client apps but I am required to deliver those as a consultant.
Recently I started playing around with Axure - a rapid prototyping
too that allows me to wireframe, prototype and document at the same
time. I began my career as a visual designer so I tend to start
designs and interaction with sketches and work backwards to
documents. Ideally I'd get rid of the documents all together but I
know that won't work in many environments - I just interviewed a
bio-tech company that said the FDA required the 300 page doc - but in
the agile projects I do as a usability consultant I can start with the
interface and work backwards by using this tool - also it provides the
interactivity I need to do usability tests.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the improved ixda.org
http://beta.ixda.org/discuss?post=19952

1 Oct 2007 - 2:48pm
Dave Malouf
2005

Russell brings up an interesting foot note suggesting there might be
differences based on setting. Innie vs. outtie, but also
compliance-based vs. non-compliance-based.

But I would suggest that a new role in those settings should be at
play (new human being). Designers should not be documenting, but
communicating design. Documentation should be done by a writer. And
documentation and communicating design are not the same thing.

I really like the idea of the design communicator role from Cooper.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the improved ixda.org
http://beta.ixda.org/discuss?post=19952

1 Oct 2007 - 4:45pm
Jim Leftwich
2004

My responses to these posts below...

> From: dave malouf <dave at ixda.org>
> Date: October 1, 2007 2:38:52 AM PDT
> To: discuss at ixda.org
> Subject: Re: [IxDA Discuss] True or False: In a perfect world we'd
> all create html clickable wireframes after the static ones have
> been don
>
>
> Hi James, I find this interesting coming from you. Maybe, I'm just
> stereotyping here, but since your background is so intermingled with
> with Industrial Design I'm really surprised that you don't think
> that an interactive prototype isn't necessary, I mean, not as a
> communication tool, but as a design tool and a communication tool.
>
> The question that sprung to mind in this thread for me, is that I
> can't imagine any one of the IDs I would for NOT delivering an
> appearance model WITH their 3D digital assets (which btw are done in
> the same software that the mechanical engineers work in). So while it
> is completely "specified", many stakeholders and just for the
> purposes of design iteration need to see the appearance model.
>
> For people less connected to the ID world. An appearance model is
> practically indistinguishable from the final product when looking at
> it and touching it. Even the buttons work as prescribed. It just
> lacks electronics (even this is changing w/ the advent of cheap
> technologies). My favorite aspect is that it is usually weighted
> realistically as well.
>
> I just can't see how we can do our jobs as effectively w/o having
> these equivalent appearance models.
>
> One of the issues I see facing the IxDer long term is that we have
> taken the road of "director" instead of builder. Unlike most
> designers we actually don't build anything. We don't show the
> customer something that tells them, "Oh! so this is what I spent all
> that money on." I believe this is a huge evangelism failing of ours
> in our history and is something that we need to change in our "best
> practices" moving forward. Interactive prototypes are a key to this.
>
> -- dave

I think prototyping is very useful, and I've prototyped extensively
in product design. Back in the 1980s, it started with raw sheets of
plex and lexan and all-nighters on the milling machine and mixing up
hot bondo and painting, etc.. Nowadays we just sent files and get
back SLAs in a couple of days. I also still love to work with foam
models, studying the ergonomics of devices and finger and control
placement.

And as I said, I and my teammembers do have certain aspects of our
software and interface work prototyped, but our designs are simply
too large (an entire phone OS, with numerous applications, for
instance, and about five months to get it the design and spec in
place and underway). We're working closely with engineers most
times, and so we can actually begin to see the actual applications
taking shape.

Other times, it's simply from extremely short development timeframes
with systems and software that are very complex and detailed. Since
we're often developing and iteratively refinining the design and spec
on a very rushed scale, I can often talk to a flow and screenshots
and discuss the twelve ways we could do something, directly with the
engineer, with us both taking notes, and then determine which
alternative we like best (and fits) and go ahead and spec that out.

As for selling the design to the organizations, I've been in this for
a long time. Since the early 90s I've been working mostly with
Directors, VPs, and up, so they already know the background and track
record and level of results they can expect. I think designers
working down in the lower levels of organizations (and I see a lot of
disgruntled and frustrated designers in my client corporations), are
often thwarted in their efforts to innovate, and spend way too much
of their time trying to justify their designs.

It really is better nearer to the top. The truth is, and let's be
honest here, many, many organizations have layers of MarCom,
Usability, Designers, etc., and much of their efforts are spent
working on processes and critiquing and checking each others
efforts. Often this eats up months and months of time, and then lots
of times these products come out looking bolted together and
inconsistent, since they weren't guided by a single directing vision.

> From: dave malouf <dave at ixda.org>
> Date: October 1, 2007 3:17:38 AM PDT
> To: discuss at lists.interactiondesigners.com
> Subject: Re: [IxDA Discuss] True or False: In a perfect world we'd
> all create html clickable wireframes after the static ones have
> been don
>
>
> I see in Jim's email the piece about the level of detail in his
> specifications. Detail is important indeed.
>
> But I wonder if we had tools that were good enough so that the time
> and energy it took to do that level of specification is the same
> amount of time it would take to just build it, then we wouldn't need
> to specify it?
>
> Like the other David, I'm doing a project in Blend right now and our
> goal is to really concentrate more energy on building usable code than
> for creating documentation. Now since this is a 1.0 product, we'll
> see how it all pans out, but we already know that a standard designer
> with even basic Flash level programming skills isn't enough to get
> the level of code we need to truly do this hand-off the way we want
> (& now) need to.
>
> The tools themselves REALLY aren't good enough. Better visual or
> human language programming tools are really needed here.
>
> I should be able to create a state transition on click on a specific
> hot spot as easily in Flash or Blend as I could in powerpoint.
> Anything short of that and IMHO the tools fail.
>
> -- dave

This might be true. I just know that I wouldn't wait around until
the perfect toolset comes along. And so many of the projects I work
on are on all manners of platforms and operating systems (and
sometimes no operating systems at all - where we implement an
interface directly onto a chip).

> From: "Wilson, Russell" <Russell.Wilson at netqos.com>
> Date: October 1, 2007 8:50:00 AM PDT
> To: Andrei Herasimchuk <andrei at involutionstudios.com>, IxDA List
> <discuss at ixda.org>
> Subject: Re: [IxDA Discuss] True or False: In a perfect world we'd
> allcreate html clickable wireframes after the static ones havebeen
> done
>
>
> If one lacks the skills to do so, either get back to school and learn
> them, grab some books and dive in on, or get a bigger budget to hire
> people who can help them build prototypes. Whichever path one takes,
> I don't think one can ever underestimate the value and importance of
> building functioning prototypes. Ever.
>
> -----------
>
> I think we are slowly transforming the way software is created. I
> would
> guess that roughly 99% of software today is still created by taking
> some
> requirements, throwing them at a dev team, iterate some builds and
> change
> a few things, and then release. No design team. This is changing
> as users
> expectations are increased by software products that raise the bar
> through
> appropriate design processes. But at the moment, it is still very
> difficult
> to insert a design phase that includes the development of
> interactive prototypes
> and testing of those prototypes, as well as the resources to
> accomplish that.
>
> (Much easier for consultants and agencies who are contracted to
> create something
> and can follow whatever process they desire)

There are lots of good prototypers around these days, so it's gotten
a lot easier to bring someone onto a project to do interactive
prototyping.

But in our projects, it's really the larger issues such as the
business and organizational ramifications of major redesigns and
establishing the guidelines for future buildout where our greatest
efforts go.

And lastly, a great deal of our "design" work these days involves
looking for ways to incorporate technologies that do away with
interfaces altogether. The best interface is no interface
necessary. So any opportunities to build smarts and efficiency into
a device or system that cuts down on the need for user mediation is
always welcome.

I love prototypes, but I love getting the real product to be exactly
like it's been designed even more and our methods have served us well
in the conditions in which we've worked. I think that every designer
and design team must find the tools and processes that suit them best.

All building architects make models. But the model is not what is
down at the worksite. The architects, working with structural
engineers also create extensive blueprints, and then work with these
onsite with the construction crews until the building is finished.
This, more than any other analogy, matches my own experiences in the
product and software world. My work is almost entirely centered
around the extensively detailed blueprints. These aren't merely
lists, but are detailed screens, control layouts, and extensive flows.

But I'll underscore again the importance of finding ways to work with
or consult to the upper levels of companies. You'll find that you
can get much more done, and with less second-guessing by others. And
in our experience, you can achieve a much greater coherency of vision
and fidelity to your design in its real implementation. Whatever
methods you like to use to design and develop, you'll find it easier
if you're working at or coordinating with the executive level of
corporations.

Jim

-------------------------------
James Leftwich, IDSA
Orbit Interaction
Palo Alto, CA
jleft at orbitnet.com
http://www.orbitnet.com

Syndicate content Get the feed