I use Workflowy as well to keep track of my progress and planning, but it's for a line-art tool that I try to keep as simple as possible. Here is the project's workflow. I document my progress simply by dragging items from the to-do list to the completed list. But I think you have to decide what exactly you want to document and why. For a one-man team, you have to be careful to balance your time between making actual progress and documenting that progress. I think a simple documentation approach like this is suitable for small and technical progress points, and make a monthly-or-so detailed and well-written blog post to go over what's been done during that month.

In the early stages of my project, I don't have enough specifics of my game to document a full GDD. I know I want to build a turn-based tactical dungeon crawler but that's about it This is the 50,000 foot view. I code some of the big pieces that I know I'll need and make sure they fit together and see what works. At this stage, I have a Notes.txt file that I check into source control where I jot down decisions, ideas, and bugs. Sometimes there are check lists, other times there's a need to do and a done section. And I journal about my progress every one to two weeks here at game dev. If the game looks like it could be fun, I keep going. If it's missing that spark, I switch ideas or revise my original.

My rough workflow for individual features is:

• figure out what needs to be done
• Make it work (sometimes hacky)
• Make it right (clean up the code, comment it, factor things out into funcitons and classes)
• Make it fast (if performance is a problem)

I'll usually spend a couple of hours to an entire day per week cleaning up my code and making sure I'm not coding myself into tons of technical debt.

In my current project A Voxel Adventure, I'm moving into the middle stage. Here I start getting a clearer picture on what I'm building. I take some time to document my decisions in Google document(s) and decide on the scope of the project. I write down all the features I think I'll need and assign a complexity value to each task.

• 1 = < a day
• 2 a few days
• 3 about a week
• 4 a few weeks
• 5 Ugh, I need to break this down into smaller tasks

This gives me a rough idea of the amount of work remaining and shows me the types of assets I'm going to need (art, sound, etc.). At this stage, it's good to start looking at the tools you might need for yourself and content creators to make their lives easier (see my journal posts on Unity's Content Pipeline and Editor Extensions). Once it starts looking cool, it's also time to start marketing. Don't make the mistake that you can predict your release date at this point. As you continue working you'll say to yourself, "Oh wow. Wouldn't it be cool if it could do X" or "Holy cow, this feature isn't going to be fun at all, so I'll scrap X, Y, and Z". In this stage the scope of my game will fluctuate (usually by growing). If the game isn't fun, time to go back to phase 1.

I chip away at this growing list until I finally start knocking out more features than I'm adding. In the later stages any kind of awesome new ideas get recorded for version 2 or another game. The release date stops wiggling around so much and you can start to really polish your game. In an ideal world, everything gets documented and you have a nice little audience of people waiting to buy your game ready to pay for it when you finally do release it.

Then I sell it and continue living the rock-star lifestyle of the indie-game developer with all the fast cars, loud music, and screaming fangirls. This is my current plan at least.
- Eck

I prefer the Blog approach as a Design Log so It can be turned into a Game Concept Document.

Ex: Board Game Iteration to try out game balance.
Header: DATE-TIME - MECHANIC NAME - ITERATION #
Body:
Play Notes: What went right or wrong with this iteration;
Prioritized Next Steps: A list of the wrong things and if they are worth fixing;
Tasks Accomplished: If it went right how did it affect the gameplay;
Experiments: What other innovations you may squeeze out of this iteration.

And you keep bulding up other iterations or changes. My first post always is the game Concept or the main mechanic, you can break down the "blogs" for each mechanic.

This way you can allways check what was done and when it was done, why it worked or not and so on. If you do this on Evernote or Google Docs you can get team members inputs on each iteration. It can sub the TODO List also.

Hope it helped.

Regards.