In my experience (about 12 years of practical web development, so certainly not as much as some here), wireframing is most useful when applied to projects that have a "what" but not a "how."<p>Whether it's an internal/personal project or something for a client, it seems to me that most ideas usually fall under "conceived by interface" or "other." If someone wants you to build a web forum, chances are that idea is based on how they want the forum to work and what the user interface should involve; if they want you to build a penny auction website, chances are good (based on several actual requests and one actual paying client) that the business model and not the UX are the driving force behind the project.<p>For projects that do lend themselves to wireframing, I've heard of several great tools -- Mockingbird is the only one I can recall -- but I am a pen and paper guy. As a developer, I think it removes me from the "I'm programming now" mindset that immediately jumps to data models and dependencies.<p>I do think this is more useful for general site layouts, though, than for completely building a site on paper (or in whatever medium). As a designer, this may not be your first concern, but the practical reality of user experience is that requirements are never the same at the end as they were during the beginning, so high-level concepts and ubiquitous elements like navigation are (hopefully) more likely to stick to The Plan than the details of each page.<p>Basically, separating user workflows and specific site functionality from wireframes helps to make sure your wireframes are both useful and more likely to stay flexible and relevant throughout development.