> What I'm afraid of is I'll be presenting a wireframe to a client and
> he'll say, "Can you make that a pop-up window?" or "Can you add a
> marker that shows which pages are have access restrictions?"
> Simple little things like that could make the wireframe a much more
> effective communication tool.
but you can do that with the wireframe, already. You'd simply add a link
that says something like "after clicking here a popup window will appear and
blah-blah-blah". If you make it actually *do* the popup then you aren't
wireframing, you're developing. The whole point, I think, is to get
something in front of the client that mimics the site's work flow and
business logic. That's the purpose of the wireframe. Anything else is
development and GUI design, which are handled later.
Further there is a *real* issue with making things too easy to show the
client, and that is that to many clients what they 'see' means that
something is working, and if you did it fast then it must've been "easy". If
you show them everything easily, then they are going to wonder (a) "why
can't I have this done at the end of the week" and (b) "since I can have it
at the end of the week", he thinks, "why are they charging me $75000 for it?
I got a cousin who makes 'web pages' and I bet if I give him $500 he'll do
it for me"
Seriously, this *is* an issue, and the smarter the client is, usually the
more they *think* they know about how to do it better/cheaper/faster. (As an
aside, this is also why doctors and lawyers get burnt so easy in the stock
market)
The wireframe exists to divorce the concept of the GUI from the work flow,
so that when you present them with a GUI mockup and they sign off on that,
that they don't then assume that all the work is done. And by breaking the
entire project in more "show-able" stages the client gets a real sense that
progress is being made in an orderly fashion so he will be much more likely
to not (a) break that progress path and (b) not object when you ask for
regular payments of real $$$ at various stages of that path. He's got
something concrete at each stage to put his hands on (and to justify up his
organizational ladder if need be). Also you're showing him 3 things, rather
than just one big thing, and again, he perceives having gotten more "value"
thereby.
We have a client currently who has been really easy to work with, using this
technique. They especially like being able to compare the wireframe and the
static GUI mocks and the prototype all at the same time. However, their
"money people" in accounting just changed and wanted to review everything
and commented , "well once it's done we'll pay the remainder of the
invoices, even though they're now 30 days past due." One call to the actual
client (not the new accountants), about how they'd agreed there'd be regular
payments at the various stages of development and this was why they got to
see the various stages in progress was all it took--they took on the payment
issue as *their* issue, and had their own internal fight about paying
invoices, and we got a check 4 days later. Guaranteed without having built
this relationship with the client that he'd have had no "visual" basis for
going in and telling the accountants to just do what they're told. It
emboldens the client, to the developer's advantage.
>
> The danger of course is that there would be tremendous opportunity to get
> carried away with all of the added features.
yeah I totally agree. In a larger organization, it's the project manager and
architect who need be at the wireframing meetings (after all all the
wireframing should be occuring in the context of collecting specifications
and understanding the client). usually PM don't have the skill set to do all
this little development extras and architects think it's way to easy to
bother with their time. That's great since again this is spec phase not
development phase. There will be plenty of time during the prototype phase
to throw in that Pop-up window and have the client comment on if that works
for the effectively.
> I think we *can* have power and extensibility (and diuturnity!) without
> sacrificing simplicity and speed.
I totally agree that you can. Let me present a rational argument against it
(see below)
Keep in mind that Wireframing is for the proto-CLIENT not for the
DEVELOPER-- you haven't converted him to a client yet because he hasn't
signed a check. A signed check in my hand defines a client, everything else
is a bunch of noise, a dot-com wanna be who needs everything done
tomorrow...on credit.
> And if I can get you to bite on that idea, I'll let you in on how I
> think wireframes could be used as a tool during development -- not as
> some complex Rational-esque code generator but as a simple
> communication tool.
here is the reason why I'm unlikely to "bite". :)
First off, I think the difference in opinion relates directly to your
comment above that "wireframes could be used as a tool during development".
I believe that is in error since no development should be done until
wireframing is complete. They are two temporally distinct processes and
development cannot and should not be attempted during specification phase.
I'll go out on a minor limb and suggest, without proof herein, that anytime
any of us have ever gotten screwed on a project was a project in which the
distinction between specification phase and development phase was not
observed.
Second, if you make a substantial improvement to wireframing I'd certainly
use it...so don't let my own opinion in the matter stop you :)
however, to me, the wireframing occurs as part of the first serious contact
with the client. At this point if the client is a putz I want to get out of
there as fast as possible. But if he is serious, then I want to make the
path between "ok let's go ahead" and "here is the first payment" be as fast
as possible, because I need a cushion for time spent on this project by my
various team members. I want to have the minimal work early on but as much
visual bang-for-the-buck as possible because in the end I need both the
client to be happy *AND* the bill to get paid promptly. You cannot
consistently make money by allowing the client to pay only at the "end" of
the project since then they control what 'end' means. Once I have some
money in the account, *then* is the time to spend on development with the
goal being that you are always monetarily ahead of the game--you always
"owe" them some more work based on monies you've collected, rather than
their owning you for work already done. The time between wireframing and
first payment (hey if you're really smart you got a retainer fee in advance
just to sit down and wireframe!) this time should be the only period where
you're running "in the red". That's why it's got to be short. And the way to
keep it short is to make the wireframe as minimal as possible--the more
bells and whistles you add the more liekly you are to extend the wireframe
period and the more likely that extension will be because you're showing the
client "development" and "prototype" stuff, rather than wireframe stuff.
my goal during wireframing is to get as quickly as possible to the
prototyping stage where the client makes a second or third payment. I got
plenty of development and auto-code generator tools in hand already that
can take care of that, bundling them all together is nice and might even be
used internally but it's got nothing to do with the *client*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
