Prototyping with Adobe CS3

8 Jan 2008 - 1:04pm
6 years ago
20 replies
1230 reads
Fred Beecher
2006

Hi all,
Ever since Thermo came out, I've started paying more attention to Adobe
products and their potential for use in rapid prototyping. Previously, I've
thought of these products as being massive, teetering piles of features that
need to be "integrated" (read: "made even more complex") in order to produce
effective prototypes. But the UXP I saw demonstrated in Thermo has wreaked a
little havoc with my prejudices.

Have any of you worked with the trio of Fireworks, Dreamweaver, & Flash to
do rapid prototyping? What is your process like? How do you deal with
printed documentation? How do you make your prototyping "rapid" (i.e., do
you/can you create Visio-like stencils)?

Thanks for any insight,
F.

Comments

8 Jan 2008 - 3:26pm
Miguel Peres
2007

Hi Fred,

In the company I work for, most of the prototyping job is made with flash
and Photoshop. The process generally involves at least a graphic designer
and a simulation designer. The simulation designer is responsible for
analyzing the taskflow developed by the UI designers and determining the
best way to implement it(which is then sent back for the UI designers for
evaluation). After approved, the simulation designer sends a list of graphic
assets that will be needed to the graphic designer and starts prototyping
the application using dummy graphics that can be easily changed later by the
final ones through the flash library.

To get prototyping "rapid" we make use of a custom component library that
act like a set of Visio-stencils and if an interaction needs a component
that is not there, we build it from the ground in an extensible way so it
can be later used in other prototypes. In my personal opinion flash is a
very good tool for prototyping, however, unless you are prototyping basic
"click and go" applications which can be very easily done with a few command
lines, you must have at least one person with strong actionscript skill in
your team to get things done "rapid".

- Miguel

9 Jan 2008 - 9:06am
Fred Beecher
2006

On 1/8/08, Miguel Peres <m.peres at gmail.com> wrote:
>
>
> To get prototyping "rapid" we make use of a custom component library that
> act like a set of Visio-stencils and if an interaction needs a component
> that is not there, we build it from the ground in an extensible way so it
> can be later used in other prototypes.

Cool! That's what I was hoping for!

In my personal opinion flash is a
> very good tool for prototyping, however, unless you are prototyping basic
> "click and go" applications which can be very easily done with a few
> command
> lines, you must have at least one person with strong actionscript skill in
> your team to get things done "rapid".

...aaaand that's what I was afraid of. That's why I haven't gone down this
route before. For prototyping to be truly rapid, the prototype needs to be
strongly tied to the UXP deliverables and it must require little special
knowledge to implement.

I guess I'll just hang out and wait for Thermo to see what that can do for
me. : )

F.

9 Jan 2008 - 10:27am
mtumi
2004

Fireworks CS3 has "rich symbols" and comes with a library of UI
widgets for various platforms. its in "common library", accessible
from the window menu.

there are some articles on prototyping with FW on the site (including
one I wrote).

MT

On Jan 9, 2008, at 9:06 AM, Fred Beecher wrote:

> On 1/8/08, Miguel Peres <m.peres at gmail.com> wrote:
>>
>>
>> To get prototyping "rapid" we make use of a custom component
>> library that
>> act like a set of Visio-stencils and if an interaction needs a
>> component
>> that is not there, we build it from the ground in an extensible
>> way so it
>> can be later used in other prototypes.
>
>
> Cool! That's what I was hoping for!
>
> In my personal opinion flash is a
>> very good tool for prototyping, however, unless you are
>> prototyping basic
>> "click and go" applications which can be very easily done with a few
>> command
>> lines, you must have at least one person with strong actionscript
>> skill in
>> your team to get things done "rapid".
>
>
> ...aaaand that's what I was afraid of. That's why I haven't gone
> down this
> route before. For prototyping to be truly rapid, the prototype
> needs to be
> strongly tied to the UXP deliverables and it must require little
> special
> knowledge to implement.
>
> I guess I'll just hang out and wait for Thermo to see what that can
> do for
> me. : )
>
> F.
> ________________________________________________________________
> *Come to IxDA Interaction08 | Savannah*
> February 8-10, 2008 in Savannah, GA, USA
> Register today: http://interaction08.ixda.org/
>
> ________________________________________________________________
> 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

9 Jan 2008 - 11:38am
bminihan
2007

In my current project, here's the process I followed:
- Loose visual conceptual model of the site and its flow, in Visio
(flowchart boxes on the page, no decoration, notes for myself about what
goes where)
- Rough hand-drawings of major pages that define the experience (free-form,
loose notes and doodles about icons and graphics, some notes about color
themes, font sizes, loose representation of headline-to-body-text
relationship)
- I did a rough wireframe in Visio to emulate my hand-drawings, but quickly
realized I was going to get a lot farther, much faster, with Fireworks (my
favorite design tool)
- I mocked up all of my rough pages in Fireworks CS3. The best thing they
added was the ability to have multiple pages in a single file, with a master
page containing the common header, footer and background. It took me about
a week to go from rough drawings and wireframes to about 15 well-formed
pages with full graphic treatments.
- I dove into dreamweaver to define the basic stylesheet with fonts and
general classes for major blocks, headline tags, and common conventions.
- I created a second Fireworks file to hold common buttons that weren't in
my first mockup, and to preserve the mockup from the slicing I needed to
keep images small (I just need a 1px-wide slice of my background image, so
slicing the mockup would have broken things apart). Again, Fireworks comes
through with button templates, common library elements, and multi-pages (I
have a page for buttons, backgrounds, photos, images, icons, and
"miscellaneous")

As soon as I had anything to share, I showed it to everyone I could. I'm
still planning to schedule sessions with users, but until I get my recruits,
I put the design (in Visio, JPG & DHTML form) in front of potential users
and SMEs).

My developers are about a week behind my prototyping, so I'm beginning to
treat their pages with styles and elements from the DHTML prototype.

I always wind up with an DHTML prototype, because that's the only way I can
confidently define and test the interactions I'll need. In this case, I
redesigned one critical page once I had coded it because I discovered
several ways to make the process more efficient. I couldn't have done that
in Fireworks without a ton of extra effort, but in DHTML, I have to use the
page myself several hundred times a day. Once I have to use it for my own
testing, I'm driven to make it faster and more intuitive.

>From start to finish, total effort was about 3 solid weeks, stretched out
over the past 1.5 months. My developers use "stories" to define experiences
in an agile paired-programming model, so I have found delivering a set of
stories with each prototype helps them see how pages fit together and how
interactions on a page should work. It also lets me define requirements
that were too difficult to prototype but must be included (i.e. if I forgot
to add "remove" buttons to items in a table, my story would be "The teacher
can add a statistic to the table and remove it by clicking the Remove link
next to the item (not represented in prototype)"). I came from an
old-school business-requirements model of working, but this new story-method
is a lot easier and faster. We meet once a day and have a deep dive twice a
week, so I'm sure that's helping as well.

Hope this helps... I haven't tried Thermo yet, but will take a look since
your review =]. My biggest problem with the above is I'm much more
productive once I'm in DHTML mode, so it would be nice to attach CSS styles
and HTML tags to Fireworks symbols, so if you exported a page as HTML it
would get you moving more quickly. Right now you're limited to a kludgy
table-layout export that's a nightmare to rebuild in Dreamweaver (and
disconnects you from your original PNG file).

Bryan
http://www.bryanminihan.com

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Fred
Beecher
Sent: Tuesday, January 08, 2008 1:05 PM
To: IxDA Discuss
Subject: [IxDA Discuss] Prototyping with Adobe CS3

Hi all,
Ever since Thermo came out, I've started paying more attention to Adobe
products and their potential for use in rapid prototyping. Previously, I've
thought of these products as being massive, teetering piles of features that
need to be "integrated" (read: "made even more complex") in order to produce
effective prototypes. But the UXP I saw demonstrated in Thermo has wreaked a
little havoc with my prejudices.

Have any of you worked with the trio of Fireworks, Dreamweaver, & Flash to
do rapid prototyping? What is your process like? How do you deal with
printed documentation? How do you make your prototyping "rapid" (i.e., do
you/can you create Visio-like stencils)?

Thanks for any insight,
F.
________________________________________________________________
*Come to IxDA Interaction08 | Savannah*
February 8-10, 2008 in Savannah, GA, USA
Register today: http://interaction08.ixda.org/

________________________________________________________________
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

9 Jan 2008 - 12:50pm
kimbieler
2007

I hope this isn't a dumb question, but are there any prototyping
tools (Visio, Axure, Fireworks, etc.) that actually give you a usable
website at the end? I'm just wondering if it's worth spending the
time applying all this functionality to a prototype, if it's all
going to have to be re-coded afterwards.

-- Kim

+ + + + + + + + + + + + + + + + + +
Kim Bieler Graphic Design
www.kbgd.com
c. 240-476-3129
+ + + + + + + + + + + + + + + + + +

9 Jan 2008 - 4:38pm
Vishal Subraman...
2005

HTML/ CSS / JS will be your best bet for production ready code. Even a
tool like Dreamweaver tends to add unnecessary code.

As far as your second Q is concerned- there is space for a prototype
only tool. If you're building a small 10 page website (or a simple
tool), maybe not so much...but for complicated ones its a different
story. The trade-off here is that of complexity & domain expertise.
Production ready code is not easy to automate and I'd rather not be
pixel pushing when I'm working on a design problem.

One approach would be to have the front-end developers within the
design team as opposed to the dev. Dunno how they would feel about it,
but its great from a UX perspective because of better control of the
product (esp when the UX & dev don't report into the same manager, as
is common in most large orgs)

> I hope this isn't a dumb question, but are there any prototyping
> tools (Visio, Axure, Fireworks, etc.) that actually give you a usable
> website at the end? I'm just wondering if it's worth spending the
> time applying all this functionality to a prototype, if it's all
> going to have to be re-coded afterwards.

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

9 Jan 2008 - 4:45pm
Fred Beecher
2006

On 1/9/08, Kim Bieler <kimbieler at mindspring.com> wrote:
>
> I hope this isn't a dumb question, but are there any prototyping
> tools (Visio, Axure, Fireworks, etc.) that actually give you a usable
> website at the end? I'm just wondering if it's worth spending the
> time applying all this functionality to a prototype, if it's all
> going to have to be re-coded afterwards.

Well, Thermo will fit your bill there, if you're trying to make a Flash/Flex
site. But it hasn't been released yet, so...

But I want to bring up another point... I think it's very important that a
prototype *not* be turned into the functional site. In a prototype, you
really shouldn't be building all sorts of functionality. You should be
faking it. Changing design takes so much less time and money than changing
functional code that to intend a prototype for eventual production negates
the money-saving value of prototyping.

F.

9 Jan 2008 - 4:52pm
Nathan Curtis
2007

Fred,

While we've worked sparingly with Fireworks, Dreamweaver, and Flash, EightShapes has had considerable success utilizing Adobe InDesign CS3 for rapid wireframing, prototyping, and specifications of large-scale design systems. Key InDesign CS3 features that enable a scalable build-out of reusable assets:

* Modularity of Placing/Linking Files (you can place, crop, and show/hide layers in one InDesign file into another InDesign file, retain/manage the linkage between the two, and even create multi-level, hierarchical linked relationships)
* Snippets (distinct files for each reusable wireframing component or documentation pattern, which you can visually browse in Adobe Bridge and drag-and-drop into your artwork or document)
* Object Libraries (equivalent in many ways to Visio's stencils)
* PDF Interactivity (create links, hovers, and other dynamic behaviors that enable you to mimic a moderate amount of interaction, whether utilizing placed wireframes, mockups, or both)

How do we deal with printing? With InDesign, producing printable documents is it's fundamental purpose. Thus, we've created a similar layer of modular documentation template assets to go with the wireframing system.

How we make our process rapid? Well, wireframing and mockups becomes drag-and-drop (-and-revise if unique or needing defined content) from the component library, production of prototypes and deliverables becomes a process of linking those wireframe / mockup files with 1 documents to export to PDF. Additionally, for prototyping, we've got a relatively straightforward set of objects that enable us to link artwork together, produce common hovers ( e.g., balloon), and also create standard previous/next pagination through documents.

In fact, our internal success has led us to opportunities to build out documentation & wireframing solutions for every client with large UX teams that we work with. Though reliant on a moderately mature design system, having between 100-300 components of your design system easily reusable creates vast efficiencies and consistencies for both output of the design process as well as the experience overall.

--

Nathan Curtis
Principal, EightShapes LLC

e: nathan@eightshapes.com
w: http://www.eightshapes.com/
p: 703.296.8831

9 Jan 2008 - 5:06pm
bminihan
2007

I agree re: Dreamweaver. It seems the least offensive in terms of code, but
after 6 years using it, I still can't use its WYSYWIG design editor for
anything predictable. Its best features are the ability to expand and
collapse chunks of HTML (or any container) to copy and move them around, its
recognition of many (not all) common accessibility gaps (no ALTs, etc) and
file management.

As far as "production-ready prototypes", I agree that no matter how finished
my prototypes are, the code is merely a suggestion and cheats at all sorts
of things to illustrate flow. Occasionally I'll deliver small snippets that
solve a problem the developer can't manage, but that's rare.

I know I'm late to the "scriptaculous" bandwagon, but I just realized the
other day it has several VERY convenient tools for DHTML prototyping that
emulate data entry behaviors that otherwise take awhile to "fake". It
doesn't do everything, and much of what I do doesn't require sliding boxes
and drag & drop, but I'm a fan of it for easing some tedious prototyping
tasks (showing/hiding stuff & emulating form field editing).

Bryan
http://www.bryanminihan.com

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Vishal
Iyer

HTML/ CSS / JS will be your best bet for production ready code. Even a
tool like Dreamweaver tends to add unnecessary code.

As far as your second Q is concerned- there is space for a prototype
only tool. If you're building a small 10 page website (or a simple
tool), maybe not so much...but for complicated ones its a different
story. The trade-off here is that of complexity & domain expertise.
Production ready code is not easy to automate and I'd rather not be
pixel pushing when I'm working on a design problem.

One approach would be to have the front-end developers within the
design team as opposed to the dev. Dunno how they would feel about it,
but its great from a UX perspective because of better control of the
product (esp when the UX & dev don't report into the same manager, as
is common in most large orgs)

-Vishal
http://www.vishaliyer.com

9 Jan 2008 - 5:54pm
Matthew Nolker
2008

Many of the Agile development teams I've seen (that are smart enough
to make an interaction designer a core part of the software
development team) move in the same direction Bryan has. The basic
principle that seems to work best is that the design will be
specified in a format that developers can use. So if it's a
Rails/Ajax application, they're doing their design exploration and
prototyping in dHTML. If the front end is flash, then that is what
the prototype and design are executed in as well.

I've personally tried many the intermediary steps like the Adobe
products or modeling tools like Caretta or iRise, but eventually
concluded that there wasn't enough spare time to execute 100% throw
away prototypes on Agile projects.

I also haven't found the single tool that a designer can use to turn
a prototype into a working web application. For some CRUD
applications, I've recently seen situations where an interaction
designer paired with Rails developer produced an amazingly rich
prototype in about 2-3 weeks. In several of those cases, much of the
prototype code base survived into the actual production application.

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

9 Jan 2008 - 7:21pm
Fred Beecher
2006

On Wed, 9 Jan 2008 14:54:26, Matthew Nolker <mnolker at pathf.com> wrote:
>
>
> I've personally tried many the intermediary steps like the Adobe
> products or modeling tools like Caretta or iRise, but eventually
> concluded that there wasn't enough spare time to execute 100% throw
> away prototypes on Agile projects.

While I haven't had the chance yet to do UCD as part of an Agile process, I
have always imagined that a rapid prototype would exist alongside but
separate from the production code. This prototype would be maybe one or two
iterations ahead of the production code, but otherwise would still follow
the same cycle as the code (e.g., one-month iterations... I actually talked
with some folks last night who work this way). This prototype would be
maintained by the UCD person/staff and used exclusively to test interactions
before they went into development.

This situation necessitates the use of some sort of rapid prototyping tool.
I've used Axure for a couple of years now, and while it grows more complex
with every release, it is still simple enough that a non-coding UCD person
can make effective prototypes that yield accurate data in testing. The
rapidity of a tool like this is what makes a throwaway prototype in an Agile
environment possible. Developing a wireframe in Axure doesn't take any more
time than doing so in Visio... the only thing that requires more time is
making the wireframe interactive.

Personally, I strongly believe that prototypes should be throwaway due to
the cost savings of avoiding re-work after code has already been written.
This leaves the designers free to experiment with different interactions
with impunity. Changing design is quick, easy and cheap. If I find a novel
interaction doesn't work, no big deal. I can quickly come up with, prototype
and test a different idea... one that integrates what I've learned from the
previous failure. If I had to work with a developer in order to actually
code this (or, horror of horrors, code it myself) it would take much longer
and be more expensive. Not only would it take my time, but a developer's as
well.

- Fred

9 Jan 2008 - 7:29pm
Matt Attaway
2004

I'm working on a desktop application right now and using Flex/Flash
to prototype it. My process is definitely a work in progress, but so
far it is:

1) Sketch out initial ideas on paper
2) Pop into Flex and create initial dialog/window designs in the
WYSIWYG editor

At this point I have something that looks like the window, but isn't
interactive.

3) Bust out Actionscript and hook up the widgets and fake the
behavior.

At this point I (hopefully) have walking, talking documentation.

The thing I like about Flex is it pretty easy to create different
test cases by swapping out the XML data. My hope is that these
prototypes can be documentation for the developers and also provide
something tangible for stakeholders to look at. I like the fact that
I can easily share the prototype by sticking a .swf on a web server
somewhere.

Flex is also nice for creating simple paper prototypes. The design
tool in Flex is very pleasant to use and has most of the basic GUI
patterns covered, so to create a new paper prototype I just draw what
I need, throw together an XML file with the test data, open the swf
in a browser, and hit print. I haven't figured out a way to use Flex
for printed documentation; our design doc is a wiki so I just embed
links in the wiki to the appropriate prototype.

Flex lets you create your own re-usable components, so you can build
a library of specialized parts. This definitely speeds up prototyping
once you get them all setup.

The big downside to Flex is if you want more than pretty pictures you
really do need to know Actionscript. If you can code though Flex is
pretty great. This whole Flex based process is new to me and the
company I work for. I'll do a post-mortem on it once we ship. =)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://gamma.ixda.org/discuss?post=24306

10 Jan 2008 - 12:23am
Matthew Nolker
2008

> While I haven't had the chance yet to do UCD as part of an Agile process, I
> have always imagined that a rapid prototype would exist alongside but
> separate from the production code. This prototype would be maybe one or two
> iterations ahead of the production code, but otherwise would still follow
> the same cycle as the code (e.g., one-month iterations... I actually talked
> with some folks last night who work this way). This prototype would be
> maintained by the UCD person/staff and used exclusively to test interactions
> before they went into development.

I've certainly done it that way too, and it works pretty well. But there is also incredible value to wearing many hats in a Agile process. If your Agile cycle is two weeks and you hand over a design model in a proprietary format, someone has to turn the model into UI code. You could pull a developer off of their task to work on the presentation code... or you could do it yourself. And then after you've gone through the cycle of converting from model to presentation code a few times, you often find you're almost as fast executing new designs in the code as you are with the model. At least, that's the trend I'm starting to see. Not that it happens for anyone overnight, or that it works out in every case (interfaces where the javascript is actually all java compiled via GWT come to mind), but when it does work it's a very nice thing. Cuts down on the documentation tremendously (want to know what the visual specifications are? read my css, baby). The developers love it. And since you're also a productive UI developer, there is less pressure to move you off the project when the interaction design is stabilized -- and I can't count the number of times where developers have started freelancing the UI because circumstances required some big change and the interaction designer rolled off 3 months ago.

(Thanks for the tip on Axure. We still use prototyping tools on projects where Agile isn't appropriate and for some Agile stuff too. And I hadn't checked that one out.)

10 Jan 2008 - 9:07am
Adrian Howard
2005

On 9 Jan 2008, at 14:54, Matthew Nolker wrote:

> Many of the Agile development teams I've seen (that are smart enough
> to make an interaction designer a core part of the software
> development team) move in the same direction Bryan has. The basic
> principle that seems to work best is that the design will be
> specified in a format that developers can use.
[snip]

I too have seen this working very well. With very occasional
exceptions[1] I don't produce any sort of "functional" or hi-fi
prototypes. Everything happens on the implementation platform. This
includes tools and domain-specific languages to help the designers
more effectively work on that platform.

Lots of lo-fi work (Paper prototypes, white boards, post-it notes,
etc.) and being in the same room as everybody else handles one part
of the testing/communication tasks the artefacts/documentation used
to handle.

Having a bunch of good development practices in an environment adapt
at handling change giving a very rapid turn around when implementing
new features copes with the situations I would previously have used
functional prototypes.

Seems to work well.

Cheers,

Adrian

[1] Basically when it is a _lot_ faster to prototype something for
user testing in something else, rather than create it using the
implementation platform. This happens very infrequently for me (I
mostly live in the web development domain, so this may be easier for
me than it is for some other folk.)

10 Jan 2008 - 9:23am
Todd Warfel
2003

On Jan 10, 2008, at 12:23 AM, Matt Nolker wrote:

> If your Agile cycle is two weeks and you hand over a design model in
> a proprietary format, someone has to turn the model into UI code.

Here's a question for you Agiler's—where does prototyping fit into the
Agile process? And what type of prototyping do you typically do, or
feel is most effective for the Agile process? What about Scrum?

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.

10 Jan 2008 - 9:23am
Adrian Howard
2005

On 9 Jan 2008, at 21:45, Fred Beecher wrote:
[snip]
> But I want to bring up another point... I think it's very important
> that a
> prototype *not* be turned into the functional site. In a prototype,
> you
> really shouldn't be building all sorts of functionality. You should be
> faking it. Changing design takes so much less time and money than
> changing
> functional code that to intend a prototype for eventual production
> negates
> the money-saving value of prototyping.
[snip]

I have to admit I don't really find this an issue (with developing
web applications anyway - which is where I spend most of my time). I
used to work at three levels

a) Low-fi work (paper prototypes, whiteboard sketches, etc.)
b) Prototypes (functional prototypes, hi-fi visuals, etc.)
c) Production ("real" code)

These days I find that (b) has been mostly squeezed out between (a)
and (c).

* I do more testing / communication work with (a) which is even cheaper.
* Development is throwing out new demoable releases on a regular
basis, which reassures everybody that real progress is being made in
the right direction - getting rid of another reason why I used to
build more functional prototypes.
* I'm working with developers that have adopted some really neat
technologies and development practices (mostly from the agile world)
that means they can produce quality code quickly and easily without a
lot (if any) of wasted work.
* Working with the developers, rather than producing prototypes off
by myself, means that the developers naturally pick up more of the
"whys" behind the design - making the whole development process easier.

As ever YMMV :-)

Cheers,

Adrian

10 Jan 2008 - 9:38am
mtumi
2004

For me, I can't say that it does very much. That's part of the
reason I'm headed down to interaction 08 - for the agile/uxd workshop.

Currently the extent to which it is part of the scrum process is that
for a more complicated feature, I will take the sprint prior to the
development sprint to work out design questions so the developers
have a clear idea what they are doing when they start. So far this
has just involved UI mockups and requirements/functional specs. It
sometimes has some aspects of a technical spec as well, for example
detailing the format of an xml document they will need to generate.
For larger endeavors than any we have taken on so far, I imagine
prototypes will be involved.

I am very interested in getting a better idea of how design can
become more integrated with the process. I have (geekily) been
looking forward to the workshop for months for this reason. :-)

MT

On Jan 10, 2008, at 9:23 AM, Todd Zaki Warfel wrote:

>
> On Jan 10, 2008, at 12:23 AM, Matt Nolker wrote:
>
>> If your Agile cycle is two weeks and you hand over a design model in
>> a proprietary format, someone has to turn the model into UI code.
>
> Here's a question for you Agiler's—where does prototyping fit into the
> Agile process? And what type of prototyping do you typically do, or
> feel is most effective for the Agile process? What about Scrum?
>
>
> 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.
>
> ________________________________________________________________
> *Come to IxDA Interaction08 | Savannah*
> February 8-10, 2008 in Savannah, GA, USA
> Register today: http://interaction08.ixda.org/
>
> ________________________________________________________________
> 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

10 Jan 2008 - 9:46am
Todd Warfel
2003

On Jan 10, 2008, at 9:38 AM, Michael Tuminello wrote:

> For me, I can't say that it does very much. That's part of the
> reason I'm headed down to interaction 08 - for the agile/uxd workshop.

So, how would you see it fitting into Agile if you could have it your
ideal way?

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.

10 Jan 2008 - 10:15am
mtumi
2004

trying to put me on the spot? :-)

I'm not really sure, to be frank. I'd be interested to talk more
about it, particularly with people more knowledgeable than I am. If
I think about it in a textbook sense I imagine there being nice
little iterative circles where each sprint involved some amount of
design, testing with prototypes and then concurrent building of
aspects of the design that have already been validated. In reality,
I am not sure you could get all this going at once - you might have
to alternate sprints, where one is focused more on design and
prototyping and the next on moving development forward. Or maybe if
you are designing something for web delivery, the future model is
something like what 37 signals proposes - where you are making it
available to the public as you build it and incorporating feedback as
it is received.

I think that the tools we have had to date have not readily lent
themselves to simultaneous revision of design and the code, and I
think that will change moving forward with the introduction of tools
like Thermo, and perhaps Blend (I'm not that familiar with it).

I'm sure some people will roll their eyes at the idea of
simultaneously revising design and code, as this has obviously
proven to be a bad idea in many instances. I think it can work if
you are refining the design as you move forward, rather than changing
it.

Anyway, hopefully I will be smarter after the conference. :-) I am
sure there are some other people on this list who have more to
contribute on this topic.

I poked around for a bit in the list archives and found this one
article posted earlier by Desiree Sy:
http://upassoc.org/upa_publications/jus/2007may/agile-ucd.html

MT

On Jan 10, 2008, at 9:46 AM, Todd Zaki Warfel wrote:

> On Jan 10, 2008, at 9:38 AM, Michael Tuminello wrote:
>
>> For me, I can't say that it does very much. That's part of the
>> reason I'm headed down to interaction 08 - for the agile/uxd
>> workshop.
>
> So, how would you see it fitting into Agile if you could have it
> your ideal way?
>
>
> 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.
>

10 Jan 2008 - 11:38am
Sarah Kampman
2008

I've been designing within the Agile/Scrum process for several years
now. In my experience, it depends on the uniqueness of the feature in
question.

If it's just another report submission page, for instance, the
developers are usually happy with just a text listing of what's
different, or perhaps a last-minute sketch on paper or a whiteboard.

If it's a new kind of report, or a wizard, or some other non-trivial
feature that doesn't have a twin within the existing software, I'll
do a paper mockup one or two iterations ahead of time, and will do a
DHTML mockup if there's any confusion about interaction points or
flow. I've found that the process of creating and approving the
mockup nearly always results in the discovery of a technical
obstacle, an unconsidered change elsewhere, or realization from the
product owner that the feature they've asked for isn't the one they
wanted. So although the mockup itself is often possible to accomplish
within an iteration, the other questions it raises need time to be
properly addressed.

If it's a radically new feature (e.g., introduction of spreadsheet
entering into a formerly forms-only interface, or a redesign of the
entire navigation system), I'll do paper mockups, DHTML prototypes,
and an early round of usability testing before the release planning
even begins. Those changes require buy-in from all of the product
owners, and usually the executive team, and have no business being in
development's queue until everyone is in agreement that the feature
appropriately solves the strategic goals. Once the feature and its
design are approved, only minor elaboration is needed during the
development iterations.

-Sarah Kampman

-----Original Message-----
Here's a question for you Agiler's%u2014where does prototyping fit
into the Agile process? And what type of prototyping do you typically
do, or feel is most effective for the Agile process? What about Scrum?

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

Syndicate content Get the feed