As things evolve, I may start writing down use cases or capability cases on paper (well not literally paper, but an OO.org document or a text file, whatever.) And since all of the stuff I'm working on now (outside of $DAYJOB) is open source, this stuff usually winds up on a blog somewhere for the world to see. Here's an example of my first stab at using Capability Cases to describe something:
http://www.jroller.com/openqabal/entry/so_what_s_a_capabilit...
Note: I don't claim this "system" is the best - or even particularly good - it's just how I happen to work.
I've been developing a personal technique(mainly aimed at games, but general enough to apply to apps) I've been calling "cycle modelling" - which depicts user stories in a visual way, using feedback loops and (implied) narrative arcs - they are used as building blocks to achieve the core goal of the game or app(e.g. "edit photos" or "rule a kingdom"). The complete product is described as a composite of many intersecting arcs and cycles; even a rough model seems to help a lot in clarifying the design and features.
You can sign up and try it for free, takes a sec: http://chalkboardhq.com/
Really, planning out apps never really works. Once you start actually building and using the app you'll realize how different it is from the initial vision.
TL;DR: I plan out my app by building it out.