Death to Lorum Ipsum?

I was just reading a post on lukew.com about issues with using Lorum Ipsum in graphic and application development.  The post points out how the use of Lorum Ipsum gives a misleading impression as to what the final product will be.

Using dummy content or fake information in the Web design process can result in products with unrealistic assumptions and potentially serious design flaws.

Personally I don’t think using Lorum Ipsum is a bad thing. I don’t think the problem is the use of Lorum Ipsum but more an issue with requirements and understanding what the outcome should be. The above mentioned “issue” would be the case if the requirements were incomplete or loosely written and ambiguous. In that event, the use of Lorum is the least of the problems.

I do agree with the fact it gives “unrealistic assumptions” of what the final will look like, but it’s not meant to be the final. In my experience as a designer, Lorum is often used in the prototype phase of a project where ever that is in the overall business process.  The idea at this point is being hashed out and tweaked to meet the initial vision of the requester. Most of which should be fairly close, provided the requirements are good.

I feel the post assumes there is data or copy to begin with, when in some cases content hasn’t been created. However, if the necessary data and or copy exists, it would only make sense to design and build the prototype with it in place. This would provide a closer “real world” picture of what the final will be. Another assumption made is that the data is dynamic which also is not always the case.  Again,this is the type of information that should be in the requirements. Yet, if a project does require a level of flexibility in the way it’s presented, it’s the responsibility of the designer to understand how to design the layout to be flexible. All which should be reviewed and approved while still a prototype.