I tend to think in terms of architecture, so how the data will fit together and what the major compontents will be. The functional requirements are usually something that crystalize in my head on the back-burner over a period of weeks until I pull the trigger and jump in. I often write some throw-away code that captures some of the non-trivial couplings between pieces as a proof of concept and then start filling in the gaps upwards.
Usually on the interface side there's a separate process that meets in the middle. I'll often either do some dummy HTML pages or (yeah, laugh) Keynote slides that give me an idea for the interactional mechanics.
That said, and it probably shows, my strong suit is in developing libraries, not applications, and I tend to paint with that brush even when doing apps.
That's pretty much where my webdev style comes from too --- library design --- so that, how I write C library code (foo_new(), foo_release(), foo_get(), foo_put(), etc) just gets expressed as (say) Sinatra handlers.
Then I call the library in different ways to build something useful out of it.
Never thought of it that way, but that makes sense to me.
Usually on the interface side there's a separate process that meets in the middle. I'll often either do some dummy HTML pages or (yeah, laugh) Keynote slides that give me an idea for the interactional mechanics.
That said, and it probably shows, my strong suit is in developing libraries, not applications, and I tend to paint with that brush even when doing apps.