There are two main aspects to software development: (1) static design and layout of visual features, like labels, edit fields, buttons, etc; and (2) processes that occur dynamically whenever certain actions are triggered.
It doesn't help that the term "designer" has been co-opted by the industry as of late to refer to visual designers rather than logical design. Both are important, but this blurring of the line is causing a lot of problems because graphic artists are being given roles to do back-end database design, UX workflow design, and all kinds of other design layers for which they have no particular training or skills.
Flow charts are the documentation historically used to communicate a design to programmers, although they have to be written by other programmers. And I personally find them far too detailed. They're annoying.
At the early stages of development, you need something that illustrates the rough layout of all of the forms and screens in the app, as well as the flow between them.
It seems people are now referring to "menu layouts" as "wireframes" to explain how users navigate through different aspects of a design. That's nice, but it imposes a certain structure on the overall application that may not be needed in the end result.
Just use any kind of structured diagramming tool to lay down blocks, put short descriptions in each one, draw lines between them with arrows, and label each line with an action trigger. (Worst-case, you can even use Word, although it's really a PITA to manage the layouts on pages.)
Each block should represent a form or dialog of some sort. Create a rough mockup of each one, identifying each field and note any specific behaviors that you envision going on.
Each line is an action trigger, like "mouse-over" or "button-click". If there's anything not obvious about it, then add a note.
At this point, you want to do what I'd call a "mind dump". Just get out what you see in your head onto some kind of canvas, which is oftentimes easier to do with pencil and paper.
Again, it's the wrong time to worry about the "look and feel", color schemes, and widths of bevels on buttons. Because I guarantee you that however much detail you think you've captured, it's probably 1/3 to 1/2 of the overall solution. Do not waste your developers' time with eye-candy when you don't have the overall design completed.
The specific tools you use are pretty much irrelevant in my mind because it's the layouts and flow you want to communicate. The developers have their own ways of taking that and turning it into something else that's more useful to them, and that will probably make no sense to you at all. They might even be able to generate a more formal document with better design tools that are far more technical than you'd ever want to use.
Only after you've got the overall architecture of the app laid out, then you'd get a graphic artist involved and apply some kind of "theme" or "style" to the app. Trust me ... doing this too early will lead to useless arguments in design meetings about things that are totally irrelevant to the functional aspects of the software.