One of the issues that Jeremy Boggs mentioned in class, and which I have seen in some of the recent writings that have been assigned, is that detailed wireframes take a good deal of design work out of the hands of designers. As someone with an interest in design I find this disappointing. In many ways I would like a design framework created by a designer to determine the way content is presented. I think, for some intuitive reason that the final product will just ‘look better’ this way.
But, a cool looking site, is of course not the only consideration for web site development. And as Dan M. Brown and others have reminded us, sitemaps, wireframes, flowcharts, etc. are communication documents, often used to present to stakeholders and to be used by the web site staff. Designers might not have a solid grasp on which content should be prioritized, something the IA team spent a great deal of time on. Wireframes and sitemaps communicate this to designers. Wireframes are not the design of the page, or often even the final structure used for web pages. And hey, given the smaller staff many of us might be working on, the wireframe designer and the graphic designer will often be the same person. Overlap is everywhere.
Okay, so maybe a lot of that was obvious, but I recently had a wireframe conversion experience. At CHNM, I am working on a information architecture redesign. As the site is now, many pages consist of a subject heading, like Online Resources with the content consisting of a list of links. The links are simple titles like, Operational Archives. I’m sure you could guess what that is, but I wanted to suggest some contextual information for these lists of links (the scope and content of the document holdings held in the Operational Archives, for example) and I think a wireframe will help me communicate this.
Honestly, with smaller sites like the one I am working on for this course, it is harder to see the importance of these steps to the process. I feel like I can visualize the entire project in my head, that I am just communicating this information to my professor and classmates. It seems that sitemaps and wireframes are amply able to do this, and working through them revise my assumptions only slightly. On larger projects however, playing with sitemaps has made me think in different directions entirely and has made me appreciate wireframes, which make up for the limitations of presenting pages as just a box with a title in a sitemap.
I found Watson’s Page Description Diagrams post, and Litanzious’ Content Sitemaps to be very valuable. I have a tendency to want to jump ahead to complex layout diagrams for wireframes, but content description and priority are the real reason for creating wireframes, and these text heavy documents helped me understand that more clearly.
Document 
Clearly when you know as much as you do, sitemaps and wireframes for smaller projects must seem like uneccesary steps like showing your work in a division problem in which you already know the answer. However, going over the basics probably never hurts and keeps you from missing something.
I know what you mean about the sitemap/wireframe exercise for sites initially this small.
I think that some people, however, are working on projects which will continue to expand in scope beyond the course assignment context; in which case it will probably be good for them in the future to have thought these things through in advance.
For those of us not already familiar with working on larger projects this kind of assignment helps us to visualize how the process will work in a larger context.