This is a common and understandable problem, easily solved.
As we know software development is driven by requirements and features, and is a process of building something to meet the requirements while taking into account the issues, and this process is always motivated by some reason for achieving a feature.
You need to get yourself thinking about the issues and reasons for the decisions you've made in your design so far.
Having a simple document which walks you through the desires, the options, the issues and the decisions you've made on them so far will be all you need to boot your brain with the details necessary to start executing the development process, not least of which is your personal motivation for achieving a certain feature.
This is similar to the option someone gave above of talking to a friend, your documentation is your friend which includes sticking to the decisions you've made so far (important for progress).
Some recommendations have been to start with the small aspects, this is also taken into account here. The walk-through of your design should obvious start with simple premises and build up to more complicated rationale. There should always be a fairly simple motivation (rationale) for implementing a given feature, but often getting to that feature means booting yourself with the decisions that build up to that one...it's really just a matter of knowing the motivation for any unit of work, and that is an important aspect of system design that has not been well supported by the tools our industry has created for themselves.
Slashdot Mirror
This is a common and understandable problem, easily solved.
As we know software development is driven by requirements and features, and is a process of building something to meet the requirements while taking into account the issues, and this process is always motivated by some reason for achieving a feature.
You need to get yourself thinking about the issues and reasons for the decisions you've made in your design so far.
Having a simple document which walks you through the desires, the options, the issues and the decisions you've made on them so far will be all you need to boot your brain with the details necessary to start executing the development process, not least of which is your personal motivation for achieving a certain feature.
This is similar to the option someone gave above of talking to a friend, your documentation is your friend which includes sticking to the decisions you've made so far (important for progress).
Some recommendations have been to start with the small aspects, this is also taken into account here. The walk-through of your design should obvious start with simple premises and build up to more complicated rationale. There should always be a fairly simple motivation (rationale) for implementing a given feature, but often getting to that feature means booting yourself with the decisions that build up to that one...it's really just a matter of knowing the motivation for any unit of work, and that is an important aspect of system design that has not been well supported by the tools our industry has created for themselves.