What do your prototypes look like?

2 Jun 2008 - 10:41am
6 years ago
9 replies
771 reads
Oleg Krupnov
2008

Do your prototypes look like clickable wireframes or do you skin them in
graphic design to imitate the final product look?
--
View this message in context: http://www.nabble.com/What-do-your-prototypes-look-like--tp17604307p17604307.html
Sent from the ixda.org - discussion list mailing list archive at Nabble.com.

Comments

2 Jun 2008 - 10:52am
Chauncey Wilson
2007

I think that the answer depends on your goals and your audience. So
the answer could be either. If you are trying to create a "vision
prototype" to convince people to go ahead, you might skin it to look
like an "imaginary" product. If you want to test out basic navigation
early, you might just use the clickable wireframes with minimal
adornment.

Chauncey

On Mon, Jun 2, 2008 at 11:41 AM, Oleg Krupnov <oleg.krupnov at gmail.com> wrote:
>
> Do your prototypes look like clickable wireframes or do you skin them in
> graphic design to imitate the final product look?
> --
> View this message in context: http://www.nabble.com/What-do-your-prototypes-look-like--tp17604307p17604307.html
> Sent from the ixda.org - discussion list mailing list archive at Nabble.com.
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

2 Jun 2008 - 11:04am
Fred Beecher
2006

On 6/2/08, Chauncey Wilson <chauncey.wilson at gmail.com> wrote:
>
> I think that the answer depends on your goals and your audience. So
> the answer could be either. If you are trying to create a "vision

Exactly. Typically, my prototypes look like clickable wireframes because
most of the time my purpose in prototyping is to quickly answer the
question, "does this suck or rule?" Testing a wireframey prototype is the
way to do this.

Now I have also done prototypes where the prototype itself was nearly
indistinguishable from the existing system. There are three situations in
which I do prototypes this way: 1) Is the project to add functionality to an
existing system? 2) Is the functionality tightly integrated into the
existing system? 3) Will the system's users freak out when they see a
wireframe instead of what they're used to seeing?

If the answer to any of these questions is "Yes," then I'll do a
higher-fidelity prototype. If not, then it's almost always quicker, cheaper,
and easier to do a lower-fidelity prototype. The information you get back
will be just as good.

- Fred

2 Jun 2008 - 12:39pm
Janne Kaasalainen
2008

> Do your prototypes look like clickable wireframes or do you skin
> them in
> graphic design to imitate the final product look?

Like others have said already, it depends (on deliverable as well as
what is a prototype). But to at least answer something more, let's
give it a shot. :)

I hardly ever share just skeletons. We discuss over a board, over a
hand drawn wireframe and I perhaps draw some initial ones to my
sketchbook. But after the very initial stages, we've started to work
on more or less pixel perfect material when it comes to static
prototypes. Interactive sketches are often made to test specific
details of the 'thing' instead of the whole at once - and these too
are close to pixel perfect. And then there's lot of iterating with the
final 'thing'.

There are some exceptions, for example sketches in very early phases
when it is still under consideration what it is that the team will be
doing. Also, when existing UI frameworks are utilized, there is no
point trying to mimic those and thus quick mock-ups or templates get
used. Then there are more conceptual and experimental things that are
used to get the feeling, and level of detail for those can be whatever
is considered enough (but these are seldom spread onward). I'm sure
there are other cases as well, but I run into those less often as of
now.

- Janne Kaasalainen

3 Jun 2008 - 3:42am
Oleg Krupnov
2008

I am of course aware that the choice hi-fi vs. lo-fi prototype depends on the
audience. I just wanted to know what (hi-fi or lo-fi) is more frequent and
common in practice.

I've had a discussion with a professional and he claimed that for his team
and process, lo-fi prototypes are not practical. They a) scare the customer
b) too different from the final product look so that the customer's opinion
may change when he sees the product and c) mix together wireframing
(documenting) and prototyping (implementing) and so are an additional effort
and productivity leak. He advocated lo-fi prototypes only for low budget
projects. I'd like to validate this point of view.

--
View this message in context: http://www.nabble.com/What-do-your-prototypes-look-like--tp17604307p17618886.html
Sent from the ixda.org - discussion list mailing list archive at Nabble.com.

3 Jun 2008 - 5:04am
Anonymous

Really depends on what you're trying to test and how you plan on improving your prototype. For me, I only prototype things that my team does not know how to do exactly right. Best prace IA only gets you so far without prototyping. Therefore I can iterate quickly once I get user feedback in and test again and iterate again and test again... etc.

If I know the optimum way to produce a solution, I don't prototype. I simply do a user test. I don't consider this iterative prototyping.

For me, low-fi prototypes are great for three things:
1. Taking the first couple of steps towards solving glaring usability problems. Since I prototype purely for R&D and the extreme limits of my team's interface design skills, even a black-n-white clickable wireframe helps point out the inadequacies of our work. We can then quickly make changes on the day after the test and push it back into testing again. I usually do 3-5 iterations for our prototypes.

2. Finding out how much of our interface requires the crutch of visual navigation elements. We can figure out whether our interfaces stand up by themselves due to choice of navigation model, labeling, grid placement and scale. Or if they need a touch of color (a touch of glamor actually) to make them work.
It's similar to evaluating a logo in print design. If you can photocopy it and it still works %u2013 that's a good brand mark.

3. Black-n-white wireframes also can help make the team aware of how people with visual disabilities can deal with your interface. It's possible to test high/low contrast and calls to action without a hi-fi full-color design.

3 Jun 2008 - 9:24am
Fred Beecher
2006

Hi Oleg,

On 6/3/08, Oleg Krupnov <oleg.krupnov at gmail.com> wrote:
>
>
> I've had a discussion with a professional and he claimed that for his team
> and process, lo-fi prototypes are not practical. They a) scare the customer
> b) too different from the final product look so that the customer's opinion
> may change when he sees the product and c) mix together wireframing
> (documenting) and prototyping (implementing) and so are an additional
> effort
> and productivity leak. He advocated lo-fi prototypes only for low budget
> projects. I'd like to validate this point of view.

> They a) scare the customer

In some cases, yes. I don't know who your customers are, but for some of the
clients I've worked with this has definitely been true. I've found that it's
people who need to rely on the system for their work and are not technically
savvy who tend to be the ones who get scared. If both of these
characteristics are true of your customers, then this point is definitely
valid. If it's not true, then this point is not valid.

> b) too different from the final product look so that the customer's
opinion
may change when he sees the product

You're not looking for the customer's opinion during early-stage
prototyping. You're trying to find out if the interaction design & IA works
or not, which is something you can observe during testing. If you're doing
later stage prototyping, then the more nuanced aspects of experience become
more important. So this point is not valid for early stage prototyping but
somewhat valid for late stage prototyping.

> c) mix together wireframing (documenting) and prototyping (implementing)
and so are an additional effort and productivity leak.

Erm. When you do all this at once, you actually *save* time. Since the
beginning of my career I have advocated for prototyping, but only when I
discovered and started using Axure was I able to actually do it. Why?
Because the wireframes (which I would do anyway) *were* the prototype. Yes,
it takes a *little* extra time to make your wireframes interactive, but WAY
less time than it would take to manage an entirely separate prototyping
process.

Also, it seems like your colleague believes that the prototype should evolve
into the code. In most cases, this is absolutely NOT the way to go. Trying
to make the prototype with code of the quality required to be launched would
slow down the process and make it much less useful.

So yeah, this particular aspect of the argument is totally invalid. : )

I hope this helps!

- Fred

3 Jun 2008 - 10:03am
Oleg Krupnov
2008

Fred, thanks for the elaborate answer!

Fred Beecher wrote:
>
> You're not looking for the customer's opinion during early-stage
> prototyping. You're trying to find out if the interaction design & IA
> works
> or not, which is something you can observe during testing. If you're doing
> later stage prototyping, then the more nuanced aspects of experience
> become
> more important. So this point is not valid for early stage prototyping but
> somewhat valid for late stage prototyping.
>

I called the guy's attention to this point, but he said that there's never
anything so greatly innovative that is capable of making the entire hi-fi
prototype invalid, and the minor corrections can be made directly in the
hi-fi prototype. They do inject new stuff and give old stuff refreshed look,
but after years of practice, they developed typical solutions for most of
things. So actually they skip the "early-stage" prototyping entirely.

I don't know if this is a good practice or bad practice, but it sounds
reasonable and I wonder how many people do exactly like this. Can you give
an example when early stage prototyping is required?

Just a thought: Paradoxically, the more innovative an interaction is, the
more rapid prototyping is needed, but the less the rapid tools are capable,
because they are based on predefined widgets. And in reverse, the more
standard an interaction is, the less is the need to do rapid prototyping of
it, and the more readily the ability to do so is available in the rapid
tools.

Fred Beecher wrote:
>
> Erm. When you do all this at once, you actually *save* time. Since the
> beginning of my career I have advocated for prototyping, but only when I
> discovered and started using Axure was I able to actually do it. Why?
> Because the wireframes (which I would do anyway) *were* the prototype.
> Yes,
> it takes a *little* extra time to make your wireframes interactive, but
> WAY
> less time than it would take to manage an entirely separate prototyping
> process.
>

I agree exactly. Here Axure makes a good point. Perhaps the best of all its
points. However, isn't it somewhat lacking the freedom of drawing, like in
Visio or Omnigraffle, not to mention pixel-perfect tools like Photoshop?

What my friend obviously means is that once they have a special guy for
building hi-fi HTML prototypes, he doesn't want to spend his own precious
time to implement interactivity in the prototypes. He is done with just
annotated wireframes in Visio.

Fred Beecher wrote:
>
> Also, it seems like your colleague believes that the prototype should
> evolve
> into the code. In most cases, this is absolutely NOT the way to go. Trying
> to make the prototype with code of the quality required to be launched
> would
> slow down the process and make it much less useful.
>

No, he'd agree with you. Prototypes are a throw-away. Though they can be
reused in other projects. :)

Oleg.

--
View this message in context: http://www.nabble.com/What-do-your-prototypes-look-like--tp17604307p17625703.html
Sent from the ixda.org - discussion list mailing list archive at Nabble.com.

4 Jun 2008 - 9:05am
Fred Beecher
2006

On 6/3/08, Oleg Krupnov <oleg.krupnov at gmail.com> wrote:
>
>
> I called the guy's attention to this point, but he said that there's never
> anything so greatly innovative that is capable of making the entire hi-fi
> prototype invalid, and the minor corrections can be made directly in the
> hi-fi prototype. They do inject new stuff and give old stuff refreshed
> look,
> but after years of practice, they developed typical solutions for most of
> things. So actually they skip the "early-stage" prototyping entirely.

Ah. Well, that changes things. You've got a hi-fi prototype already, and
apparently someone to manage it. : )

I don't know if this is a good practice or bad practice, but it sounds
> reasonable and I wonder how many people do exactly like this. Can you give
> an example when early stage prototyping is required?

My situation is that I'm an external consultant who works on a lot of
from-scratch or wreck-and-rebuild projects. So for me, if there is any hint
of interactivity on a system I'll prototype it first. But even on very
simple content sites where paper prototype testing would be fine, I do
interactive prototyping. It's just easier for me. Also, many of our clients
have a user base that is spread out throughout the country (and in some
cases the world). It's MUCH easier to do remote testing with an interactive
prototype than, say, a clickable PDF.

But in your case, I think your colleague nailed it. You do early stage
prototyping when you've got something that's so innovative you don't have
any way to judge how effective it will be. On one project, I came up with
this map-based interaction that was intended to help people find vacation
property and encourage them to start planning to purchase it. I had no idea
if it would work. I did a rough prototype, tested *just that interaction*,
learned that mostly it worked well but that it shouldn't be the *only* way
to search.

Just a thought: Paradoxically, the more innovative an interaction is, the
> more rapid prototyping is needed, but the less the rapid tools are capable,
> because they are based on predefined widgets. And in reverse, the more
> standard an interaction is, the less is the need to do rapid prototyping of
> it, and the more readily the ability to do so is available in the rapid
> tools.

Yes! And that's why I taught a workshop on prototyping RIAs in Axure at the
2007 IA Summit. : ) The tools are very basic, but with a bit of creativity &
hacking, you can really go a long way. The only interaction I've had trouble
prototyping is drag & drop. But I do have good ways of faking it in Axure.

I agree exactly. Here Axure makes a good point. Perhaps the best of all its
> points. However, isn't it somewhat lacking the freedom of drawing, like in
> Visio or Omnigraffle, not to mention pixel-perfect tools like Photoshop?

Photoshop it is not, but it has all but replaced Visio for me. I can get any
shape I need except, strangely, for circles. : )

What my friend obviously means is that once they have a special guy for
> building hi-fi HTML prototypes, he doesn't want to spend his own precious
> time to implement interactivity in the prototypes. He is done with just
> annotated wireframes in Visio.

Yes, in your situation that is true. You're lucky to have a dedicated
prototyper!

Take care,
F.

6 Jun 2008 - 4:59am
Duncan Brown
2008

Oleg Krupnov wrote:
>
> Do your prototypes look like clickable wireframes or do you skin them in
> graphic design to imitate the final product look?
>

My prototypes look like all of the above
my workflow if typically

paper -> wireframe -> rendered UI

I work on the interaction all the way through the process, but get the main
user task flow worked out in a more abstract form (paper stickies) before
introducing any concrete UI elements.

a 'presentation' of the UI could happen at any stage, but most people are
only interested in the pretty pictures... then say they don't like green!

Duncan

--
View this message in context: http://www.nabble.com/What-do-your-prototypes-look-like--tp17604307p17688565.html
Sent from the ixda.org - discussion list mailing list archive at Nabble.com.

Syndicate content Get the feed