[IxDA Discuss] What do these prototyping tools give me? (RE: Axure RP Pro prototyping tool)

Sat May 13 20:30:54 PDT 2006

[Long]
Dave & Todd,

What are you missing:
I think you're missing the environment in which the need for a tool like
this arises.  Todd points at this with "when these are appropriate".  When
and where.  I don't know if you've ever worked in place where it's
relevant.  Our company is a huge ecommerce retailer.  We have projects that
support our ecommerce strategy, pet projects, maintenance needs,
multichannel projects, and a few large initiatives with outside vendors.
Our ecommerce team who works on these projects:  We have 7 web project
managers, none of whom have web experience.  (One of them has done technical
writing.)  We have one user experience person who does functional specs,
wireframes, usability testing.  We have one designer who has a background in
graphic design & advertising, but not web or interaction design.  Our
company is a textbook case for iRise.  We have so little definition,
conceptualization, and so many useless text documents, that we end up buried
in rework. We have a few more than nine managers, executives, and product
owners who want work done all the time.

 Prototyping tool:
iRise has a 'server' (read, engine, as it's software) that sits on a
networked computer or an actual server.  It has licenses for 'Studio' that
sit on the users' local machines.  It has another 'Manager' piece for
requirements management.  It has two ways for non-studio users to view it:
'Reader' is a license for internal people who will use it regularly;
and 'iDoc' is the free reader that let's people view it for free inside or
out of your company - onshore or off.  Reader & iDoc let you view the entire
simulation and give feedback on it.  Reader & iDoc simply present the
simulation in your browser.  iDoc is also the name of the file that you send
out for others to view.

Maintainable objects:
The Studio has Scenarios, Pages, Templates (for pages), Masters (sorta
like templates for elements & objects), Decisions, and Datasheets.  You
start by building scenarios in a whiteboard.  Scenarios consist of Pages and
Decisions.  Pages are built with elements - design elements, functional
elements, and data elements.  Templates typically have design & functional
elements, usually in a specific array/layout.  Masters are good for
functional elements, as you can reuse them on different templates.
Decisions help you make choices for navigation, user validation or
segmentation, calculations, and a few other things that depend on your
ability to imagine contingent relationships.  Datasheets let you store,
access, update, delete records.  Putting Decisions and Datasheets together
is where iRise really excels.  That's where data elements come into play.
iDocs also become the currency for archiving and sharing objects with
others.  For instance, like a developer could share lines of code in
NotePad, I can save Decisions & Datasheets that solve a particular problem
with another user.

Sharing & Annotating:
Studio users can share things via the server, shared projects, or by sending
someone a private project.  Shared projects live on the shared server.
Private projects live on your local machine (with studio).  Designers can
share projects with non-studio users by (clicking a button to) produce an
iDoc.  The iDoc goes out by email (it's in the hundred KB range for big
simulations) or on shareable media or drives.  The recipient opens the iDoc
in with either a Reader license or with the free download iDoc Reader.  Just
to repeat an important point:   The viewer goes through the simulation - the
whole simulation - with the iDoc.  The iDoc has the simulation and the
document mentioned before.  The viewer can make comments (a la PowerPoint or
Adobe Acrobat) in the Simulation or document.
[I laughed after reading: *If it isn't in something like PDF, HTML, SWF, or
DOC, then I can't be bothered with it.  *Is it that four is your limit?
What about MP3, JPG, GIF, or EXE?  How is not *something like* those, if
they're all extensions for filetypes?]
Special Example:  For usability testing, we simply open the simulation in a
browser using a Reader license on the test machine.  We run Morae to record
the test session.

Converting prototypes to something useful (by Dev & QC):
So, these are simulations (iRise dogma), not simply prototypes.  One
potential distinction, we could build a simulation for a new checkout webapp
that works as the live site could, including data operations.  A difference
in the recipient is that they have more technical prowess and interest than
some others.  Does this simulation supply code?  No.  It does let them see
and use and do what you want the user to see and use and do.  Maybe QC would
use it for forecasting or preliminary analysis, but not for rigorous
systems-based evaluations.  (I don't know the role of your QC group.  I'm
thinking about load-testing and running this on beta servers for extended
evaluation concurrent to other system changes and data pushes.)

Requirements gathering:
Maybe I don't understand what you use and need for requirements gathering.
For us, the requirements gathering method is heavy text documentation.  That
doesn't work as well as prototypes.  We noticed that iRise simulations work
far better than the text documents, and are faster, easier, better than the
prototypes we can build with current resource supply & demand.
Requirements "gathering" to me means 'figure out what to build, given what's
possible, what you're capable of, and how much time & money are on the
table'.  It's not 'describe in detail what happens when user clicks
<widget>'.

Maintenance:
Maintaining iRise? Or, maintaining projects that take a long time?
Maintaining iRise is based on the basic question of maintaining any
prototyping tool.  For example, how long will this company last?  How many
updates will they make?  What is their R&D budget?  Do they listen to the
requests & comments I make.  We evaluated those and chose iRise.  Visio's
not going anywhere fast.  Axure doesn't meet our needs for data transactions
and doesn't' intend to (based on their rep's comments at the time).  Serena
wants to sell us other stuff, tells us we shouldn't use the tool to do
certain things with data, and didn't want to discuss future development with
us.  It'd take me longer to learn Adobe/MM tools to the desired level of
proficiency than it would take me to learn iRise.
Maintaining projects begs the question that you'd be working on this
project as long with iRise as you have with your current tools.  Ha!  Sorry,
it was open, had to take it.  It actually isn't clear to me if the project
you mention suffers from scope creep, poor conceptual framework, or you mean
it's a system that needs long term maintenance.  If it's scope creep or poor
concepts, then iRise could help you by letting you work things out in more
detail and faster.  If it's a system you're maintaining, then I think of
something like using the Templates & Masters I mentioned earlier.  Those can
be saved and reused across projects.  For instance, I can just as easily
save a set of Templates in an iDoc and send them to a colleague, as I can
save a full simulation.  Also, projects can be archived - both private and
shared - for later use.

I hope this helps clear things up.  If I see you at another summit or
conference, I'm happy to show it to you.
Jay

On 5/11/06, Todd Warfel <lists at toddwarfel.com> wrote:
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> I think another thing that's missing is when these are appropriate.
> For instance, in Dave's case if he's got 5 Designers that are
> familiar w/Adobe and MM tools, then why switch to something like
> Axure or iRise? There's the initial expense. Then the learning curve
> and downtime (soft costs).
>
> Who's going to use or consume the output? There's a mention of a
> "free reader," but frankly, I don't want or need another free reader
> and don't want to make our clients download a free reader. If it
> isn't in something like PDF, HTML, SWF, or DOC, then I can't be
> bothered with it.
>
> From all that I've gathered so far, these are decent requirements
> gathering tools, but you'd be better off prototyping on paper or with
> Flash/HTML.
>
> What about ongoing maintenance? Some of our projects have been
> running for 1.5 years or more. There's been some changes. Maintenance
> is a big issue for us.
>
> On May 10, 2006, at 11:22 PM, David Heller wrote:
>
> > [Please voluntarily trim replies to include only relevant quoted
> > material.]
> >
> > If people concede the point about these tools not working well as a
> > conversion prototype > word platform (which is what I'm hearing),
> > and then
> > it is just about prototyping, then ... Why these tools?
> > What do they offer that another development environment doesn't? I
> > mean
> > iRise and Serena have pretty heft licensing costs. That is pretty
> > hard to
> > justify when I can great prototypes in Dreamweaver or Flash or Flex
> > 2.0 or
> > the upcoming tools in the Expression Suite from MS, just as easily.
> >
> > What am I missing here? Seriously, I'm about to head into a HUGE
> > hosted
> > enterprise application re-design, and I'd really like to know what I'm
> > missing out on. I've looked at these tools, but a separate Wiki for
> > gathering requirements + Dreamweaver seem to be working fine. So
> > I'm really
> > curious about this. $10k for a $5m project doesn't seem like a lot
> > to ask
> > for, but it is still $10k .. But compare that to $5k for 5 licenses of
> > Studio 8 by Adobe, and I just don't see the cost benefit analysis.
> > Help me!
> >
> > Aspects that people didn't talk about are:
> > Maintainable objects
> > Sharing across teams, and within a team
> > Annotating (was sorta mentioned)
> > Converting prototypes to something consumable by other teams (Dev &
> > QC jump
> > to mind).
> >
> > I think Jay hit one requirement on the head and that is being able
> > to create
> > data sets to be used for usability testing.
> >
> > -- dave
> >
> >
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://listguide.ixda.org/
> > List Help .................. http://listhelp.ixda.org/
> > (Un)Subscription Options ... http://subscription-options.ixda.org/
> > Announcements List ......... http://subscribe-announce.ixda.org/
> > Questions .................. lists at ixda.org
> > Home ....................... http://ixda.org/
> > Resource Library ........... http://resources.ixda.org
> >
> >
>
>
> Cheers!
>
> Todd R. Warfel
> Partner, Design & Usability Specialist
> Messagefirst | designing and usability consulting
> --------------------------------------
> Contact Info
> Voice:    (607) 339-9640
> 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.
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

-- 
_________________________________
Jay A. Morgan
jayamorgan at gmail.com