Generally, and probably not strictly in this order, I tend to work like this:

Gather user or desired requirements. This is usually more complex than it starts out sounding. It tends to run from UI elements, desired functionality devoid of UI requests, desired output and displays, application management functionality, user management, "what happens after that?", "what should we see on *this* screen", etc. Also included are data requirements, etc., so thinking regarding data storage, existing db mods, and the like can be worked on. My experience is that this step is repeated many, many times throughout... :)

Gather resources based on what I know so far. That may mean investigating existing app(s), db and structure, CPAN exploration, lots of books, etc. Generally I do this pre-design to help me start thinking it through. I'll look for prior solutions, etc.

White board, butcher paper, markers, etc. Flow charts, liberal attempts at pseudo code (which is where I get ideas about modularizing code, etc.) Often the pseudo code then gets summarized into an outline or diagram form as an overview. Try to explicity define any/all subs, objects, modules; in/out for each, etc.

Write tests for discrete units. Often, this is where I tend to shortcut and it's a weakness.

Code a first layer of core functionality, test. Add more functionality. Generally, I try to 'get the basic issues functioning' first, then layer onto it. At various stages I'll return to the first step to double check if we're on the right track - but the warning here is that there can be way too many changes if this is done too often. Big surprises in design or major feature creep are really undesirable at this stage... lol

Test, etc... prior to alpha/beta.

It's a very dynamic process for me and not as rigid as it may sound, and probably not near as formal as more professional folks may approach it. It's always seemed important to me to get the core functionality working as quickly as possible for my own morale, and for the morale of any team members and/or clients...

I've used a few design tools, but my tendency seems to be big white boards, big pieces of paper and diagrams as thought tools first. Should the project or client seem to require formal paper stages, or if the project is complex enough, I/we certainly do them.