I think when you roll in the client or clients, a contract developer or designer, a web development shop, a consultant or ‘friend in the industry’…you need a gameplan, otherwise expectations of each party can be different. Everyone wants a say, everyone wants their ideas ‘on the homepage’, etc. You need a plan and documentation.

I once worked at a firm that had owners, AEs, PMs, developers, clients, the client’s bosses, client’s ad agency, etc all in the mix talking about features and technology. There were also designers in the room. Until we got a documentation process down, and let the designers lead it, we couldn’t get good work out. The IA thinking on a whiteboard and wireframes were a way for the designers to lock in good functionality and fend off poor choices. I think wireframes are more for protection of the product in a less than ideal development situation.

I am working on another project with a team of 4..I’m the designer, 2 developers and 1 who floats between the two roles and handles business aspects. We go straight from sketch, to screen design, to development with no specs (the design is the spec). It works perfectly in this arrangement.

How do you even go about a project without *some* type of documented planning? Maybe the UI and work flow magically appear in your head, you have a perfect visual memory, and no organizational buy-in, or negotiation, or sharing of ideas is necessary until you get a highly dynamic PROTOTYPE (to you probably known as the application-in-progress). Or you just get buy-in after your new application is developed, and everyone agrees with your vision and no revision is ever necessary. Must be nice.

I, for one, have used every type of prototyping imaginable depending on the particular situation.

Sometimes I’ve found it absolutely critical to do a paper prototype for myself, or to show a developer, and other times I dive right into HTML (for web-based apps) when I’m doing a slight redesign of an existing page or process.

Othertimes I’ve created excruciatingly detailed Bitmaps to spark the imaginations of people who matter; and god help me, yes, Powerpoint has saved me a a number of times when I needed to do some quick and dirty user testing and development on the new feature started yesterday.

So, please, please, please, always second guess yourself when you’re thinking in absolutes, especially when it comes to design. We can’t all sit around with Ruby on Rails working directly with our client, pleasing him/her as our ideas take the form of a working app, and expect the users to be happy every time.

As mentioned above it would be wise to create a better prototype than scratched on paper if someone else is responsible for implementation. Communication and getting buy-in is a large reason personas, use cases, etc… exist. If the functionality did not already exist and was any more complicated than the functionality described, diagrams and more thought can go a long ways.

Getting Real needs to be done more, and taught more to those in school. The practices of Personas, Use Cases, and Wireframes have been developed and should be used where they are most effective. 37 Signals recognizes this, and I imagine most experienced designers do as well.

I know from personal experience and experience working with you that I never have the best idea first. If I make a wireframe it will often be revised multiple times before everyone agrees it’s a go.

I’m not saying every client deserves a branded wireframe and sitemap, with detailed case studies/user profiles. But, what I am saying is that at some point, for a project to be successful, the thought processes that drive these deliverables NEED to happen in order for success to be achieved.

I can’t figure out if Jason is saying we need to do away with the process of thought, or simply the process of creating the representations of the thought(site map, wireframe, etc), but IMO, by iliminating the thought, you eliminate a crucial factor in the success of your site/application.