Designing for the web is part art and part science. The science part includes having a certain process that one goes through while working on any project. A defined process ensures that one doesn't skip a crucial stage; what might at first seem like overkill usually isn't.
The research phase is crucial. Depending on the project, this might have already been done by someone else, but as a designer it's imperative to understand the background of the project. Some key questions to ask are:
The answers to these main questions usually lead to more questions, and gathering feedback from the client helps establish a solid plan of action for the work. This phase should include customer interviews, to get details of what the end user is trying to achieve.
Many designers make the mistake of jumping straight into their mockup tool of choice (Photoshop/Illustrator etc), but it's a lot smarter to do some low-fidelity sketches first. Paper is cheap and a pencil is faster than a mouse. Quick and rough sketches mean that you don't get too attached to any solution.
I use this stage to:
Sometimes the sketching phase isn't distinct from wireframing, depending on how refined the initial sketches were. Wireframes formalize the sketches a little bit if they finished at a very rough state. Depending on the needs of the project, these could be made (using a tool like Axure/Invision/Keynote or something else of your choice) interactive or static.
I prefer to keep these fairly low-fidelity as well, since this is not the stage to worry about colors, typography, or other important details of visual design/communication. It also helps keep the focus on figuring out whether the flow is working or not. Quick user testing with these wireframes helps reveal flaws in my thinking or assumptions, and reinforce the importance of keeping the end user in mind.
This is the fun part, where the needs of the project are taken into consideration to come up with a look and feel of the solution. This is a good time to play with colors, typefaces, visual styles etc. Generating a style guide to help with development work is a great idea as well. I prefer this method because the look and feel of a website or an app is a result of how the various elements interact— type, color, buttons, links, forms etc.
Depending on the team I am working with, I may or may not be involved with development. I am happy to transform my design into markup, but it makes sense to collaborate with dedicated developers on more complex projects. However, I have the ability to make smaller changes on the fly if needed, rather than bothering a developer to move that button 3px to the left!