I swear that I will repeatedly tell users that nothing is guaranteed to actually appear in the final product, and that it may end up looking nothing like the mockups
Tried that many times, it simply doesn't work that way.
Problem #1: Users will have false sense of progress - There is nothing you can say or do to explain to your customers that what you are showing them are in fact only mockups. They can SEE with their own eyes there's "only" some wiring under-the-hood left.
Problem #2: You'll get all kind of design feedback - Which you typically don't want at this point. Any discussion about fonts and colors and visual identity and whatnot is at least counter-productive (if not straight harmful) while you are still struggling to agree on basic structure and functionality of the system.
Problem #3: Your developers will confuse mockups for GUI spec - We can say what we want, but developer's psychology (and power of abstraction) isn't that different from ordinary user psychology, we are all homo sapiens after all. Which means you'll have a very hard time explaining to your developers (whatever they might say) that your mockups are just a vehicle to test different ideas and to test mutual understanding with the customer. Not to mention developers simply copying the mockups into actual screens without thinking for 30 seconds, and usually complaining that the person creating mockups should have better understanding of their tool / framework / whatever to create more accurate representation of the actual GUI.
So what do you do?
First, you don't do "nice" mockups, at least at the beginning. Use pen and paper. Or a drawing board. Or a mockup tool that have sketchy / black&white look and feel. This way you are communicating that mockups are only that - mockups.
Second, don't introduce some formal and complicated "process" with your mockups, that also invokes "spec" mentality easily. Simply draw some related screens, comment them with users in live workshops, draw some more screens etc.
Btw you'll want to do that before coding has even started. You'll want to start with several "main" application screens, and when you have those reasonably pinned down, only then proceed with some kind of scenarios (whatever methodology you use), because it's important to get the customers in their natural business context right away.
I was so frustrated with all this that I wrote my own tool almost a decade ago (MockupScreens, it actually became quite popular).
Oh, and here is the most comprehensive list of such tools I know of, both free and commercial:
http://c2.com/cgi/wiki?GuiPrototypingTools
When choosing the tool, know in advance what do you want the tool for:
- High fidelity or low fidelity? Even prototyping right there in live workshops?
- Communicating via PDFs / Word documents, or just creating simple screenshots?
- Using the tool to produce something close to a spec or just use it for throw-away mockups?
- What's your target platform (the platform of the system you are developing): desktop, web, smartphone, etc?
- Populating screens with real-looking data to present real usage scenarios? (for this one, you can expect to have dozens of "main" screens but literally hundreds of their "children" with only difference being some on-screen data here and there
- What level of interaction do you need from the tool? (Most tools have "links" you can put on everything, e.g. to click on a button, but some tools are almost fully interactive)
- etc etc