From my own, personal experience, I reckon that you may categorise the site design process into two sections: the look process that doesn't work with a mockup tools, and the the one which does. Previously being on both sides with this fence, I have a comprehension of the way both of these processes work even though designing without a wireframe works, I'd have to vote in preference of them.
Wireframing, the creation of a "visual blueprint", doesn't need to be overly complicated. At the most basic, I've seen wireframes which can be simply are group of post-it notes with the graphical user interface (UI) elements drawn on them. They're then placed onto a piece of paper to indicate the structural layout. Match it up to wireframes produced through design software and you will see a more refined wireframe through the latter, but regardless how you would like to you could make your structural model, it feels right always the same. Simply put, it shows yourself, the consumer or any other party where things will probably be found on the page.
This is often a real-time saver in case you are to become a website for the client. Going back to my times of located on "side A" in the fence, when producing a website for any client I never accustomed to execute any wireframing process in those days. The entire process contained: gathering requirements, spec'ing the website, creating the graphical UI after which building the web site once the design have been agreed. The main flaw I discovered within this process is the possibility of the customer attempting to change the main layout quite considerably. I'd have no problem whenever they simply want to tweak things occasionally e.g. colours, make text larger, start being active . more images occasionally, make video a lttle bit bigger (the most common stuff); nonetheless it would have been a whole lot more painful if they then need to move to produce about about the page that directly affected the "page template". Jumping up to "side B" from the fence and producing the wired layout for that site implies that layout could be agreed beforehand in the knowledge that when the UI design is presented, you could possibly then just need to update the standard stuff.
Being forced to Spell it for Clients
Even if presenting a wireframe to a client though, I have had occasions where they will be unwilling to sign this part off on the grounds which it looks very "blocky" and "plain". "Yes it does" will be my immediate response to this because these blocks will determine where we're going to put things on the lovely page to ensure once you get back to me down the road when you have reviewed the graphical design, you can not then tell me why is the navigation up here and not there? Remember that, I've had clients similar to this previously so even if creating a wireframe, there may be times when you still need to spell it out that this is purely to have the layout correct for starters, then we'll make use of the pretty little with it afterwards.
An Arsenal of Design Software
You don't need to necessarily know your way around Adobe software as a way to produce some decent wireframes. I take advantage of a web-based tool, Cacoo, to create mine. This online software allows you to drag and drop pre-created elements on to your page. This could save a lot of time along the route.?
Much like everything web related, everyone may have their own opinion for this topic, but my own, personal preference is by using a wireframe whenever I'm designing a web site. Be it for a client and for my very own site, it doesn't matter mainly because it implies that the UI design is sped up because you're effectively working coming from a template.
When you're taking care of a project to get a client, then aiming to have Joe Bloggs sign over wires before starting around the UI is part of this design procedure that I would call important making certain you maintain good budget and time management over a project.