When you get to show the results to others - just use whatever you are presenting the rest of the message with - almost all "office" type products have sufficient capacity to manage that part. The clever bit is the bit you do by yourself.
Nothing beats pencil and paper. We used to just scan hand-drawn diagrams and insert them into PowerPoint or wherever. Over the time this got accepted as the culture within the group.
I started using Dia (http://projects.gnome.org/dia/) when my employer wouldn't spring for Visio. A bit quirky at times, but overall not too bad for simple stuff.
I first use paper and pencil, but then I transcribe and keep it up to date electronically.
http://lucidchart.com has been my favorite service as it is free for simpler projects and can be upgraded if you need more complexity. I've watched the project grow from an idea, to recruiting developers in my CS classes, to a full blown project which has exceeded my expectations. It's exciting to watch!
My process is a bit rudimentary. I just have a folder with notebook paper in it. When I need to create a new system or subsytem I will draw it on paper just as it would look in any of these diagraming tools. Once ready I'll use lucidchart to replicate the drawing (schema or flowchart). Once it's implemented in code and committed in Git I will go back to the electronic copy, mark in red or other colors anything that will change in the next refactor or implementation. As I refactor I change the red makrings to black indicating it is now part of the system. The paper becomes an artifact of the first revision.
Sometimes I'll break out a new paper and do the initial drawings to test my knowledge of the system and see if I have complicated the design. This system works well for me.
Then zap it with my DSLR. Or if it needs to be published, use Dia and export SVG/png into target document.
I occasionally write out graphviz stuff from my code using a very light weight library I wrote (C struct to stdout) if I'm trying to visualise what is in memory at a point in time. This has been invaluable whilst knocking up a simple mark-sweep GC for a project I was working on.
Also for the corporate world where only Microsoft tools are an option, I tend to just use MS Word, you can make diagrams that are good enough to get the message across, yet everybody has access to it without requiring a special license.
Seconding Yed. It is great for making structured diagrams. It is very quick to make good looking diagrams without spending much time on formatting and beautification. User interface is nice and configurable, though a bit counter-intuitive at times. I have been unable to figure how to make free-form diagrams using Yed, so feel sometimes that creativity is hampered.
Flowcharts are stupid. Simple systems can be internalized (kept in your mind, perfectly), and complex systems are too complex to graph to any human scale size or useful purpose. These two categories do not overlap. They apply recursively all the way down. Waste of time, no value.
Flowcharts are a great documentation and vizualization tool, if used properly it greatly reduce time required to understand system processes and behaviour.
For the rare moment when I need create a diagram in a computer, I'll use PowerPoint. However, mostly it's just the whiteboard or pen+paper. I like the chance to not look at the screen and, for the former, getting out of my chair.
Gliffy. It's not perfect but it is quick and easy to get something decent looking. It also has reasonable integration with Confluence if you're using that internally.
yUML ( http://yuml.me ) is brilliant for quickly putting together simple, nice looking diagrams. It's based on Graphviz and doesn't require graphical tools, just a basic text language, so you can throw together something for a demo in 2 minutes.
When you get to show the results to others - just use whatever you are presenting the rest of the message with - almost all "office" type products have sufficient capacity to manage that part. The clever bit is the bit you do by yourself.