True or False: In a perfect world we'd all create html clickable wireframes after the static ones have been don

1 Oct 2007 - 2:43am
6 years ago
13 replies
622 reads
Jim Leftwich
2004

This seems to be a never-ending discussion, regarding methods of
design and development. I contract to have certain system/apps that
I've designed prototyped, but certainly not all nor even the majority.

I work on wireframes, graphical layouts and keyframes, intensive
flows, and comprehensive implementation documentation, and have done
so for numerous OS GUIs (starting back in the 80s), lots of medical
equipment and devices, complex military systems, and so many mobile
device, phone, smartphone, and media players that I can't even count
them. And I've envisioned and designed the entire dynamic experience
architectures and the layout of every screen, menu, sequential
pathway, and the general rules for extension and further development
in my head and then documented.

Many times in my career, the programmers implementing my interaction
design and interfaces have been remote, or have done all the
implementation afterward. I don't do websites, but this has included
lots of very complex systems and even some that had many different
types of applications within an overall OS application framework
(that I also designed).

If I'd mocked up or made interactive every thing I've designed since
1983, it would've taken much longer and would've taken time away from
intense detailing and functional management that I spent my time on
instead.

Nowadays, I and my partners will often have portions mocked up and
made interactive, mostly for show to our clients or execs while
implementation is underway. No engineers I work with would prefer to
have interactive models _in lieu of_ the kinds of implementational
documentation I've traditionally provided.

So mileage varies, and many of us that have been working in this
field for decades have developed a number of highly leveraging
methods for getting more designed faster, and implemented with
rigorous detail and consistency.

None of my most successful products and software were interactively
prototyped. If you know it and can see it in your head (upside down,
backward, and in every dimension dynamically), you can document it in
such a way that when it's implemented, it will be just as conceived.
Work out the details on paper, and learn to communicate with massive
detail (and in my projects, considerable attention to generalized
rules and patterns), and you'll do fine.

Don't ever let anyone tell you that there's only one way, or a best
way to design interaction. It's just not true.

Jim

-------------------------------
James Leftwich, IDSA
Orbit Interaction
Palo Alto, CA
jleft at orbitnet.com
http://www.orbitnet.com

> From: davewalker at interfacevisuals.com
> Date: September 28, 2007 3:45:30 PM PDT
> To: "Dan Saffer" <dan at odannyboy.com>, "IxDA Discuss"
> <discuss at lists.interactiondesigners.com>
> Subject: Re: [IxDA Discuss] True or False: In a perfect world we'd
> all create html clickable wireframes after the static ones have
> been done
>
>
> I agree that wireframes are useful. I also think that prototypes
> are critical if we are to advance our trade. I use my own
> wireframes to build working prototypes, because I need the
> discipline that comes from doing the wireframe. Prototypes are a
> lot of work and that work can be wasted if you haven't already put
> process behind it.
> This is especially true if you are delivering XAML directly to a
> dev team. The XAML can be a prototype, but because it is also the
> actual design, wireframes help refine the vision before creating
> the XAML. Wireframes are a lot easier and it's just easier to toss
> my darlings into the wastebin and start over. If I go directly to
> the XAML, inevitably I invest too much and I try to hard to rescue
> early explorations from the cutting floor.
> Dave
>
>> -----Original Message-----
>> From: Dan Saffer [mailto:dan at odannyboy.com]
>> Sent: Friday, August 31, 2007 05:59 PM
>> To: 'IxDA Discuss'
>> Subject: Re: [IxDA Discuss] True or False: In a perfect world we'd
>> all create html clickable wireframes after the static ones have
>> been done
>>
>>
>> On Aug 31, 2007, at 2:15 PM, Victor Lombardi wrote:
>>
>>> Andrei wrote:
>>>
>>> RE>I think one has to build a functioning prototype of what you
>>> design for any project...
>>>
>>> Amen. Wireframes follow a workflow that architects use that is
>>> inappropriate for what we do. As the Henry Dreyfuss quote
>>> illustrates, industrial design is a much better metaphor. Industrial
>>> designers have 'works-like' prototypes and 'looks-like'
>>> prototypes, but non-interactive wireframes are neither, and lacking
>>> vital usefulness.
>>
>> Really? In the world I live in, where I don't always get to hook up
>> prototypes to live databases and where I have neither the time nor
>> resources to build prototypes that replicate every use case I can
>> think of, wireframes are still important. Why? Because they can
>> document detail that a prototype, unless it is absolutely working
>> (which is to say, it is the final product) cannot. I can also link
>> decisions in a design to earlier decisions and show how logic flows
>> within an application in a way that is not apparent in a prototype.
>> Unlike analog objects made by industrial designers, the "works-like"
>> prototypes to demonstrate digital behavior are extremely challenging.
>> I'd argue that is what wireframes really are: the "works-like"
>> prototypes.
>>
>>
>>> there's no reason to keep using static diagramming tools.
>>>
>>> 2007 should be the year the wireframe dies.
>>>
>>
>> Actually, there are a lot of reasons. Paper has been shown time and
>> time again to be an excellent communication tool. The time it takes
>> to diagram (and revise that diagram) on paper is considerably less
>> than the time it would take to mock it up (unless we're talking some
>> really basic product). Paper is easily transportable and simple to
>> edit and draw on. On paper, unlike a prototype, I can document:
>>
>> - Logic flows
>> - Constraints
>> - Conditional states and their triggers
>> - Changes to the design over time
>> - Notes on the hows and whys something is to be built to the
>> developers/engineers/industrial and graphic designers.
>>
>> Paper documents can be read of sit beside my teammates as they
>> work to make my design a reality without forcing them to launch a
>> prototype and have to re-engineer it themselves from what they are
>> seeing. Wireframes show how a product is to be built--information
>> that can be used to build a prototype as well. But digital products
>> are no better than another product--and perhaps worse than analog
>> ones--in that you can't see what the constraints and specifications
>> are from simply looking at a prototype of a final product.
>>
>> In my mind, wireframes and prototypes are two sides of the same coin.
>> Both serve different purposes and one shouldn't substitute for the
>> other, except in some cases. Both are important and I'd never confuse
>> one for the other, or substitute one for the other if I could help
>> it.
>>
>> Dan
>>
>> ps. I do know that there are some people who do hybrids--mixing a
>> prototype with annotations. That is kind of cool.

Comments

1 Oct 2007 - 4:38am
Dave Malouf
2005

Hi James, I find this interesting coming from you. Maybe, I'm just
stereotyping here, but since your background is so intermingled with
with Industrial Design I'm really surprised that you don't think
that an interactive prototype isn't necessary, I mean, not as a
communication tool, but as a design tool and a communication tool.

The question that sprung to mind in this thread for me, is that I
can't imagine any one of the IDs I would for NOT delivering an
appearance model WITH their 3D digital assets (which btw are done in
the same software that the mechanical engineers work in). So while it
is completely "specified", many stakeholders and just for the
purposes of design iteration need to see the appearance model.

For people less connected to the ID world. An appearance model is
practically indistinguishable from the final product when looking at
it and touching it. Even the buttons work as prescribed. It just
lacks electronics (even this is changing w/ the advent of cheap
technologies). My favorite aspect is that it is usually weighted
realistically as well.

I just can't see how we can do our jobs as effectively w/o having
these equivalent appearance models.

One of the issues I see facing the IxDer long term is that we have
taken the road of "director" instead of builder. Unlike most
designers we actually don't build anything. We don't show the
customer something that tells them, "Oh! so this is what I spent all
that money on." I believe this is a huge evangelism failing of ours
in our history and is something that we need to change in our "best
practices" moving forward. Interactive prototypes are a key to this.

-- dave

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the improved ixda.org
http://beta.ixda.org/discuss?post=19994

1 Oct 2007 - 5:17am
Dave Malouf
2005

I see in Jim's email the piece about the level of detail in his
specifications. Detail is important indeed.

But I wonder if we had tools that were good enough so that the time
and energy it took to do that level of specification is the same
amount of time it would take to just build it, then we wouldn't need
to specify it?

Like the other David, I'm doing a project in Blend right now and our
goal is to really concentrate more energy on building usable code than
for creating documentation. Now since this is a 1.0 product, we'll
see how it all pans out, but we already know that a standard designer
with even basic Flash level programming skills isn't enough to get
the level of code we need to truly do this hand-off the way we want
(& now) need to.

The tools themselves REALLY aren't good enough. Better visual or
human language programming tools are really needed here.

I should be able to create a state transition on click on a specific
hot spot as easily in Flash or Blend as I could in powerpoint.
Anything short of that and IMHO the tools fail.

-- dave

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=20000

1 Oct 2007 - 8:22am
Todd Warfel
2003

Have you spent any time trying to figure out why? I'm curious what
causes this type of reaction from the engineers you're dealing with.

On Oct 1, 2007, at 3:43 AM, James Leftwich, IDSA wrote:

> Nowadays, I and my partners will often have portions mocked up and
> made interactive, mostly for show to our clients or execs while
> implementation is underway. No engineers I work with would prefer to
> have interactive models _in lieu of_ the kinds of implementational
> documentation I've traditionally provided.

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.

1 Oct 2007 - 9:46pm
David Walker
2007

I haven't had time to respond properly with everything I've learned about doing a XAML project with Blend and a little C#. But I echo Dave Malouf's comments here; Blend 1.0 does not have the maturity to deliver what I want to deliver as a designer. I find myself explaining to the dev lead: "Okay, I had to do a lateral transform on this object in order to get it to look the way I wanted, but Blend isn't smart enough to also transform the height and width properties, so we can't use auto-sizing: we'll have to write a little sizing code."
The dev lead doesn't want to write this kind of code, but he likes how I've made it look, so he caves a little. But I do find that I end up losing a lot of control with Blend 1.0. I am playing with tools that were designed to create software within certain constraints, which is just not ever going to work for our trade.
I am looking forward to the soon-to-be-released 2.0 version of Blend, along with the soon-to-be-released Visual Studio 2008. Because VS2005 also has trouble interpreting XAML properly - another symtom of XAML immaturity. But the idea has real promise and I don't want to give up on it quite yet. This model will advance our trade. We will truly be in charge of "how it works", not just how it looks.
Cheers all,
Dave W

>-----Original Message-----
>From: dave malouf [mailto:dave at ixda.org]
>Sent: Monday, October 1, 2007 06:17 AM
>To: discuss at lists.interactiondesigners.com
>Subject: Re: [IxDA Discuss] True or False: In a perfect world we'd all create html clickable wireframes after the static ones have been don
>
>I see in Jim's email the piece about the level of detail in his
>specifications. Detail is important indeed.
>
>But I wonder if we had tools that were good enough so that the time
>and energy it took to do that level of specification is the same
>amount of time it would take to just build it, then we wouldn't need
>to specify it?
>
>Like the other David, I'm doing a project in Blend right now and our
>goal is to really concentrate more energy on building usable code than
>for creating documentation. Now since this is a 1.0 product, we'll
>see how it all pans out, but we already know that a standard designer
>with even basic Flash level programming skills isn't enough to get
>the level of code we need to truly do this hand-off the way we want
>(& now) need to.
>
>The tools themselves REALLY aren't good enough. Better visual or
>human language programming tools are really needed here.
>
>I should be able to create a state transition on click on a specific
>hot spot as easily in Flash or Blend as I could in powerpoint.
>Anything short of that and IMHO the tools fail.
>
>-- dave
>
>
>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
>Posted from the new ixda.org
>http://beta.ixda.org/discuss?post=20000
>
>
>________________________________________________________________
>Welcome to the Interaction Design Association (IxDA)!
>To post to this list ....... discuss at ixda.org
>List Guidelines ............ http://beta.ixda.org/guidelines
>List Help .................. http://beta.ixda.org/help
>Unsubscribe ................ http://beta.ixda.org/unsubscribe
>Questions .................. list at ixda.org
>Home ....................... http://beta.ixda.org
>

2 Oct 2007 - 5:05am
Elizabeth Whitworth
2007

Perhaps the best type of specifications document depends on the industry you
work in. In my current job in the logistics industry, the only times that I
am required to make an interactive prototype is for presentation of a design
concept an end-customer. For the rest, the developers hands-down prefer
simple wireframes/screenshots + a detailed specifications document including
use cases and business rules. I think that it is because in b2b logistics,
the make or break points of any application rests in the business rules. Any
fancy visual/interaction design is just icing on the cake. The developers
know this and therefore do not focus very much on the type of interaction
design that is typically displayed in an interactive prototype (don't get me
started on the need for better interaction design in b2b applications...:P).
I imagine this is quite different in a different industry such as
e-commerce, where interaction design can greatly effect usage or customer
satisfaction and therefore becomes more important.

Any comments on the industry/ies you have been working in or the types of
applications you have been working on James?

- elizabeth

On 10/1/07, Todd Zaki Warfel <lists at toddwarfel.com> wrote:
>
> Have you spent any time trying to figure out why? I'm curious what
> causes this type of reaction from the engineers you're dealing with.
>
> On Oct 1, 2007, at 3:43 AM, James Leftwich, IDSA wrote:
>
> > Nowadays, I and my partners will often have portions mocked up and
> > made interactive, mostly for show to our clients or execs while
> > implementation is underway. No engineers I work with would prefer to
> > have interactive models _in lieu of_ the kinds of implementational
> > documentation I've traditionally provided.
>
>
> 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.
>
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org
>

2 Oct 2007 - 5:56am
Elizabeth Whitworth
2007

wow. I just found the other half of this thread. There is no way I have time
to read it all right now, so sorry if my post is out of touch...

cheers,
- elizabeth

On 10/2/07, Elizabeth Whitworth <elizabethwhitworth at gmail.com> wrote:
>
> Perhaps the best type of specifications document depends on the industry
> you work in. In my current job in the logistics industry, the only times
> that I am required to make an interactive prototype is for presentation of a
> design concept an end-customer. For the rest, the developers hands-down
> prefer simple wireframes/screenshots + a detailed specifications document
> including use cases and business rules. I think that it is because in b2b
> logistics, the make or break points of any application rests in the business
> rules. Any fancy visual/interaction design is just icing on the cake. The
> developers know this and therefore do not focus very much on the type of
> interaction design that is typically displayed in an interactive prototype
> (don't get me started on the need for better interaction design in b2b
> applications...:P). I imagine this is quite different in a different
> industry such as e-commerce, where interaction design can greatly effect
> usage or customer satisfaction and therefore becomes more important.
>
> Any comments on the industry/ies you have been working in or the types of
> applications you have been working on James?
>
> - elizabeth
>
> On 10/1/07, Todd Zaki Warfel <lists at toddwarfel.com> wrote:
> >
> > Have you spent any time trying to figure out why? I'm curious what
> > causes this type of reaction from the engineers you're dealing with.
> >
> > On Oct 1, 2007, at 3:43 AM, James Leftwich, IDSA wrote:
> >
> > > Nowadays, I and my partners will often have portions mocked up and
> > > made interactive, mostly for show to our clients or execs while
> > > implementation is underway. No engineers I work with would prefer to
> > > have interactive models _in lieu of_ the kinds of implementational
> > > documentation I've traditionally provided.
> >
> >
> > 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.
> >
> >
> >
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://beta.ixda.org/guidelines
> > List Help .................. http://beta.ixda.org/help
> > Unsubscribe ................ http://beta.ixda.org/unsubscribe
> > Questions .................. list at ixda.org
> > Home ....................... http://beta.ixda.org
> >
>
>

2 Oct 2007 - 5:57am
Elizabeth Whitworth
2007

wow. I just found the other half of this thread. There is no way I have time
to read it all right now, so sorry if my post is out of touch...

cheers,
- elizabeth

On 10/2/07, Elizabeth Whitworth <elizabethwhitworth at gmail.com> wrote:
>
> Perhaps the best type of specifications document depends on the industry
> you work in. In my current job in the logistics industry, the only times
> that I am required to make an interactive prototype is for presentation of a
> design concept an end-customer. For the rest, the developers hands-down
> prefer simple wireframes/screenshots + a detailed specifications document
> including use cases and business rules. I think that it is because in b2b
> logistics, the make or break points of any application rests in the business
> rules. Any fancy visual/interaction design is just icing on the cake. The
> developers know this and therefore do not focus very much on the type of
> interaction design that is typically displayed in an interactive prototype
> (don't get me started on the need for better interaction design in b2b
> applications...:P). I imagine this is quite different in a different
> industry such as e-commerce, where interaction design can greatly effect
> usage or customer satisfaction and therefore becomes more important.
>
> Any comments on the industry/ies you have been working in or the types of
> applications you have been working on James?
>
> - elizabeth
>
> On 10/1/07, Todd Zaki Warfel <lists at toddwarfel.com> wrote:
> >
> > Have you spent any time trying to figure out why? I'm curious what
> > causes this type of reaction from the engineers you're dealing with.
> >
> > On Oct 1, 2007, at 3:43 AM, James Leftwich, IDSA wrote:
> >
> > > Nowadays, I and my partners will often have portions mocked up and
> > > made interactive, mostly for show to our clients or execs while
> > > implementation is underway. No engineers I work with would prefer to
> > > have interactive models _in lieu of_ the kinds of implementational
> > > documentation I've traditionally provided.
> >
> >
> > 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.
> >
> >
> >
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://beta.ixda.org/guidelines
> > List Help .................. http://beta.ixda.org/help
> > Unsubscribe ................ http://beta.ixda.org/unsubscribe
> > Questions .................. list at ixda.org
> > Home ....................... http://beta.ixda.org
> >
>
>

2 Oct 2007 - 5:56am
Elizabeth Whitworth
2007

wow. I just found the other half of this thread. There is no way I have time
to read it all right now, so sorry if my post is out of touch...

cheers,
- elizabeth

On 10/2/07, Elizabeth Whitworth <elizabethwhitworth at gmail.com> wrote:
>
> Perhaps the best type of specifications document depends on the industry
> you work in. In my current job in the logistics industry, the only times
> that I am required to make an interactive prototype is for presentation of a
> design concept an end-customer. For the rest, the developers hands-down
> prefer simple wireframes/screenshots + a detailed specifications document
> including use cases and business rules. I think that it is because in b2b
> logistics, the make or break points of any application rests in the business
> rules. Any fancy visual/interaction design is just icing on the cake. The
> developers know this and therefore do not focus very much on the type of
> interaction design that is typically displayed in an interactive prototype
> (don't get me started on the need for better interaction design in b2b
> applications...:P). I imagine this is quite different in a different
> industry such as e-commerce, where interaction design can greatly effect
> usage or customer satisfaction and therefore becomes more important.
>
> Any comments on the industry/ies you have been working in or the types of
> applications you have been working on James?
>
> - elizabeth
>
> On 10/1/07, Todd Zaki Warfel <lists at toddwarfel.com> wrote:
> >
> > Have you spent any time trying to figure out why? I'm curious what
> > causes this type of reaction from the engineers you're dealing with.
> >
> > On Oct 1, 2007, at 3:43 AM, James Leftwich, IDSA wrote:
> >
> > > Nowadays, I and my partners will often have portions mocked up and
> > > made interactive, mostly for show to our clients or execs while
> > > implementation is underway. No engineers I work with would prefer to
> > > have interactive models _in lieu of_ the kinds of implementational
> > > documentation I've traditionally provided.
> >
> >
> > 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.
> >
> >
> >
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://beta.ixda.org/guidelines
> > List Help .................. http://beta.ixda.org/help
> > Unsubscribe ................ http://beta.ixda.org/unsubscribe
> > Questions .................. list at ixda.org
> > Home ....................... http://beta.ixda.org
> >
>
>

2 Oct 2007 - 12:03pm
Dave Malouf
2005

Elizabeth, prototypes are not ONLY about communicating outwardly about
your concepts. I would suggest that prototypes are a primary design
tool for you.

How can you design in an interactive medium without creating in that
medium? No other design discipline completely ignores its primary
output form and it seems wise to me that we require a basic system of
output modeling as part of our core design methods.

Even if I eventually hand off digital or printed documents to
communicate down stream, I believe that prototypes are not a
replacement for documentation or 2nd fiddle (if ya got time)
artifact, but rather THE primary formation from which documentation
should be derived.

Validation w/ users and stakeholders and communicating ideas up and
down to me are quite necessary, but not primary for prototypes.

The problem is building them (skills) and ingraining them into your
design project plans.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the improved ixda.org
http://beta.ixda.org/discuss?post=20109

2 Oct 2007 - 12:32pm
bminihan
2007

I'm not sure if I'm responding to this thread from 3 months back, or if your post is new, David, but I agree that prototypes first and foremost (for me) are for my own use above and beyond all others. The only way I can describe my method is that I naturally "think" in functional prototypes, and wireframes are actually kind of backward in designing the functionality of a single page. Again, this is just me, and I do use wireframes for site and process flows, but for a highly interactive single page (I build a lot of portlets), I have to build them in D/X/HTML first. I get into a rapid experimental mode, once the construct is there, and can quickly turn around a dozen variants of a working model, but if I can't prove to myself that it will work in HTML first, how can I prove it to a developer?

Another aspect we fall into a lot is that our standard stylesheet uses relatively sized fonts, and many of our employees take advantage of that and set their browser accordingly. I haven't tried Axure yet, but I haven't seen a wireframing tool that can illustrate the consequences of fluidly resizable text on a very compact interface. Similarly, many of our tools are translated into 8 languages, to the effect of German on a 2" x 3" box is quite profound - with a few Javascript variables to hold jiffy-translations, you can see all of that in a few clicks, with very little additional setup required.

I also have a network engineering background, and do a lot of performance tuning consulting for our portal, so many of my prototypes are shippable code. In that way, it does save a lot of time to start with a prototype in many situations. The majority of our developers are not savvy DHTML programmers, and project budgets tend to be much lower when we deliver the documented front-end to them with the business requirements (on the order of 1/5 the original cost, on occasion). It also lets us (my team) bake in the usability recommendations, without having to sacrifice them to project timelines...

- Bryan
http://www.bryanminihan.com

---- David Malouf <dave at ixda.org> wrote:
> Elizabeth, prototypes are not ONLY about communicating outwardly about
> your concepts. I would suggest that prototypes are a primary design
> tool for you.
>
> How can you design in an interactive medium without creating in that
> medium? No other design discipline completely ignores its primary
> output form and it seems wise to me that we require a basic system of
> output modeling as part of our core design methods.
>
> Even if I eventually hand off digital or printed documents to
> communicate down stream, I believe that prototypes are not a
> replacement for documentation or 2nd fiddle (if ya got time)
> artifact, but rather THE primary formation from which documentation
> should be derived.
>
> Validation w/ users and stakeholders and communicating ideas up and
> down to me are quite necessary, but not primary for prototypes.
>
> The problem is building them (skills) and ingraining them into your
> design project plans.
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the improved ixda.org
> http://beta.ixda.org/discuss?post=20109
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org

--

2 Oct 2007 - 12:51pm
dmitryn
2004

Elizabeth,

I completely agree that, in the enterprise space, business rules are
often what makes or breaks an application. That doesn't mean that
interaction design for these applications is "icing on the cake". On
the contrary, good interaction design will communicate business rules
clearly to the users, and bad interaction design will mangle the rules
or obscure them entirely.

In my experience, detailed specifications documents simply do not work
well as a means of communicating design, even in an environment of
complex business rules. They are usually too static to effectively
document the design, too heavyweight to be really understood by anyone
but the person who writes them, and too difficult to update to remain
relevant as requirements and scope change.

As you note, B2B/enterprise applications are often lacking in good
interaction design. If you want to change this in your particular
project, you will need a way to communicate your design ideas and
decisions to your development team. Personally, I have found that
interactive prototypes, combined with lightweight documentation of
business rules and usage scenarios, are an effective way of doing
this. Try it, and you just might find that your developers' resistance
is mostly due to failing to realize that there are alternatives to the
status quo.

Dmitry

On 10/2/07, Elizabeth Whitworth <elizabethwhitworth at gmail.com> wrote:
> Perhaps the best type of specifications document depends on the industry you
> work in. In my current job in the logistics industry, the only times that I
> am required to make an interactive prototype is for presentation of a design
> concept an end-customer. For the rest, the developers hands-down prefer
> simple wireframes/screenshots + a detailed specifications document including
> use cases and business rules. I think that it is because in b2b logistics,
> the make or break points of any application rests in the business rules. Any
> fancy visual/interaction design is just icing on the cake. The developers
> know this and therefore do not focus very much on the type of interaction
> design that is typically displayed in an interactive prototype (don't get me
> started on the need for better interaction design in b2b applications...:P).
> I imagine this is quite different in a different industry such as
> e-commerce, where interaction design can greatly effect usage or customer
> satisfaction and therefore becomes more important.
>
> Any comments on the industry/ies you have been working in or the types of
> applications you have been working on James?
>
> - elizabeth
>
> On 10/1/07, Todd Zaki Warfel <lists at toddwarfel.com> wrote:
> >
> > Have you spent any time trying to figure out why? I'm curious what
> > causes this type of reaction from the engineers you're dealing with.
> >
> > On Oct 1, 2007, at 3:43 AM, James Leftwich, IDSA wrote:
> >
> > > Nowadays, I and my partners will often have portions mocked up and
> > > made interactive, mostly for show to our clients or execs while
> > > implementation is underway. No engineers I work with would prefer to
> > > have interactive models _in lieu of_ the kinds of implementational
> > > documentation I've traditionally provided.
> >
> >
> > 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.
> >
> >
> >
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://beta.ixda.org/guidelines
> > List Help .................. http://beta.ixda.org/help
> > Unsubscribe ................ http://beta.ixda.org/unsubscribe
> > Questions .................. list at ixda.org
> > Home ....................... http://beta.ixda.org
> >
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org
>

12 Oct 2007 - 12:59pm
Elizabeth Whitworth
2007

Hello David,

I wholeheartedly agree that prototypes are an essential design tool. We
often do paper prototypes of our designs, or "spike" prototypes to test out
a particular user interaction within a design. However, I still have trouble
fitting my head around how I could make a prototype for the kind of
application we are making at my company.

For example, we have two major software clients that are used together on
our platform. One is for the shippers (who have goods that need to be
shipped), and the other is for the carriers (who have the trucks to ship the
goods). One shipper can have anywhere from 30 - 200 carriers connected to
their client, and a carrier can have anywhere from 1-20 shippers connected
to theirs. The basic way the platform works is that a shipper places items
(5 - 100 per day) on the platform using their client. Their carriers can
then view these items and make bids on them. After receiving a number of
bids (e.g. 10), our customers will accept one of them. The platform then
sends out acceptance and rejection messages.

The interaction design for such software is incredibly interesting. There
are 3 different panes in the screen display for each each client (1 for
notifications and contact data, 1 for the different categories of item
listings, and 1 to display the details of the currently selected item), with
2-6 tabs associated with each of the panes. There are also a large number of
business rules surrounding who can view a given item, which information is
available to different classes of users, and processes for notification and
cancellation, etc.

But I really have no idea how to prototype it (in a reasonable amount of
time :-), let alone in a way that can be used as specifications for
developers. Any suggestions? I have to admit that I am really not all that
skilled in prototyping at the moment. I have very limited programming skills
and generally stick to click through HTML pages, but I don't think that is
the problem in this case.

Currently we simply show series of screenshots + descriptions to describe
user interactions to developers. We also use paper prototypes to work
through very basic interactions, but have found that paper prototypes are
pretty useless in testing large scale (10+ users) user interaction with the
system which should support an average of 50, and up to 200 users.

- Liz

> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the improved ixda.org
> http://beta.ixda.org/discuss?post=20109
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org
>

12 Oct 2007 - 3:33pm
Elizabeth Whitworth
2007

Dmitry,

I agree with everything you said :-).

I think that I have also not really communicated my point (problem?) very
well. There have only been a couple of times that I have used interactive
prototypes (+ minimal documentation) to communicate designs to the
developers here. Both times they were relatively simple web application
interfaces but with complex back-ends, and both times the developers
completed the projects to the t regarding the back end business rules, but
only implemented certain aspects of the interaction design. Instead of the
specifications tool being the problem, I think perhaps the real problem lies
in the context I am working in. There is no resistance from developers to
the specifications - they simply run out of time to follow through on a
design. Anything UX related that we don't specify very clearly as part of
the core of the application tends to fall through the cracks, and another
third of the time it's cut out of the project purposefully because the
customer does not want to pay for it (and neither do we). Since my company
makes money based on customer transactions, even 2 weeks spent on something
other than implementing customization requests and getting a customer on our
productive system is costing the company revenue, therefore they go to a lot
of effort to shave time off every single project.

In a way I feel like I have had to change my way of thinking to from
'holistic, clean, and helpful user experience' to 'super-practical
minimalist functional design. cheap.' in order to fit into the context of
my current job. This is not necessarily a bad thing, but it means that I
really had to change the way I work and think. I think I was also a little
overenthusiastic in my first few projects e.g. expecting to be able to
create some beautiful 37signals-like interface, when what we really need for
this customer is an excel-like interface. Nowadays I find myself working
much harder to prioritize and distinguish the improvements in interaction
design that are _absolutely_ necessary from the ones that are just good
ideas, and really think about how I can present them to others so that they
seem worthwhile investments in the software from a business perspective.
It's still tough because often the most worthwhile improvements in
interaction design (e.g. changing the interaction style of one of our base
modules to be more intuitive), would take a lot of development effort.

Anyway, I'm sure I'm of-topic by now.
Thanks for your feedback,
- Liz

On 10/2/07, Dmitry Nekrasovski < mail.dmitry at gmail.com> wrote:
>
> Elizabeth,
>
> I completely agree that, in the enterprise space, business rules are
> often what makes or breaks an application. That doesn't mean that
> interaction design for these applications is "icing on the cake". On
> the contrary, good interaction design will communicate business rules
> clearly to the users, and bad interaction design will mangle the rules
> or obscure them entirely.
>
> In my experience, detailed specifications documents simply do not work
> well as a means of communicating design, even in an environment of
> complex business rules. They are usually too static to effectively
> document the design, too heavyweight to be really understood by anyone
> but the person who writes them, and too difficult to update to remain
> relevant as requirements and scope change.
>
> As you note, B2B/enterprise applications are often lacking in good
> interaction design. If you want to change this in your particular
> project, you will need a way to communicate your design ideas and
> decisions to your development team. Personally, I have found that
> interactive prototypes, combined with lightweight documentation of
> business rules and usage scenarios, are an effective way of doing
> this. Try it, and you just might find that your developers' resistance
> is mostly due to failing to realize that there are alternatives to the
> status quo.
>
> Dmitry
>
> On 10/2/07, Elizabeth Whitworth < elizabethwhitworth at gmail.com > wrote:
> > Perhaps the best type of specifications document depends on the industry
> you
> > work in. In my current job in the logistics industry, the only times
> that I
> > am required to make an interactive prototype is for presentation of a
> design
> > concept an end-customer. For the rest, the developers hands-down prefer
> > simple wireframes/screenshots + a detailed specifications document
> including
> > use cases and business rules. I think that it is because in b2b
> logistics,
> > the make or break points of any application rests in the business rules.
> Any
> > fancy visual/interaction design is just icing on the cake. The
> developers
> > know this and therefore do not focus very much on the type of
> interaction
> > design that is typically displayed in an interactive prototype (don't
> get me
> > started on the need for better interaction design in b2b
> applications...:P).
> > I imagine this is quite different in a different industry such as
> > e-commerce, where interaction design can greatly effect usage or
> customer
> > satisfaction and therefore becomes more important.
> >
> > Any comments on the industry/ies you have been working in or the types
> of
> > applications you have been working on James?
> >
> > - elizabeth
> >
> > On 10/1/07, Todd Zaki Warfel < lists at toddwarfel.com> wrote:
> > >
> > > Have you spent any time trying to figure out why? I'm curious what
> > > causes this type of reaction from the engineers you're dealing with.
> > >
> > > On Oct 1, 2007, at 3:43 AM, James Leftwich, IDSA wrote:
> > >
> > > > Nowadays, I and my partners will often have portions mocked up and
> > > > made interactive, mostly for show to our clients or execs while
> > > > implementation is underway. No engineers I work with would prefer
> to
> > > > have interactive models _in lieu of_ the kinds of implementational
> > > > documentation I've traditionally provided.
> > >
> > >
> > > 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.
> > >
> > >
> > >
> > > ________________________________________________________________
> > > Welcome to the Interaction Design Association (IxDA)!
> > > To post to this list ....... discuss at ixda.org
> > > List Guidelines ............ http://beta.ixda.org/guidelines
> > > List Help .................. http://beta.ixda.org/help
> > > Unsubscribe ................ http://beta.ixda.org/unsubscribe
> > > Questions .................. list at ixda.org
> > > Home ....................... http://beta.ixda.org
> > >
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://beta.ixda.org/guidelines
> > List Help .................. http://beta.ixda.org/help
> > Unsubscribe ................ http://beta.ixda.org/unsubscribe
> > Questions .................. list at ixda.org
> > Home ....................... http://beta.ixda.org
> >
>

Syndicate content Get the feed