If a problem is less complex or can be released iteratively, than that's the lean way to do it, where you also have good learning. But often to solve the problem just a bit you already need a load of stuff to be taken care of.
Key to me is to stay in text or cheap click-dummies for long enough. Depending on the complexity I go through several stages:
- Always probe for details if you can imagine some already, you are trying to know as much as possible as soon as possible. File it all in to a "to take care of later"-list at least, better yet sort in properly already.
- write down everything (maybe others can remember everything, fine too :) )
- change and refine whenever something new has to be taken care of. IN the following steps it will always be easier now, than in the next step.
1. gather high level requirements with the stakeholders
2. sketch a rough workflow. I usually do a nested list.
3. write down a complete workflow
4. now you might know what you need, so define a rough UI, technology, interfaces
5. still in text: write your concept so someone else understands it
6. talk everyone involved through the concept (first stakeholders, than devs)
7. double-check if you cant simplify or leave out anything, at least for a first version
8. if necessary: do mockups, designs, schemas
9. only now start to program (for difficult stuff a prototype)
- On top it might be helpful to have a small checklist depending on your needs with entries like "reporting?, testing?, support?"