in reply to Software design -- The confussion of buzzwords
After that, it is a case of looking for areas of commonality in the process, and factoring these out as subroutines, utility modules and classes.
I think design becomes more of an issue with interactive systems, because of the potentially large number of states and transitions. I still start with the data model, but I might sketch state transition or process flow diagrams. Then I start coding, pretty much the way you described, blocking out the program structure first, and filling in the subroutines and methods later.
In my experience, software design doesn't change when a team is involved. But the practice of coding is severely impacted. When you get several people working on related code, individual productivity takes a hit, and you have to get more organised about testing, source code management, release control etc.