Each project presents unique design challenges, and we work hard to avoid a one-size-fits-all design mentality. Having said that, for new small-to-medium sized projects we start with a standard approach that has proven successful for us in the past.

Start at the top: For web applications, workflow is the hardest thing to get right, and it'll have the largest impact on the quality of the application. Depending on where you are in the business cycle, the ability to quickly prototype and demonstrate your workflow might also be important.

Focus on it. Get out a pen and start sketching the site, on paper or on a whiteboard. No details, yet, just boxes connected by arrows. Once your first cut is done, start editing:

• Eliminate "dead" pages, ones that just display a short message and invite you to continue.
• Combine pages where it will improve efficiency, and split pages when it makes the process less confusing.
• Think about destinations - when you're done with a process, where do you end up? Hint: content-free "home" pages are a crutch.
• Think about which actions are important to the system, as opposed to the user - things like logging in. Try to focus the workflow on the what the user wants to get done, and integrate the system-required actions into those processes naturally.
• At each stage in the process, try to provide the user one obvious next step.

Before you started sketching the site, you probably had a general idea of the data you'll need to collect and retain. Use the workflow sketch to refine that understanding - get a feel for the dynamics of the site, when information becomes available, when it needs to be stored, and what the transactional boundaries look like from the user's point of view.

Transactional boundaries are critical in any non-trivial application. Users need to know when their work has been saved, and if it's not yet complete, how to get back to it. Ideally, an action should be an all-or-nothing proposition - either it is complete and saved, or nothing has been changed. Complex tasks might not have such obvious behavior - they may require a series of steps, some of them optional. In such cases, it must be clear when changes are preserved, and how to return to previous steps.

Armed with a deeper understanding of your information needs, dive to the bottom: design your database. Go directly to the database, do not pass go, do not design a code-based object model. You can create much richer relationships in code than you can on the database, so if you start with code you'll waste all your effort trying to shoehorn objects into the database, or fighting an uphill battle to get decent performance (have you ever looked at the abominations generated by one of those automated model-to-schema tools? Yeesh).

So now, with a workflow and a schema, you're in a great position to design an object model that not only supports your site, but can also actually be stored efficiently. In fact, you could even use something like DbForms to create and use your new data model without any intermediate code.