There's more than one way to answer this question.

1) The proper "game design" isn't really a stage as such. It lasts the entire project, and you have to make decisions the whole time about how various features are going to work right up until you burn a gold master

2) The preproduction phase, wherein code and art are limited to prototypes or even nothing at all, typically lasts between one and six months, based on my readings of Game Developer. This "design phase" includes creation of a design document and a large number of business decisions about the process of making the game, including staffing requirements, preliminary high-level technical design strategies for the product, and components to purchase or build. In organizations that use them, prototypes for gameplay are typically built rapid-fire to refine the design concepts. A preproduction model of design has the advantage that the design resources can start preproduction on new projects shortly after the previous project goes into production mode.

3) The creation of the design document. This, in professional circles, appears to congeal over the space of a few weeks to a couple months at most, and results in the creation of a cohesive description of all in-game processes and assets, but usually very little in the way of implementation of those descriptions (sample art/prototype technology aside). This would account for about 1/2 to 3/4 of the work involved in a preproduction phase

4) The technical design of the product. There's very little information about this side of the industry, but based on my non-game design experience, I have to place it at about 1/10th to 1/4 of the effort required for the preproduction phase.

5) The creation of a demo suitable for display at shows such as E3. This is an effort that's pretty well-scoped for the A-list titles, and it's usually somewhere in the neighbourhood of a year to 18 months for a serious team working on a top-notch title.

My experience with non-game development puts the design phase as being 1/4 of the time the project is going to take. Most companies run on yearly release cycles, so 3 months are spent planing and designing and doing tech demos to make sure certain things work. All before any actual game code is written, any art is made, and usually before any real cash is allocated to the project specifically.

Though this is with a very large company who can dedicate people to just doing project planning and design. In the gaming industry that luxury likely isn't open to very many.

What it all comes down to is "however long it takes to get it done." For some people it will be longer or shorter. For different games, it's going to be longer or shorter.

It depends how many people are working how many hours a week. A full time staff of 10 people could probably do the design for an RPG in 6-9 months, but a handful of hobbyists working in their free time might take more than 2 years.

I think liquiddark is right about game design lasting throughout the whole process. While I can't speak for my practical experience in developing games, most software process life cycles have some form of iterative and incremental design loops built into them.

For example, in the classic waterfall method, you seperate the requirements, analysis, design and implementation (and maintenance) each layer needing to be completed before you can start on the layer below it. However, even with this venerable process model, there are feedback loops so that discoveries in any one stage can percolate back up to the next level. More modern software process models take into account that as you analyze the requirements and do the design and start implementing the code, you'll get feedback about what you really want to do or what you need to do. So you have to go back and reanalyze and redesign and recode. So as liquiddark pointed out.....you're never truly done with the design phase.

I probably err on the side of taking too long to do my analysis and design stages. Ironically, at least from a pure software engineering standpoint, this forum "Game Design" isn't really what's meant by design. In fact, this forum should probably be called "Game Analysis" or "Game Requirements". But since we're speaking of design as meaning "game ideas", even though the design process never really ends, make sure you don't get trapped in the "moving target" problem. Essentially this is feature creep that gets added in that doesn't add to the core essential value of the game you are creating.

Technically speaking from a broad software engineering perspective (and not just the game industry per se, which may have totally different terminology), almost all of the posts here have to do with asking the question...."What do I want my program to do?" or "How can I do a better version of feature X in game Y?". That's a question normally asked in the requirements analysis. Analysis in a nutshell simply asks, "What should this program do (functional requirements), and what kind of experience will I get from it? (non-functional requirements)".

The design stage is when you start figuring out how to take the requirements and do high level design (which is more abstract and covers things like systems analysis as well as how to decompose the system model into its constituent components for example) and low level design, which deals with things like figuring out what data structures to use or what algorithms to use. In other words, from a software engineering perspective, design is the beginning of the technical planning for your game, not the content. Analysis is trying to transform the question "What do I want my program to do?" into parts that can be modeled by the computer as well as what (and how) actors (humans or other systems) will need to interact with your program.

Good analysis and design may take up more initial time, but it also allows you to better understand what exactly it is you're trying to create. In turn, this means that your final code can be tweaked or re-implemented much more quickly especially if you realize that a feature you wanted isn't exactly how you want it done. So if you're doing this as a hobby, I think spending lots of time on design and analysis is a good idea. In the real world however, time is money, so you have to make some concessions.