Write a Game Design Document... But Not Right Away

So, I've gone an pulled a sneaky on you. The Quarantine remake I posted about doing is not something I just started the other day. It's been on my mind for a while, and I've been actively working on it for about a little over a month.
"What was your first step?" You ask. If you're familiar with game development, you may snarkily add, "Surely it was drafting a detailed game design document?"
Absolutely not, you fictional know-it-all.
For those who may not know, a game design document (GDD) is a high-level yet detailed write-up of everything you intend to put into your game. Not so much from a technical standpoint - there's a separate document for that - but your game's structure, control schemes, game world details, character bios, monetization/marketing strategies, and so forth would all be outlined here. It's the equivalent to the "production bibles" used by film companies to make sure their fictional world remains consistent and fleshed out.
So why not start with one? Surely, you've started with an idea - why not get that down on paper before you lose it?
Fair point - keep some notes. Have a scratch pad handy to get down those rough, unrefined ideas. But let them stew before you commit them to a more formal document. You may find that, after a week of mulling it over, your talking sandwich sidekick isn't as funny as it initially seemed, or that on reflection, one of your fundamental game mechanics isn't as fun as it sounded while drifting off to sleep three weeks ago.
I'll give you a concrete example related to my Quarantine project:
The original Quarantine had a really neat diegetic ui:

Quarantine screenshot from MobyGames

All the information you need is presented to you in the same way it's given to Drake Edgewater, you player character. Health, ammunition, mission time, and so forth is all presented on your cab's dashboard in a clunky yet artistically appropriate way. Players can look (and shoot) out the side windows, and blood and bullet holes will appear on your windshield as you interact with the game world. I had initially imagined doing something similar but, as I intend to add lateral movement (i.e., strafing) to the car's controls, this up-close first person view isn't as useful. to get the spacial awareness to strafe effectively, I decided a third-person view a la Grand Theft Auto V would be more appropriate, which would make a cab interior-inspired UI no longer diegetic. If I had started with a GDD before giving it enough though, I'd have to go in and edit it.
Which, to be fair, isn't a bad thing. After all, a GDD is meant to be a living document - it should be frequently updated - but the more poorly-thought info that goes into the document means more room for missed corrections.
There's another reason starting with a GDD may be a poor choice for you: Motivation. You could spend so much time planning and detailing your project that you don't actually spend time working on it, and you lose the momentum you need to continue on. That's a big problem for me personally; I start projects strong, and lose steam along the way, eventually being replaced by a new project.

Memes. amirite? From Reddit.

Instead, I flagged a few things that may present a challenge, and dove into prototyping it. In this case, it was the controls for the player's hovercab. Would I need to use Unity's physics forces to keep the car aloft? Could I use wheel colliders, but with invisible wheels? Could I fudge the effect with an invisible "sled" collider? And in what ways would controlling a hovercar differ from a wheeled one? Diving into this discovery and prototyping phase was much more engaging than sitting down in front of a Word document for hours, and I'm glad I started with it.
Of course, your mileage may vary. But in general, my advice would be to find something you look forward to doing and start prototyping. It may end up changing your vision, or details thereof.