>> Scenario 1: You get the basic flow of the site and then you tell the graphic artist to create a look and feel, you start building HTML prototype and your HTML programmer turns around and says "I know they want a contact us form here but what fields do they want?" Arghhhh. What a horrible scenario.
------ This is a given as to what will happen no matter what. I have never started a project in which I had all of the details at first, there were always questions later on. I don't really see any way around this, no matter how much pre-planning you do, there will always be questions. ------ >> Scenario 2: You can prevent scenario 1 from occuring by creating a requirements document between wireframe and prototype. Client looks at requirements doc, does not really understand it so he/she signs off on it. HTML programmer codes what he thing the client asked for and then client comes back and says, sorry that is not what I want, can you change x,y,z and the kitchen sink. Arghhhhh. You get a disgruntled employee. Not very good. ------ I don't believe a requirements document will work for the exact reasons you mentioned. The client has no idea what you are talking about and if they sign-off on it, you can guarantee changes will be made once they actually start to see something. ------ >> Scenario 3: Wireframe has two modes. First mode just gets general feel and second mode allows architect to go back and get more complete data. Client gets to see what is proposed and can correct some of the errors before you get disgruntled employees and before you get to the point where you have spaghetti code because every time the client comes back you create fixed instead of doing it right from the start. ------ I don't like doing HTML that much either, although Dreamweaver can make it a lot easier. Either way, the client will never be able to tell you what they want until they can see it. Whether you make a second wireframe or wireframe mode, there will still be changes made to the prototype later down the road. I don't see that you are making life any simpler by adding in another step. Maybe you get a few more requirements nailed down up front, but there will still be more hidden that won't come up until down the road in the prototype. There is no right or wrong, if you have a way that works, go with it. I just don't see how adding another requirements gathering phase will change that much. Either way, there will still be some surprises during the prototype - but it is still much easier to change the prototype as HTML rather than trying to change the HTML, CF, and Database just because of a new form field. -- Jeff ==^================================================================ 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 ==^================================================================
