Game design is enjoyable. It's freeing to grab a coffee and brainstorm a million awesome sounding game ideas. This is a good, healthy and necessary thing to do in the early design stage but there's a trap you need to be aware of; it's easy to assume the following:
Game Design is stage one. Development is stage two.
This isn't true! Game design is on-going. As the project develops and ideas start to become concrete sometimes the theory doesn't work in reality. Things need adjusting. Ideas turn out to not be fun or ideas conflict, or aren't possible to implement. Reality can hurt but it's guiding you to a game that can be implemented.
A cloud of ideas, or list of features isn't a game design.
After some brain storming you might come up with a concept for a game like this:
Oh it's going to be an RPG with seven levels descending through hell to kill a demon, there'll be 10 classes and async multiplayer. The combat will be actiony, and you can collect souls to set off spells. As you go through the game you unlock abilities and there are a few simple cutscenes with textboxes.
Is this a game design? No! How might you start this game? Start blocking out levels and make the transitions from one level to the next happen, get the player on screen, get his animation system designed etc. Right? That seems reasonable from this concept. But it's wrong! It's risky, it has massive potential for busy work and time-wasting.
You need to take this slightly fuzzy game concept and decide on a kernel to build the game around.
What's a Kernel?
A kernel is the stone in the middle of a fruit or seed. Think of a peach, when the fruit is very small the pit starts to harden in the center and the fruit grows around this. The kernel gives the fruit it's shape; everything grows around it.
When coming up with a game design you need to discover what your kernel will be. Ask yourself this:
What small, core interactive experience can I make that should be fun?
Before jumping into development, find this core experience. You might not get it first time but keep searching until you can say "Ok, this is fun". Then you can build layers of features and content around this core experience adding more complexity.
A kernel experience should be something you can program in a few days (or even better hours). Ludum Dare or similar game jam challenges will help you make this happen.
Even if it's only fun to you, that's fine, it's not the only content in the game.
Start with a kernel and build layer after layer of fun around it.
But My Game Features Can Only Come Together at the End
Consider redesigning your game so it can be developed from a core. This doesn't mean sacrificing complexity, it means moving the design around so you can start with a stepping stone that leads deeper into your game design.
Games that only come together at the end risk everything on something that's not anywhere near guaranteed. It's like going into a casino, walking up to the roulette table and putting 1000 man hours worth of chips on red twenty-two.
Imagine you pull it off, all these features are done and you play it, and it sucks. Now you're in a desperate search to try and the fun without having to throw everything away. This is not a good place to be and it isn't a place you have to be.
After the Kernel
Once you have a core developed make the game completable as soon as possible i.e. you're able to start a game, win or lose and be dumped back to the title screen. Then revisit the kernel and add on extra layers of fun, filling out the game with content and features.
Isn't This a Vertical Slice?
No. This term isn't precise but it's more of a very small game experience that's been polished to >70% final to give a sense of how the game will feel. It's used to give direction to a team that's responsible for filling out the rest of the game content or more commonly to show to a publisher in order to secure full-funding for the full game.
A kernel is far, far smaller; graphics and sound don't matter, it's all about creating an interactive experience that feels fun.
Isn't This an MVP? (Minimum Viable Product)
No. For instance if you're making a Spiderman game and you have a neat web swinging mechanic that's a kernel but it's not a product, it's not a game, it's a cornerstone for your on-going development.
This Wouldn't Work for Game X
This technique works well for game-like games, movie-like game or visual novel-like games are served less well by it. Trope games that already have their fun proven also don't need this technique but then you need to be sure you're delivering something novel or best of breed otherwise players aren't going to be interested.
Most other games this development method holds well. Maybe a horror game shouldn't be fun instead they're about creating an certain atmosphere (usually apprehension and dread). That's fine, it should start with that kernel and build out. The method of development is key not the exact nature of the word "fun".
Take Aways
Come up with your big-fat-game-design idea, narrow it down to one interactive experience. Prototype this kernel - does it suck? Iterate or throw it away and come up with a new idea. Once you have a fun kernel you're on the right path. Build out the full game loop, then start to fill out the game design space, play test it regularly.
Do this and you'll find it's easier to make good, fun games. You're less likely to pour your energy into something that was somewhat fun to make but sucks to play.