I mostly write unattended jobs that shunt information around a relational database or two. For systems of this type, I generally start with a data model - either a new one, or I sketch out the existing structure. When I have a suitable data model, the processing steps required generally become obvious.

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.