I start off with a list of features, then pen and paper. Then I start building out the app in pure html without any style.
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.
I am old school: I use an SRS (software requirements spec) doc and start with the product's description, then features, then I create a development doc place in Confluence and JIRA for development trail--just like I do at work. There is no one way--everyone works differently.
I've struggled to find an efficient way to do this for years so I built an app for this... I still don't know how useful it is for people out there, and I haven't decided if it's worth turning into a product.
Basically, list some user stories. Then draw some diagrams based on those. Regularly head out for some coffee with pen and paper and write up some notes.
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.
I draft my ideas on paper with pen... very rough sketches. Then, I call a meeting with my team and we discuss it for a couple hours. I re-draft ideas, and then call another meeting. Discuss, redraft. The process repeats itself until the idea gets more and more exciting and we start coding, or until the idea loses excitement and then we shelf it.
I usually start with a pretty rough mental image of what I want, maybe draw a few rough sketches / diagrams / whatever on paper or on the whiteboard, then just start building and let it evolve. Once I have enough built to feel comfortable showing it to people, I start showing it around and soliciting feedback.
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:
7 comments
[ 4.2 ms ] story [ 23.0 ms ] threadReally, 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.
You can sign up and try it for free, takes a sec: http://chalkboardhq.com/
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.
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.