Which comes first: Task Flows or Wires?

27 May 2008 - 8:32am
6 years ago
10 replies
1480 reads
tdellaringa
2006

Hello everyone,

I'm just starting a brand new project, something of a larger scale. I have
basic requirements at hand, nothing too detailed though (very high level).
I'm wondering which is better to tackle first, task flows or wires?
Intuitively I'm thinking I would do task flows first, to get the sense of
how the pages fit together before jumping into wires, but would like to hear
thoughts.

I'm also going to be giving Axure a try with this project, I've gone through
the demo movies and I think it looks really great.

Thanks!

Tom

--
See my web comic!
http://www.maroonedcomic.com

Comments

27 May 2008 - 8:46am
Matt Nish-Lapidus
2007

Hi,

I'm actually a huge fan of starting with concept models. That way you
can map out how each bit of information (including users) connects to
all the others, from there you can start to understand the required
interactions and flows. Then I'd do flows for each (or some) specific
interactions.. once all that is pretty firm I'd start the
sketching/wireframe portion of actually designing the UI for each
flow.

I highly recommend Dan Brow's "Communicating Design" as a source for
how to do these things, and what other types of exploratory
documentation you might want to try.

Matt.

On Tue, May 27, 2008 at 9:32 AM, Tom Dell'Aringa <pixelmech at gmail.com> wrote:
> Hello everyone,
>
> I'm just starting a brand new project, something of a larger scale. I have
> basic requirements at hand, nothing too detailed though (very high level).
> I'm wondering which is better to tackle first, task flows or wires?
> Intuitively I'm thinking I would do task flows first, to get the sense of
> how the pages fit together before jumping into wires, but would like to hear
> thoughts.
>
> I'm also going to be giving Axure a try with this project, I've gone through
> the demo movies and I think it looks really great.
>
> Thanks!
>
> Tom
>
> --
> See my web comic!
> http://www.maroonedcomic.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
>

--
Matt Nish-Lapidus
work: matt at bibliocommons.com / www.bibliocommons.com
--
personal: mattnl at gmail.com

27 May 2008 - 8:51am
AlokJain
2006

Tom,

I would certainly suggest starting with High level task flows, for me
it tends unearth more gaps and question, but do not push for the task
flow to be complete or thorough to the last detail, else it'll become
a goal in itself.

The other thing that'll help is to set up a wiki, this has helped me
tremendously with large engagements, to keep recording new and
evolving requirements as well as design.

Cheers
Alok Jain

On May 27, 2008, at 9:32 AM, Tom Dell'Aringa wrote:

> Hello everyone,
>
> I'm just starting a brand new project, something of a larger scale.
> I have
> basic requirements at hand, nothing too detailed though (very high
> level).
> I'm wondering which is better to tackle first, task flows or wires?
> Intuitively I'm thinking I would do task flows first, to get the
> sense of
> how the pages fit together before jumping into wires, but would like
> to hear
> thoughts.
>
> I'm also going to be giving Axure a try with this project, I've gone
> through
> the demo movies and I think it looks really great.
>
> Thanks!
>
> Tom
>
> --
> See my web comic!
> http://www.maroonedcomic.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

27 May 2008 - 10:06am
Fred Beecher
2006

On 5/27/08, Tom Dell'Aringa <pixelmech at gmail.com> wrote:
>
>
> Intuitively I'm thinking I would do task flows first, to get the sense of
> how the pages fit together before jumping into wires, but would like to
> hear
> thoughts.

DEFINITELY! How do you know what wireframes to make if you haven't mapped
out the flows? : )

But as Matt says, it might be worthwhile really exploring the subject matter
area in depth first. Are you working with a Business Analyst on this
project? Or are you the BA? : ) What stage are the requirements at? If
you've got this detailed knowledge already, then you may be able to skip the
concept modeling and jump straight into flows.

I'm also going to be giving Axure a try with this project, I've gone through
> the demo movies and I think it looks really great.

Axure is great for this kind of thing. You can develop flows in Axure in
addition to wireframes, and make the pages represented in the flow link to
your actual wireframes in the clickable prototype. (There's even a trick to
enable clicks on these flow objects to control the state of dynamic elements
on the destination page... email me off-list if you're interested.)

What type of development are you working in? Do your developers hate paper
documentation? You can use these live-linked flows plus a prototype
generated with the option to display annotation tags to give them *live*
documentation within the prototype. Damn cool if you ask me. : )

- F.

27 May 2008 - 2:03pm
Kevin Lee
2007

If you are an interaction designer, you should consider starting out
with flow map (even if you have a strict feature content requirements
from engineering or marketing). This exercise not only put you (or
your team) out of your comfort zone and think from user's
perspective but also force you to think like the user (rather than
like the designer).

In mapping out the most straight forward mental model of flow of
information, you will eventually find yourself creating necessary
wireframes to visually communicate the information layout, behaviors,
and use cases.

At the end, just like anything else, this is also an iterative
process. So don't let yourself love your flow map too much because
it will change as you move down the product dev process.

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

27 May 2008 - 2:24pm
Jeffrey D. Gimzek
2007

I second this - at least a few top level flows.

Say, registration, first time login, repeat user (cookied) visit, and
one flow on primary function (posting something, buying something,
searching something) are necessary to even know what to start
wireframing.

You can save a lot of time this way by concentrating your wireframe
design work on the most important user screens, and letting those
screens define site-wide standards.

Not doing some flows first can lead to the FAQ page page having the
same priority in the design schedule as the shopping cart page (or
whatever mission critical page)

It also helps to show the stakeholders what is really important to
users, and can help them prioritize development.

jd

On May 27, 2008, at 12:03 PM, Kevin Lee wrote:

> If you are an interaction designer, you should consider starting out
> with flow map (even if you have a strict feature content requirements
> from engineering or marketing). This exercise not only put you (or
> your team) out of your comfort zone and think from user's
> perspective but also force you to think like the user (rather than
> like the designer).
>
> In mapping out the most straight forward mental model of flow of
> information, you will eventually find yourself creating necessary
> wireframes to visually communicate the information layout, behaviors,
> and use cases.
>
> At the end, just like anything else, this is also an iterative
> process. So don't let yourself love your flow map too much because
> it will change as you move down the product dev process.

- -

Jeffrey D. Gimzek | Senior User Experience Designer

http://www.glassdoor.com

27 May 2008 - 2:54pm
Leah Buley
2007

I agree that doing task flows first is probably the standard, but
I'll play devil's advocate here: you can actually get some pretty
interesting results by diving right away into super sketchy, lo-fi
wireframing.

Task flows can sometimes make a process seem linear and sequential
even though people may approach it by fits and starts, through weird
back doors, and in otherwise unpredictable ways.

Starting with the most interesting moment in a process and
envisioning what that might look like and then brainstorming around
what hangs off that moment -- before, after, and parallel to it --
can be another good way to start to get your hands around how much
complexity you're dealing with.

Then on to task flows and more traditional wireframing...

Leah

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

27 May 2008 - 5:14pm
Emil Ovemar
2008

I agree with Leah. Starting with a rough wireframe of the social object (photo, article, video etc) and getting interactions with the object down can be an effective way to get things going. An A3 with simplified wireframes of all screens has worked for me too. Flows emerge (and screens are added and removed) when talking about these miniframes with the client.

Emil

27 May 2008 - 7:45pm
Uday Gajendar
2007

Love it! This is great advice... Not sure if it is for tightly
sequential situations like install/register/setup UI's, but totally
for something with multiple access points and ways in and out of the
product or application. You gotta start designing somewhere, so might
as well pick a spot and allow for creative ideas to emerge as you work
through it, feeling out the "space". Keeping it lo-fi, sketchy is key
too.

Also really like your use of the word "moments"... like touchpoints in
a product, it evokes a sense of drama, story, emotion, beyond mere
"use cases", but connecting to the human aspect.

Thanks for sharing!

Uday Gajendar
Sr. Interaction Designer
Voice Technology Group
Cisco | San Jose
------------------------------
ugajenda at cisco.com
+1 408 902 2137

On May 27, 2008, at 12:54 PM, Leah Buley wrote:
> even though people may approach it by fits and starts, through weird
> back doors, and in otherwise unpredictable ways.
>
> Starting with the most interesting moment in a process and
> envisioning what that might look like and then brainstorming around
> what hangs off that moment

27 May 2008 - 9:49pm
David Drucker
2008

To plan out every single screen would make the whole enterprise so
dreadfully dull and rigid. For me, it's a lot like music composition
(my previous training). Frequently, the passage/screen at hand will
dictate other riffs/widgets...OK, I'll stop before I get too far afield.

The fact is, some people work better with a carefully worked out plan
done up front, and others prefer to tackle the part that interests
them the most (or perhaps is the key task that must be achieved) first.

-David

--
David Drucker
Vancouver, BC
david at drucker.ca

On 27-May-08, at 12:54 PM, Leah Buley wrote:

> I agree that doing task flows first is probably the standard, but
> I'll play devil's advocate here: you can actually get some pretty
> interesting results by diving right away into super sketchy, lo-fi
> wireframing.
>
> Task flows can sometimes make a process seem linear and sequential
> even though people may approach it by fits and starts, through weird
> back doors, and in otherwise unpredictable ways.
>
> Starting with the most interesting moment in a process and
> envisioning what that might look like and then brainstorming around
> what hangs off that moment -- before, after, and parallel to it --
> can be another good way to start to get your hands around how much
> complexity you're dealing with.
>
> Then on to task flows and more traditional wireframing...
>
> Leah
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=29516
>
>
> ________________________________________________________________
> 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

28 May 2008 - 9:05am
mpullen
2008

Since you are starting a large brand new project you should be doing
some work before flows or wireframes.

*I am going to assume the problem is well defined and the vision of what
is being built is clear for sake of brevity.*

Concept models will help you identify all the things or objects that you
are talking about as well as give the relationships between these
things. Dan did a great presentation at this at the IXDA conference.
"Concept Models: A Tool for Planning Interaction Dan Brown, EightShapes"

When you understand the concepts and their relationships then you can
start sketching out ideas about the whole application or different areas
in the application. These sketches are loose and conceptual so that you
can start the conversation. If any of these sketches are moving in the
right direction for the stakeholders then you can dive a little deeper.

All of this should start to give you a better handle on the problem,
requirements and potential solution.

Now you should be able to talk about areas of the application and flow
between areas. I am not sure you would have detailed workflows at this
point and definitely do not have wireframes. You may be able to look at
some of the overarching navigation at this time.

As you refine the sketches and uncover more requirements to consider
there will come a point where you can start to talk about intra and
interscreen flow. Here you should be able to start high level flow
diagrams to give a sense of coverage.

In my experience wireframing starts after the highlevel framework of
interaction has been straw-modeled and the team is ready to dive into a
particular area of the application. Wireframing starts to illustrate the
layout and content of screens/pages. Doing this too early has been a lot
of wasted time for me in the past. Sketching is much better for
conceptualizing and communicating early on in the process.

My 7 cents,

mTp
Principal Interaction Designer
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
This message is for the named person's use only. This communication is for
informational purposes only and has been obtained from sources believed to
be reliable, but it is not necessarily complete and its accuracy cannot be
guaranteed. It is not intended as an offer or solicitation for the purchase
or sale of any financial instrument or as an official confirmation of any
transaction. Moreover, this material should not be construed to contain any
recommendation regarding, or opinion concerning, any security. It may
contain confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender. You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. Any views expressed in this message are those of the individual
sender, except where the message states otherwise and the sender is
authorized to state them to be the views of any such entity.

Securities products and services provided to Canadian investors are offered
by ITG Canada Corp. (member CIPF and IDA), an affiliate of Investment
Technology Group, Inc.

ITG Inc. and/or its affiliates reserves the right to monitor and archive
all electronic communications through its network.

ITG Inc. Member FINRA, SIPC
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Syndicate content Get the feed