I like to think that everything around us can be represented, one way or another, through a diagram. Even if it is just a linear diagram representing the transition between the states of a particular object throughout time (like a living being, going through a number of states from birth to death). I use diagrams to lay down my thoughts and ideas for the actual implementation. I improvise quite a lot.
Therefore, my diagrams are most of the time at a very high level, and feel like mind maps.
To throw some examples in, this is actually a class inheritance map (one that's been cut) in my game where Interactive Object is the base type.
This is an FSM (Finite-state machine) diagram for a spikes trap (those awesome traps on which you step and woosh spikes show up from the ground).
This is a handbook diagram (named this way because it's intended to be a come back to it often diagram) that I drew recently. It outlines the components of a game, and also helps with gathering the required assets, as you can see immediately what's needed and what isn't. I recommend these on small projects, as they get pretty huge on big ones. They can be broadened further though, so that may fix things.
When I go to a lower level, it's usually because I need to plan the most intricate aspects of my architecture, and I usually deal with UML there. I never concentrate on outputting absolutely clean and correct UML though. I've adopted what I liked the most about the UML convention, and turned it into a nice mindmap-ish UML. It's simple and does the job for me, but I wouldn't go with it in an environment where actual UML is expected, for obvious reasons.
Another situation when I have to go to a lower level is when I have to describe actual algorithms. I use what I call flow diagrams. It is a format inspired by the diagrams used in white box testing.
A sample for the spike trap that I drew right now would look like this:
This is normally the final layer between diagrams and actual algorithm implementations. If the need arises, I detail the flow diagrams further (with extra executed instructions), and deduce or estimate complexity, and build accurate test cases.
I also prefer diagrams over pseudocode.
Not that related to game development, I also have a nice format to describe the screens in a multi-screen app, the functionality that the user can trigger on each screen, and the relationship between screens. I normally build these before starting the actual development, and they act like a map throughout the development process. If it's for a client, the screen diagram is even more useful! It helps me go through all of the project, from start to beginning, and take into consideration all of the functionality that it's going to need. Therefore, it's invaluable to providing an accurate cost and time estimate.
So yeah, I definitely diagram everything and anything. If I have an idea, I can and will definitely draw a diagram for it. If I somehow start a project without at least a very broad diagram to back me up, I feel crippled.