The amount of time it takes for you to get to this point is totally dependent on the scope of your project and your team. So far, you've had to spend a lot of time talking to a lot of different people to get input on the various requirements for the application. Don't get frustrated if it seems like it's taking a long time or if it becomes tedious (which it will!). Writing the functional spec imposes a lot of discipline on the whole web development cycle and, in turn, can require a good deal of patience and diligence upfront to make it through. The time spent now, though, will reap multiple dividends later. In terms of development time, frustration, and money saved by having a document that spells out exactly what the application is and how it should work, it's a small price to pay at the beginning to avoid a death march.

Now that we have defined our application and mapped out the functionality and information, we're ready to create some mockups. At this point, it is recommended you bring in a graphic designer to develop these for you. Even if you're capable of putting them together, it can be beneficial to have someone else looking through your document and creating these. They'll spot holes in your logic and raise good questions; plus, it will free you up to continue focus on the writing and any final requirements gathering you need to do. A basic process you may want to follow:

• Create wireframes for your key pages*
  A wireframe is a mockup of the page that only addresses the layout, not aesthetics. Think of it as the skeleton of your page, and the mockup will add the skin. A wireframe is useful because, at this point, you're still dealing with pure information and flow but you're also starting to understand the relationship of that information as it applies to your application. The spec writer should be creating these.

View an example wireframe.
• Design for the functional requirements, business requirements, and user requirements
  Lay your user's needs over the functional and business requirements. If it's not usable, then it's completely worthless to everyone involved. Address the user first and then work in the other requirements. Perhaps the hardest part is finding this common ground between the business needs and user accessibility, so do not be deterred.

Now, you may be asking "Why are we creating wireframes and mockups if we have already created a prototype?" That is a great question! Actually, what we want to accomplish at this stage (as opposed to the previous one) is a major commitment to the look and feel. The prototype should be created with the thought of being able to throw it away at a moment's notice. It is just there for you to have something to put in your hands, so to speak. This is the stage where we want to define the look and feel, make critical design decisions (like color scheme, layout, branding, etc.), and get ready to create the design document. Also, as a designer it can be useful to see your prototype in order to generate ideas faster (i.e., some of the thinking about how everything works together has been done) and it can provide a nice starting point from which to work from. Just don't allow yourself to become married to your own work at this point: be open to change and different ideas.

Now, that's why we create the mockups. The wireframes should simply follow the mockups, and here's why we create them. We are going to be drafting a design document in the next section. As you will see, one of the aims of this document is to allow all stakeholders in the project to see a kind of "Sneak Preview" of the upcoming functional spec. The best way to elicit useful and impartial feedback is to leave as much detail out as possible. Ideally, what you want to do is convey the application and the functionality without bogging the conversations down in discussions of color or branding. This is best done with wireframes. Wireframes are all about getting the right kind of feedback at the right time. So in order to gain useful comments about the layout, navigation, and functionality of the application, we want to strip out as much of the design and visual design as possible.

If it seems confusing to you to have a designer working on the look and feel while you are putting together a design document with only the wireframes, it may be useful to view this process as a spiral, or iterative, development cycle and not a linear, or waterfall, methodology. It has been my experience that I work faster and end up with a better product when I follow this sort of organic approach: letting several facets of the application design process run in parallel and gradually allow the application to sort of rise up on its own through the requirements gathering process. The key for all of this working is having a good team and keeping the communication open.