The future of Wireframes (was: Joel Spolsky claims the "Program Manager" role does UI design... ????)

12 Mar 2009 - 4:20am
5 years ago
18 replies
2506 reads
milan
2005

> If I never see "wireframe" as a deliverable again, I will be a
> happy man. The age of visio, omniograffle, axure, iRise, etc. I hope
> come crashing down (now offense to all the coders who worked hard on
> these tools), in favor of Fireworks, Catalyst, Flash, Blend and
> Illustrator, Coda, etc.

Dave,

really interesting remark, questioning all my beliefs :-)

I am not sure if I understand your point here. Do you think wireframes
should be skipped, because this activity doesn't add any value? We used
to work that way, starting directly with the "final" design - around
2001 when I thought I was a web designer... Today, I always advocate for
the opposite.

Personally, I think wireframes or similar non-visual tools should keep
their role in UX projects, because they enable designers and others
involved to abstract the general behaviour/structure from the visual and
coded high fidelity design.

They are just a way to concentrate on a certain aspect of the design,
while Illustrator does the same for detailed visual design, and a
Swim-Lane Diagram for abstract interaction modelling. For detailed
interaction design, to communicate how a certain interaction element or
a navigation is working, I also prefer something more close to the final
result, but does that really replace the high-level structuring done in
wireframes?

For me, the classic way is like

Requirements, Goals
(here is a fork)
Scenarios (Diagrams etc) Design Principles (based on CI)
Wireframes or Similar Vision & Style Guide
Lo-Fi Prototype (Paper, HTML) Visual Mockups
Testing and Learning Hi Fi Prototype (Blend etc.)
(here the two are joining again)
Testing (again :)
Documentation, Specification, Production
Communication

I think the future could be even less concrete, like an even more
abstract wireframe-framework where design components are being stacked
like modules. This would better respond to composite application or
highly personalized products.

Your thoughts, please!

milan
--
milan guenther * interaction design
||| | | |||| || |||||||| | || | ||

+33 6 67 11 13 83 * www.guenther.cx

Comments

12 Mar 2009 - 5:33am
Dave Malouf
2005

Hi Milan,

Thanx for asking me to explain so nicely. ;-)

First, let me say this REALLY all depends on context and this is what
I would call part of the Pendulum effect of practice shifting. I.e. we
went from IMHO no user testing to focusing so much on the user we
forgot about the value of the designer (but that's another thread).
We went from stale technology driven sites to flourishes of
expressionism and now have found a new type of minimalism, and I'm
sure we'll see a reaction to this soon enough.

My thoughts on this subject are more complex than the previous thread
can fully account for.
1) We aren't making enough. We have made enough excuses for this and
we need to make more.
2) Look at your own terminology
"Personally, I think wireframes or similar non-visual tools should
keep their role in UX projects, because they enable designers and
others involved to abstract the general behaviour/structure from the
visual and coded high fidelity design."
The UX role is not one of "design"? This separation of roles of
structure/behavior from form is something I'm growingly against
(easy for me to say now that I'm not "in the game" any longer). I
have seen way too many designers who know users, tech, and
communication to not suggest this any longer. It is just plain
irresponsible.
3) Because of this, I think we have relied too heavily on processes
that actually KEPT us from design thinking and design methodologies
that could actually help us most.

So to answer your question most directly:
1) Pen to paper should ALWAYS be your first tool. If you aren't
drawing/sketching I almost want to say you really are missing out on
the most fundamental part of being a designer.
2) What you do after that depends on the project type.
a) jump right into a graphics tool for UI
b) use visio/omnigraffle but ONLY for flows (NEVER for wireframes)
c) use excel for content cataloging
d) Do scenario development
i) sketch comics
ii) annotate photographs

But what is really clear to me is that what has been delivered as
"wireframes" in the past and all the efforts for making all these
stencils and palettes for "wireframes" has been where we have sold
ourselves WAY short.

Sure there are various levels of fidelity and polish, but what I have
found over time is that the more I did wireframes the more I actually
realized they were full on UIs that I wanted to deliver.

And again like the persona conversation it isn't about the
deliverable (we so concentrate too much on deliverables) as much as
it is about what are you trying to achieve with those deliverables.
I.e. a wireframe should be about the stage where you begin
"framing" your UI. The language, navigation, path structure, all
start to line up. But how I communicate this will depend on my
audiences. I have found that wireframes are distracting enough to
warrant something up fidelity from them anyway. NOT final design, but
not as unrefined as a traditional wireframe. Basically my wireframe
had to be visually designed to be most effective at communicating the
level of detail I needed to.

the BIG mistake I have seen is where we try to communicate
"behaviors" into wireframes. These annotated wireframes with
multiple states to me is the biggest headache in the world. It is
documentation and unreadable. Just build it! SHOW me what you want it
to behave like. And this is the area that Andrei and myself are now in
alignment. It is YOUR job to make that happen. Passing the buck to
someone else is really giving up control over your baby. Sure, call
it collaboration, but it is still giving it up AND managerial
perception sees it (thus the whole "gatekeeper" thing you see in
Joel's article.

Tools like Blend & Catalyst are looking to change this dynamic A LOT.
I suggest you go out there and make them sing!!!

-- dave

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=39897

12 Mar 2009 - 5:52am
Todd Warfel
2003

On Mar 12, 2009, at 6:20 AM, David Malouf wrote:

> If I never see "wireframe" as a deliverable again, I will be a happy
> man. The age of visio, omniograffle, axure, iRise, etc. I hope come
> crashing down (now offense to all the coders who worked hard on
> these tools), in favor of Fireworks, Catalyst, Flash, Blend and
> Illustrator, Coda, etc.

I sure hope this isn't what you're teaching your students at SCAD. I
would hope that as practitioners and educators we can realize the
value for various methods and when they are appropriate.

Animators and game developers use storyboards and wireframes in their
process. If there's any question, watch a documentation on how Pixar
makes films or speak to people working at EA.

Axure and iRise are not wireframing tools. They are documentation and
simulation tools, which are used much more for creating prototypes
than static wireframes.

For the time being and foreseeable future, there is and will be a
great deal of fantastic design work done incorporating wireframes in
the design delivery process.

We haven't done a wireframe in 2 years. We only prototype these days.
However, I still realize the value of wireframes and how they can help
in the design process. Would I rather see more prototyping and less
wireframing? Sure. But at the same time, I realize that there are
companies who are much more documentation driven and prototyping might
not be right for them (yet).

Cheers!

Todd Zaki Warfel
Principal 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
Twitter: zakiwarfel
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

12 Mar 2009 - 6:00am
Dave Malouf
2005

Todd? If a best in class designer as yourself isn't using wireframes and
hasn't for ages (2 yrs in our biz = ages) it seems to me that you are just
being open to be nice.

1st, I didn't say don't do storyboards. I did say don't do wireframes and
YES I do teach my students to work in interactive ALL the time.
Sketch > scenarios/storyboards (that are ALWAYS human situated; more on this
below) > low-fi interactive > hi-fi interactive

Ok, storyboards have to be character/human situated. The point of the
storyboards is to tell the story of use (IMHO) than to relay early concepts
of UI. This means that you would do better to do comic strips with lightly
sketched UI (See the Drawing Board series by Cooper as great examples of
this) instead of doing "wireframes" as story boards.

There is ALWAYS a point where you have to do what is best for your context
and for your skillsets but the conversation is about direction and the fact
that you say "yet" already implies that a documentation centric approach to
your design is the past. So why wait!?!

-- dave

On Thu, Mar 12, 2009 at 7:52 AM, Todd Zaki Warfel <lists at toddwarfel.com>wrote:

>
> On Mar 12, 2009, at 6:20 AM, David Malouf wrote:
>
> If I never see "wireframe" as a deliverable again, I will be a happy man.
> The age of visio, omniograffle, axure, iRise, etc. I hope come crashing down
> (now offense to all the coders who worked hard on these tools), in favor of
> Fireworks, Catalyst, Flash, Blend and Illustrator, Coda, etc.
>
>
> I sure hope this isn't what you're teaching your students at SCAD. I would
> hope that as practitioners and educators we can realize the value for
> various methods and when they are appropriate.
>
> Animators and game developers use storyboards and wireframes in their
> process. If there's any question, watch a documentation on how Pixar makes
> films or speak to people working at EA.
>
> Axure and iRise are not wireframing tools. They are documentation and
> simulation tools, which are used much more for creating prototypes than
> static wireframes.
>
> For the time being and foreseeable future, there is and will be a great
> deal of fantastic design work done incorporating wireframes in the design
> delivery process.
>
> We haven't done a wireframe in 2 years. We only prototype these days.
> However, I still realize the value of wireframes and how they can help in
> the design process. Would I rather see more prototyping and less
> wireframing? Sure. But at the same time, I realize that there are companies
> who are much more documentation driven and prototyping might not be right
> for them (yet).
>
>
> Cheers!
>
> Todd Zaki Warfel
> Principal Design Researcher
> Messagefirst | Designing Information. Beautifully.
> ----------------------------------
> *Contact Info*
> Voice: (215) 825-7423Email: todd at messagefirst.com
> AIM: twarfel at mac.com
> Blog: http://toddwarfel.com <http://toddwarfel/>
> Twitter: zakiwarfel
> ----------------------------------
> In theory, theory and practice are the same.
> In practice, they are not.
>
>
>
>
>

--
Dave Malouf
http://davemalouf.com/
http://twitter.com/daveixd
http://scad.edu/industrialdesign
http://ixda.org/

12 Mar 2009 - 6:11am
milan
2005

> 1st, I didn't say don't do storyboards. I did say don't do wireframes and
> YES I do teach my students to work in interactive ALL the time.
> Sketch > scenarios/storyboards (that are ALWAYS human situated; more on this
> below) > low-fi interactive > hi-fi interactive

So that means you start with interactive techniques directly, but still
there is a phase where the "look" of what you are building is rather
undefined / abstract.
So Flash, Blend, Fireworks may not be the best choice of tools, right?

I think they focus too much on visual/interactive details, and thus
distract from the goal to quickly create a rough vision of the product.

Besides, imho ALL interaction designers have to learn to code to be able
to produce new visions of interactions on their own, but that's another
story.

--
milan guenther * interaction design
||| | | |||| || |||||||| | || | ||

+33 6 67 11 13 83 * www.guenther.cx

12 Mar 2009 - 6:21am
milan
2005

> 1st, I didn't say don't do storyboards. I did say don't do wireframes and
> YES I do teach my students to work in interactive ALL the time.
> Sketch > scenarios/storyboards (that are ALWAYS human situated; more on this
> below) > low-fi interactive > hi-fi interactive

So that means you start with interactive techniques directly, but still
there is a phase where the "look" of what you are building is rather
undefined / abstract.
So Flash, Blend, Fireworks may not be the best choice of tools, right?

I think they focus too much on visual/interactive details, and thus
distract from the goal to quickly create a rough vision of the product.

Besides, imho ALL interaction designers have to learn to code to be able
to produce new visions of interactions on their own. Besides being
at least a "basic" graphic designer.
But that's another story (:

milan
--
milan guenther * interaction design
||| | | |||| || |||||||| | || | ||

+33 6 67 11 13 83 * www.guenther.cx

12 Mar 2009 - 6:23am
pyces
2007

I agree. In my experience, any client who sees color and images focuses
on whether they like that color or whether that image fits, and don't
pay attention to the more important elements (at this stage in the
process), which include the related issues of clarity of navigation, how
easy it is for users to fulfill their goals, whether the most important
tasks are readily findable, whether the page flow makes sense. This can
and much more can all be done in wireframes (I use Visio) in a fraction
of the time it takes to code it, which allows the client to provide
feedback earlier and keeps me from going down a wrong path, while
letting me know when I'm going down the right one. I can also make
changes on-the-fly when meeting with clients so that we can immediately
see how their suggestions might enhance or detract from the user
experience. You can do this with FireWorks too, but here you have
usually added color and images (unless people are making grayscale
prototypes in FireWorks?) which detract from the team's and client's
abillity to think objectively about the afore-mentioned critical
elements. At least for me, making changes on-the-fly with HTML within
the span of a meeting would be difficult!

Speaking of hi-fidelity prototyping tools, has anyone used Silverlight
extensively? Could you share your experiences?

Thanks,
Courtney Jordan

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Milan Guenther
Sent: Thursday, March 12, 2009 8:11 AM
To: Dave Malouf
Cc: Forum Interaction Design Ixda
Subject: Re: [IxDA Discuss] The future of Wireframes (was: Joel Spolsky
claims the "Program Manager" role does UI design... ????)

> 1st, I didn't say don't do storyboards. I did say don't do wireframes
and
> YES I do teach my students to work in interactive ALL the time.
> Sketch > scenarios/storyboards (that are ALWAYS human situated; more
on this
> below) > low-fi interactive > hi-fi interactive

So that means you start with interactive techniques directly, but still
there is a phase where the "look" of what you are building is rather
undefined / abstract.
So Flash, Blend, Fireworks may not be the best choice of tools, right?

I think they focus too much on visual/interactive details, and thus
distract from the goal to quickly create a rough vision of the product.

Besides, imho ALL interaction designers have to learn to code to be able
to produce new visions of interactions on their own, but that's another
story.

--
milan guenther * interaction design
||| | | |||| || |||||||| | || | ||

+33 6 67 11 13 83 * www.guenther.cx

________________________________________________________________
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

12 Mar 2009 - 6:40am
Todd Warfel
2003

On Mar 12, 2009, at 8:00 AM, Dave Malouf wrote:

> Todd? If a best in class designer as yourself isn't using wireframes
> and hasn't for ages (2 yrs in our biz = ages) it seems to me that
> you are just being open to be nice.

I'm a realistic dreamer. A paradox of balance.

Actually, I'm not being nice, I'm being honest. I realize that OUR
situation isn't the norm. Not only do we not wireframe, but we also
produce production level prototypes. What WE do at Messagefirst isn't
typical and I'm realistic in knowing that. I don't expect others to do
what we do. It would be nice and I do hope the field gets there one
day, but I don't see it coming anytime soon.

That's not to say I don't think more people should be doing more
prototyping and less wireframing, because I do. However, I realize
that there are a number of environments that require heavy
documentation (e.g. government, corporate) and so in those contexts I
see wireframes w/behavior notes as being valuable.

Additionally, I realize that IA/IxD is getting done by people who
aren't IAs and IxDs. It's getting done by project managers, product
managers, business analysts, developers, etc. And for several of those
people, wireframes are the best way they can communicate.

I do look forward to the day when our field and those related to us
are doing a lot more prototyping and less wireframing, however, I feel
that day is a long way off. In the mean time, I'll keep doing what I
do, looking for ways to continually improve our process and hope to
leave behind a game changing legacy.

Cheers!

Todd Zaki Warfel
Principal 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
Twitter: zakiwarfel
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

12 Mar 2009 - 6:48am
Coryndon Luxmoore
2004

> FireWorks too, but here you have
> usually added color and images (unless people are making grayscale
> prototypes in FireWorks?)

Yep the core of my process revolves around wireframes in fireworks
with simple image maps. Super easy to maintain and iterate as you can
use the PNGs for the wireframes, the prototype, usecases, other
documentation. You can add the fully rendered versions of the core
screens into the prototype as the visual design templates are evolved.
It has made it much easier to get the entire team on board, users
tested, etc. It has its limits for detailed interaction testing but it
covers about 90% of the design process for a lot of my clients

--------------------------------------------
Coryndon Luxmoore
Interaction Designer

coryndon (at) luxmoore (dot) com
---------------------------------------------

12 Mar 2009 - 7:27am
Vishal Subraman...
2005

This is one of those threads that won't ever tip either way, because 'it
depends'. Everything that's been said here is valid. Let me throw out one
more scenario (that I work in)- very large scale products. We
have separate folks who do

1. User Research/ Sketches/ Wireframes/ Process Flows/ UI/ non-production
level prototypes/ Usability (this seems bigger only because I expanded all
the steps involved)
2.Visual Design/ Branding/ CSS
3. Front End Dev

All 3 report into the same structure, but these roles need to
be separate because they are all each full time roles. Yes, I 'work in
Visio' (Omnigraffle in my case) all day, but I don't get paid because of my
killer Omnigraffle skills. This forum knows better what I bring to the
table. In large scale products like the one that I work on, people working
on all three will result in overall mediocrity.

If I were leading an effort to build say a small 5-10 'page' website, it
would be foolish to hire to do the same. If I were designing a really
complex product (like say a medical device or such), Design Research would
probably be a separate role. And so on. There is such a wide spectrum of
products & projects in the marketplace, that there is space for all. Saying
that wireframes need to go, or designers should not code is just plain
wrong.

> That's not to say I don't think more people should be doing more
prototyping and less wireframing, because I do. > However, I
realize that there are a number of environments that require heavy
documentation (e.g. government, > corporate) and so in those
contexts I see wireframes w/behavior notes as being valuable.

--
-Vishal
http://www.vishaliyer.com

12 Mar 2009 - 7:34am
Nicholas Iozzo
2007

I think it is worth emphasizing what Todd said. Wireframes will be
around until the sophistication of the buyer gets to the point where
they are not needed.

When doing consulting in large corporations or government, when you
developing new tools for complex processes, wireframes allow you to
focus the attention of the buyer onto the functionality within the
screen.

The norm in these situations is using the wireframes to flesh out the
requirements. You could have done some great research, and inspired
requirements documentation but odds are that most people in the room
still do not get what you are trying to build. Wireframes allow you
to quickly show them what it is and iterate it many more times then
you ever could in a prototype or a fully design comp.

Reason two has to do with detailed screen specifications. When you
are designing an application to aid highly trained experts, the
business rules within the system need to be documented and
illustrated in a comprehensive manner. Prototypes will not cut it.
Notes on comps will not cut it.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=39897

12 Mar 2009 - 8:16am
Scott McDaniel
2007

On Thu, Mar 12, 2009 at 9:34 AM, Nicholas Iozzo <ixda at humansize.com> wrote:
>
> Reason two has to do with detailed screen specifications. When you
> are designing an application to aid highly trained experts, the
> business rules within the system need to be documented and
> illustrated in a comprehensive manner. Prototypes will not cut it.
> Notes on comps will not cut it.

This has been a great conversation, but this is the point I wanted to
make in 'defense' of wireframes.
While various levels of fidelity can serve different purposes, the
longer term use for most of the wireframes I produce
ends up being for the benefit of engineering teams who use them to get
a visual and textual reference for what they're
building, without being directly concerned with the final design.
Depending on the needs of the specific project, application,
team and so on, this can be as granular as ID names and

I realize I may be exposing my personal practice as wrong for what
these things are supposed to be,
but given when it comes to documentation I've been thanked more times
for making things easier on Engineering, not to mention providing a
framework for them to work within and still maintain the UX concerns,
I feel confident in the relevance of wireframing,
even if that will change over time.

All my love,
Scott

--
"I have mad skills at doing spazzy things." - Janiene West

12 Mar 2009 - 8:51am
Dave Malouf
2005

Milan & Courtney,

Why do you assume that I mean that low-fi interactive means using color?

I used to believe that whole message about "distraction" until I realized
through conversations about wireframes with clients that there were OTHER
distractions, or more importantly lack of focus. I found that I can easily
tell a client to ignore Look & feel and concentrate on what I want them to
concentrate on. It was about the presentation.

Todd, I actually think you aren't so different as you think you are. If you
remove the titles of IA/IxD you'll find that MANY designing/building
interactive systems are doing exactly what you do. They aren't in OUR
community, but I've been learning that the interactive community for example
is so much larger than we are as a community and doing a heck of a lot more
of the work we think about as being in our domain. Its like when IAs compare
their work/scope/community to Informatics. I often feel we are a pinprick
compared to the larger context of the work being done.

As for tools. You can use fireworks, blend and flash and do the whole thing
in Grayscale, no? And you can use Visio and add as much distracting color as
in Illustrator. My point about tools is in layering (a topic we haven't
touched yet). If I start in my interactive and drawing tools I'm going to
end in, I can create expertise in the tools that count towards the end
products and not distract my education with learning tools that add little
to no value to the end process. IF Visio or Omni, etc. weren't just an
upstream tool I might agree with you.

So what is the larger point? Is the real point about "wireframes"? NO! Its
really a red herring. the real point is about what is our responsibility as
designers. Not "interaction designers" but as "designers". The answer is
"the whole vision" and anything short of that means that somewhere around
the bend someone is going to be doing a more complete job than you are. It
might not be now, but I give it 4 years and this, "I'm an interaction
designer, I do wireframes" thing that many (not necessarily in this thread)
are defending is going to find their way to the door. I know I will never
hire someone who can't do production graphics again.

-- dave

12 Mar 2009 - 10:58am
Andrei Herasimchuk
2004

On Mar 12, 2009, at 4:33 AM, dave malouf wrote:

> But what is really clear to me is that what has been delivered as
> "wireframes" in the past and all the efforts for making all these
> stencils and palettes for "wireframes" has been where we have sold
> ourselves WAY short.

Wow... I think I just woke up in some alternate reality. To hear Dave
say this after all this time... well... I'm finally at a loss for words.

Know hope!

--
Andrei Herasimchuk

Chief Design Officer, Involution Studios
innovating the digital world

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

12 Mar 2009 - 11:10am
Andrei Herasimchuk
2004

For what it's worth, the larger point isn't about "wireframes." The
larger point is what Dave is saying. If all you create is wireframes,
then you're not really an interface or interaction designer.

Further, using software tools to create wireframes is largely
busywork. You can do wireframes with pencil and paper. Why waste time
producing a deliverable with a heavy software tool like Visio or
Illustrator that will never show up in the final product? Just sketch
it. It's both faster and more direct as a designer to do it that way.

I'm off to SXSW. Just as things are getting interesting.

--
Andrei Herasimchuk

Chief Design Officer, Involution Studios
innovating the digital world

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

12 Mar 2009 - 12:33pm
milan
2005

On Thu, 2009-03-12 at 10:51 -0400, Dave Malouf wrote:
> Milan & Courtney,
>
> Why do you assume that I mean that low-fi interactive means using color?

No, I think for the "lo-fiest" interactive prototype you need just one
pen and some paper. But my point was, using Exp. Blend for lo-fi
prototyping would be like using a giant oil palette for sketching, since
this is also a heavy software tool.

So I think it does not always make sense to use those production-ready
tools from the beginning, and one of the strengths of a good designer is
to know when to use what tool, and when to apply which technique.

Did you ever use DENIM? Apart from requiring a tablet pc, being a bit
unstable here under linux, it is great to quickly create low-fi
prototypes basen on sketches. It creates HTML output which is easy to
share, and yes you may even use more than one colour though I never used
that function :) - now that's a light tool for early phases, doing the
same in Blend would be much more effort.

To the other points I totally agree, there is no such design that
results in intermediate states. The designer must have a vision, the
vision is the final product, and the result of his work has to be close
to that. He/she has to master all technologies involved to communicate
and implement that vision.

milan
--
milan guenther * interaction design
||| | | |||| || |||||||| | || | ||

+33 6 67 11 13 83 * www.guenther.cx

12 Mar 2009 - 1:46pm
Jim Leftwich
2004

Andrei writes:

"For what it's worth, the larger point isn't about "wireframes."
The larger point is what Dave is saying. If all you create is
wireframes, then you're not really an interface or interaction
designer."

Response:

I completely disagree, which simply goes to show that there can be
very different informed perspectives on what constitutes an
interaction designer.

Most of my 25-year-long career has been based on high-fidelity flows
(both wireframes and high-fidelity wireframes with production
graphics as part of them). These have been delivered to dozens of
different types of engineering groups and individuals for
implementation in a vast range of products, platforms, software, and
systems.

So it's entirely possible. Again we see that our field has a broad
range of possibilities, and not a narrow definition.

Andrei writes:

"Further, using software tools to create wireframes is largely
busywork. You can do wireframes with pencil and paper. Why waste time
producing a deliverable with a heavy software tool like Visio or
Illustrator that will never show up in the final product? Just sketch
it. It's both faster and more direct as a designer to do it that
way."

Response:

I've always spent a great deal of time on my flows, both as
early-stage pencil sketches, low-fidelity digital wireframes and
thumbnail graphic flows, and then on to higher fidelity graphics and
heavily described/note-intensive flows and documentation.

I've always considered time doing flows to be thinking time. I'm
using these graphical maps to consider alternative patterns,
arrangements, configurations, and relationships. In my own work
there's something about doing the graphical layout that supports my
flow state and ability to think about the overall dynamic
interactional architecture (I've used Illustrator and Photoshop in
combination to do flows and documenation for the past 20 years,
SuperPaint prior to that, and MacPaint back in the early days).

I like maps and flows because it lets me examine alternative patterns
faster. I can then also have there there to communicate with -
primarily with my associate engineer, but also with clients or other
associates (or apprentices that are working with me).

Personally, I don't use Omnigraffle because I work faster and have
more graphical and layout flexibility with Illustrator. I can import
graphics from Photoshop master files where I'm creating the
implementable graphics, and scale and move things around in a more
accomodating manner. In short, I can simply be more graphically
communicative in Illustrator.

The other advantage of using digital tools (and I never do mockups or
prototypes, except for physical industrial design prototypes - as I
work with an engineer to build it for real as the design is being
created), is the ability to quickly copy and make exploratory
iterations. I find that much more difficult to do with pencil
sketches. I find myself wanting to copy everything to a second
iteration, but changing just one or two things, and then have both to
compare.

My method and approach has certainly worked for me, and again this is
evidence of not everyone working successfully in the same manner.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=39897

12 Mar 2009 - 2:27pm
Andrei Herasimchuk
2004

On Mar 12, 2009, at 12:46 PM, Jim Leftwich wrote:

> I completely disagree, which simply goes to show that there can be
> very different informed perspectives on what constitutes an
> interaction designer.

Honestly and with all due respect, you're basically talking out of
both sides of your mouth with this post, Jim.

You're getting hung up on a detail point: That using a digital tool
over pencil and paper for design sketching and process work is somehow
being negated in this discussion. It's not. The larger point is that
people who do NOTHING BUT deliver line art style wireframes and
workflow diagrams are about to get lapped a few times over in this
field by up and coming designers who will be able to run circles
around them both in the hard skills of craft and the soft skills of
design vision and communication.

Don't shoot the messenger here, but you all have been warned.

> Most of my 25-year-long career has been based on high-fidelity flows
> (both wireframes and high-fidelity wireframes with production
> graphics as part of them). These have been delivered to dozens of
> different types of engineering groups and individuals for
> implementation in a vast range of products, platforms, software, and
> systems.
>
> So it's entirely possible. Again we see that our field has a broad
> range of possibilities, and not a narrow definition.

You just stated that "production graphics" were part of the process,
which is obviously beyond "wireframes." So I'm not sure why you're
disagreeing with the larger point.

> I've always spent a great deal of time on my flows, both as
> early-stage pencil sketches, low-fidelity digital wireframes and
> thumbnail graphic flows, and then on to higher fidelity graphics and
> heavily described/note-intensive flows and documentation.

You're again bringing in stuff beyond the crude line work wireframes.
Are you arguing the larger point or agreeing with it? It appears you
are validating the larger point.

> I've always considered time doing flows to be thinking time. I'm
> using these graphical maps to consider alternative patterns,
> arrangements, configurations, and relationships. In my own work
> there's something about doing the graphical layout that supports my
> flow state and ability to think about the overall dynamic
> interactional architecture (I've used Illustrator and Photoshop in
> combination to do flows and documenation for the past 20 years,
> SuperPaint prior to that, and MacPaint back in the early days).

Again... stuff that's not wireframes in the sense of what we've been
discussing to this point.

> I like maps and flows because it lets me examine alternative patterns
> faster. I can then also have there there to communicate with -
> primarily with my associate engineer, but also with clients or other
> associates (or apprentices that are working with me).

Fine. But you're still doing busywork if you are taking the time to
create digital mockups that effectively will get thrown away and never
see the light of day. If you have the time and budget, that's great.
But to claim you're not doing busywork is disingenuous. You can do all
of that stuff with pencil and paper and inking and such on projects.
In fact, where you don't have the time and budget, I bet you do. We
all do if push comes to shove.

You can do it an order of magnitude faster with pencil and paper.

But that's a distraction. It's not the point.

The point is that there are people in this field who think their job
is to make wireframes, and nothing else. Dave's larger point was that
has to go away. I've been saying that for years, and I'm glad to hear
him say it now.

--
Andrei Herasimchuk

Chief Design Officer, Involution Studios
innovating the digital world

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

12 Mar 2009 - 5:40pm
Jim Leftwich
2004

I think we're in agreement regarding the difference between just
simple wireframes and flows that are composed of production source
images and elements.

But I do believe that some of us find it easier and more to iterate
and explore using digital tools, than by sketching. I do. And as I
stated, it's in doing that (which produces a discussion-ready
artifact showing alternatives side by side) that I'm simultaneously
thinking and turning the problem over in my head.

The digital (and printed form) of my specs are never wasted, in that
they're the documentation of the interactional architecture and the
implementable resources. They're the blueprints. They're also the
materials that I used to teach associates and apprentices. Therefore
very useful.

In my own case, it's in pencil work that I end up doing more busy
work, in that I spend a lot of time drawing many of the same things
again, rather than simply copying them over to another part of my
huge Illustrator canvas.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=39897

Syndicate content Get the feed