What a great piece!
This kind of thinking is what is required to be a project manager, not just
a programer. Programming skills are necessary, but without management
skills (including managing the client's expectations), a project is doomed
to failure from the start (missed deadlines, missed budgets or missed
expectations).
At 11:40 AM 2/22/01, John Quarto-vonTivadar wrote:
> > 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
