Before writing any code, a little planning to map your business process to SharePoint workflow can go a long way. The two most important things to keep in mind are that
a) SharePoint workflows are document-centric, meaning they run process around a document or list item, and
b) They are human-based, meaning that they can drive people process by assigning tasks, in addition to automated computational process.
How do these things help? Well, knowing the capabilities and strengths of SharePoint workflow can help you plan the structure of the workflow’s surrounding SharePoint objects, what the workflow should do, and how it can get the information that it needs. For example, since a workflow instance runs on an item, you have access to the content and fields on that item; do you want the workflow to manipulate metadata, and if so, what columns do you need?
If you’re designing a workflow that doesn’t really “process” or route a single document, e.g. a workflow that involves reviewing a set of documents instead of just one, would it work to use items that link to those documents in a regular list instead of a document library as starting points for the workflow?
If you need to drive people to do different tasks, where and when should tasks be assigned, and what data do you need to collect from those people when they complete their tasks?
Also, workflows run as System Account (Administrator privileges) so that it can do things that ordinary people cannot, like creating audit entries. Can you take advantage of this for any part of the process?
Once you have a sense of what your workflow needs to do, you can start the authoring process.
In the next entry, I'll be starting the Five Steps in Developing Workflows.:) Next: Step 1: Model Your Workflow in VS