Designing a computer system (and that means everything but the coding) is constructing an intermediate vocabulary and language such that, when things change, your intermediate language can already express the new conditions. Now you can do that with functional code and a DSL, or you can do that with OOP and a class model. Since you're going to .NET, let's assume OOP.
You've got two things to do before coding: analysis and design. Analysis is understanding and creating that language I spoke about. Design is implementing a solution with that new language inside a certain environment. Coding is actually detailed design -- it's the same thing. In OOP you (generally) move smoothly from talking to the users about their world to coding the computer. In greenfield programming there are no major jumps like you would have with waterfall. The goal of all of this A&D is to get classes, code units, tables -- big hunks of stuff that will organize your code. Small systems you should be able to burn through A&D in days or hours. Big systems can take much longer.
Now there's all kinds of tricks to making good languages, er, object graphs. Too much to go into here. Just remember that the purpose of OOP is that when the customer says "But I'd like that green if the bank account balance is over $200" that you should be looking to tweak something regarding the class BankAccount and the member "Balance" -- the customer's language is your language. This is what makes OOP rule large development work.
Now that's the 5-cent version of OOP. As for "What to do, when" it's real simple -- do the stuff the team worries about. Having said that, it's perfectly fine to use a "recipe book" like RUP, MSF, Agile, etc to help you remember stuff you should be worrying about. In general, just like in coding where you move from talking to the folks to making the code happen, you should be thinking of "stuff to worry about" starting with business concepts "Do we know what they want? Are they going to pay for it? Do we have access to the key players?" Then you move towards technical concepts like "Are we sure a relational database is going to handle this load?" or "There's no way the user is going to wait more than 5 seconds at his browser" But there's no rule -- you can have killer business risks later in the project and you can have killer technical risks earlier. The trick is to be constantly moving from big, fuzzy, general, business-type worries to little, clear, specific, technical-type worries. If you get your "conceptual cone" working in a project -- designing and managing from big concepts down to little concepts -- it's like riding downhill on a greased rail.
I've probably proven myself a complete idiot for trying to take on such a huge topic in a blog post, but there's a lot of "noise" on this subject: the core principles are not supposed to be rocket science.
I think that's a great description of the process. I would make the point that designing on customer language in OOP is one of those things experienced programmers shy away from. The next paragraph about "What to do, when" is a much better source of OOP design. Just to take the example of account balance, in looking at business-type worries it would probably become clear that transactional integrity is a big deal in this kind of software, so you'd want to clearly separate out queries on the balance and modifications to the balance and restrict access to the functions. These sorts of pressures, along with technical pressures much more clearly describe the design parameters.
