There's nothing like that first moment after a kickoff meeting to sit down with your coffee, do some research and make a few sketches and/or wire frames. It's a great way to spur discussion and get people from different disciplines to weigh-in with feedback as part of the pre-design phase. There are some things to consider for the typical waterfall model, and these are the basic points I tend to follow...
The result of waterfall
Preparing complete design documents is a lot of work and can turn out to be, "design debt". Every little detail has to be documented. If anything is missing for engineers or API teams down the road, the result can lead to confusion and lots of redesign to the document, or worse—a cascade of production failures resulting in a half-baked interface and poor user experience. No matter how much fun it was to design, you may be disappointed with the result if things didn't go well in production.
Scrum
Agile Scrum is a workflow where you work collectively with a team to enhance existing features, or design and build a product from the ground up. We gather to discuss the user journey, write user stories (notecards with acceptance criteria on the back), and I'm always fascinated by what my scrum teams contribute. It's a chance to sketch on the dry-erase board and share ideas before I start wire framing; it's a chance for everyone to be on the same page.
User Testing and Scrum
As the weeks progress, and the first installments of a product become available for testing, it's time to pounce! Scrum without user testing, would be like a car without a steering wheel. As the car makes it's way down the road, you need to know where the road blocks are for users and it's important to user-test and implement changes as you go.
Blending Waterfall and Scrum Strategically
It's been my experience that pure scrum, without a little bit of waterfall, does not function well for the team.