Re: How to price? [problems of dealing with novice clients] Re: How to price? [problems of dealing with novice clients]But the publisher is incompetent to measure the quality. An interactive
interface, even just plain hypertext with links, is not evaluated the same
way as a flat printed page would be... if it is judged solely on the basis
of how nice each page looks, it will probably be a failure from the point
of view of stimulating interaction, getting it on hotlists, getting its URL
passed around... we found that when working on standalone products,
we had to train the publishers in user-centered design first, then in
paper prototyping, then in usability engineering, at least to the degree
necessary to get them to understand how you measure a good interface.
In general this turned out not to be worth it... it turns into a choice
between doing low-quality work that makes the clients happy until it hits the
market, (i.e. it satisfies their wrongheaded notions of how best to present
themselves) at which point they admit they were wrong and beg for changes
far too late, or doing high-quality work that makes the clients disgruntled
that they did not get 'what they want'... until they see how wildly
successful is at
making users interact and come back. Thankfully on the Web that turnover
time is short. But you have to face the basic question: "are you prepared
to
educate the client, facing their wrath if they don't get it, or should you
stick to markets where they already understand interactive design (few)".
We found that we *could* educate the clients, i.e. we could quickly train
them in interactive design as we had a considerable curriculum on it, but
it just wasn't worth it for small clients just getting into the industry.
Thus we leave these
alone now.
>probably involve arbitration, but we are considering using language of
>this sort (after consulting with our copyright and contract lawyer, of
>course!) in our agreement. So that a client can expect from us Internet
One of these situations hit arbitration when the client decided to apply a
totally different standard of evaluation than the contract specified for an
intermediate deliverable (i.e. they wanted it to look pretty although it
was a functional spec version intended to get feedback on functionality
*before* we made it prettier, at great cost to ourselves had they found the
pretty version not to their liking - we suspect that they actually planned
to use this to *raise* the final financing).
They had subjected us to similar "process innovations", most notably
through delivering the final database 3 months late (after delivering us 5
half-baked versions each with their own schema) when we needed it in order
to finish the product for a hard deadline. This forced us to build some
parts 5
times over, at our own expense as it was a fixed bid. I'd advise against fixed
bids when working for novice entrepreneurs, novice information system managers,
and novices of other kinds. You will be investing major time in their
education.
The parameters applicable to deals between professionals simply don't apply.
Similarly, the terms of a contract are not necessarily enough to protect you.
We should have drawn the line on this mob much earlier, in fact we were
bending over backwards for them as it was, and we tried to resolve what
their *real* criteria and constraints were several times. To no avail. It
ended up as our first dispute with a client in SEVEN years. I guess this
is a sign that we bend over *too* far backwards to keep our clients happy. ;-)
>information services developed to a level exceeding the minimum
>professional standards in the industry as defined by the current state of
>Web development.
Ye gods, this changes by the week! Who are the experts? Do you really
want to be paying an arbitrator to listen to Tweedledum and Tweedledee
argue over the design issues that we are putting together on this list ?
Hey, I'm up for it. Have your arbitrator give me a call, and I'm on your
side.
>Otherwise, the client may have extreme expectations that can't be met. But
A common problem everywhere in the IT industry.
>if the site is crummy, we've failed to fulfill the contract. Of course,
>we'd never do a crummy site, but you need a starting point for this kind
>of language.
If you'd never do a crummy site, then don't deal with clients who would
ever accuse you of doing one deliberately... who would, worst case, shrug
shoulders and say "hey, this is a new thing, you tried your best, we knew
what you were doing at every step, we authorized it, so a few bucks got
wasted, that's business... if you were the wrong guys, well I said you were
the right guys, so I am as much at fault as you.". I am starting to think
that, despite its obvious economic inefficiency, this is how big business gets
big. By making it less risky to deal with them than with others.
>There are now several lawyers involved with these issues on the list, and
>I'd appreciate any off-the-cuff, nonbinding, semi-unofficial ideas about
>this from them, as well as the same kind of ideas from the non-legaltypes.
Hope the above helps.
-- Craig Hubley Business that relies on knowledge Craig Hubley & Associates needs systems that exploit the Web craig@passport.ca 416-778-6136 416-778-1965 FAX