The problem I see with the traditional method (derive functionality first) is that it asks the client to speak in terms and concepts they simply aren't familiar with. We have analogies of this type of behavior all around us. We go to the doctor and they tell us that we appear to have a mildly intubigated cytoplasty. We go to our accountant and they tell us that we need to roll over our ESOP plan into a graduated SEP or face the consequences of IRS Ruling 2774.
What about us? When we tell our clients that they need to determine the functional specifications or requirements of an application before we begin doing any work on the front end, we see this in a very different light from the examples above. We're just trying to make sure we don't put the cart before the horse. After all, why do a front end when you don't know yet what the front end needs to do? Silly, no? My answer to this is "no". Not silly at all. Front ends are an efficient and cheap way of helping clients determine what they want. They are concrete; "functionality" is quite abstract. I recently spent a half a day with a client who wanted to know my "secrets" for successful web applications. "It's really very simple. Use prototypes to determine client requirements. Mark up the prototypes as a first cut of XFAs, fuseactions, dynamic data, and circuits. If you get that done, you've eliminated the greatest sources of project failures." But they had a prototype, you see? They had already done that part. Now, they wanted to know my secrets. "Why don't you bring up the prototype and I'll help you through the initial architecture?" I suggested. It turned out that they had a single prototype page. After that, they covered two white boards with cryptic diagrams, some of which showed menus; some of which purported to be functional areas; and others I suspect were simple grafitti. This was the "real" work and they very carefully printed "DO NOT ERASE!!!" to make sure their "architecture" wouldn't be lost. As they talked about things, it became absolutely clear that they had only the vaguest notion of functionality and structures, though I gave them full marks for buzzword compliancy. What they wanted was Magic Fixit Architectural Powder and they were pretty sure I had it. In fact, they got a little annoyed by my suggestion that we were not ready to architect anything yet. "We're already writing code," I was told. So the entire conversation necessarily was highly abstract and theoretical, since there was no "there" there. If the project succeeds, I would submit this as proof positive in a divine being who directly interposes in human affairs to turn sure loss into gain. -----Original Message----- From: Steve Nelson [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 09, 2002 2:35 PM To: [EMAIL PROTECTED] Subject: Re: FLiP and Prototyping > As soon as the client sees HTML they get excited. How true! Then they > think they have a real application. Clients differ however and I think > the success of a project hinges on managing the client, their > expectations and their capability to visualise it in terms other than > just a webpage. This is where you come in, and how you manage the > client matters. They are all mostly different, although most want to > see the vissuals at some point early in the process. This is why I > "mock up" the visuals, and educate them on what the functioning > prototype actaully represents You have to provide a minimal amount of training to your client regardless of what method you use. They won't understand your software development process until you tell them. So whether you build the HTML first or last, you'll have to explain to them what they're getting. I've tried both ways. Building an HTML only front end first has dramatically improved my projects. I find it is much easier to explain to them that a prototype is just a clickable non-working application than it is to explain to them to not worry about the way something looks. If you try to get them to focus on functionality first, they will eventually get hung up on the way something looks or a spelling error or a layout issue. Once they get hung on a design issue, they will not move on until that issue is fixed. So instead of a functional version you get a functional version that has a tiny amount of design in it. The problem with this is that often developers get pushed up to the day of the deadline and decide the look and feel isn't that important, making the features work are more important. So the end user gets screwed out of a good interface, and they ultimately decide to not use the software. How many people use EVERY feature on their VCR? Very few. How many VCRs are blinking 12:00 right now? MILLIONS! This is because the software was built around features instead of built around what the users really want and making it easy to use. Creating a good user experience is SO much more important than having another feature. At least, I think it is! :-) Steve Nelson ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
