I usually start with a high level, highly abstract design phase just to start to get my head around the scope of my requirements.
Another thing I like to do really early is home in on my I/O since these are the only parts of the application that are settled down. I will design out the database tables so that they can provide me with all the functionality I'm going to need. I believe that form follows function, so putting these pieces together helps to give some more "reality" to the design. Designing the database tables also gives you a stepping stone into the DAL code. This is also where you'll be planning any info you need to grab from XML files or web services and those designs will help formalize the mechanical code that handles communicating with those resources. Then take a look at the files / web pages / etc. that you're outputing. Those are very real, very tangible things that give you a great feel for what the rest of the application is going to need to accomplish in order to complete those outputs.
A few other notes: I try to follow the guidelines in Code Complete 2 by Steve McConnell who recommends starting at the top, identify components that make up the current level of abstraction and then repeat the process burrowing down into each of those components. Keep going until you reach the point where it's easier to code the next step than to design it. That said, I find it suicidal to design too much up front. In all ways that don't affect the rest of the team, I prefer to design a little, code a little, make sure everything is going as planned, then design a little, code a little, etc.