Jamie, this is always a good subject to discuss within the community, so thanks for bringing it up!
First, however, I'd like to underscore what others have already said regarding how we all want to present ourselves professionally in our discussion forums. Those of us that have been participating in online forums since the 1980s know all too well the challenges associated with communicating in the limited bandwidth of text responses. Ours is an incredibly and beautifully diverse community of professionals, with an equally wide array of approaches and methodologies used to confront our many design challenges. Civility and mutual respect are always and forever going to be our first order here. Listening to and respecting the voices of others is our best approach to encourage a sharing of our many skills and experiences. As for design specifications, as we see, there have been a number of solutions mentioned above. Since I began consulting in Interaction Design in 1983, my approach to interaction specification has largely been in digitally-created print documentation. Even as interactive means began to appear in the late 1980s and beyond, I've stuck to blue-print-like specs, but I understand why others prefer different methods and everyone should work with what works best for their situation. With my own work, much of the interaction stretched across both digital and physical controls and displays, so print documentation provided a way to efficiently and simply documents flow, interrelationships, and logical rules. Also, print documentation, if adequately detailed, is very very efficient and compact. It's relatively easy to instantly turn to a page or descriptive paragraph explaining the logic or behavior, as opposed to having to reverse extract that from playing with an interactive model. Again, interactive models are not bad. They can be utterly necessary and it's never bad to have for testing purposes. That's primarily what I've used interactive models for. I like to think of it as the blueprints and the 3D model that architects use. One cannot imagine a skyscraper being built only from a 3D model. Blueprints are very valuable reference documents, which can and should contain minute details. Also, and this mostly applies to consultants, but if you're working on a large variety of products or services, perhaps built on entirely different platforms, operating systems, or devices, it's highly efficient to use print documentation to specify the Interaction Design. Print documentation is also easy to collaborate with, since documents can be marked up and written on. My own consulting was often based on iterative one or two-week design and documentation cycles, culminating in a master aggregation and refinement process to produce the final, large design specification document. Templates? Well that's where this is an interesting question for me. Looking at my documentation, it's easy to see a general, mostly graphic design kind of format that I used, but that's pretty much where my templating stopped. I never was able to be happy with tools like Omnigraffle, etc., because I always wanted to move things around and pack in information with my own flow lines. For that reason, I've used Adobe Illustrator and Photoshop for many years. Back in the 1980s it was MacPaint and then SuperPaint (which was an awesomely efficient and integrated tool for pixels and vectors, though was based on QuickDraw rather than Postscript). I'm always happy to share my many printed specification documents with others (when we're together), but their sheer size (many the size of small phone books), are rather hard to share electronically. I do have some photos and samples from some of my projects and their specification documents up in my 2005 slideshow here: http://www.orbitnet.com/iasummit2005/iasummit2005.html Bear in mind that when you see two or three pages of specs from one of those projects, there are probably a hundred or more additional pages. Interaction Design specification documents almost always covered the following: 1) An up-front encapsulation of features 2) Hierarchical or interrelational maps or diagrams of the system 3) Interaction flow diagrams (with varying degrees of fidelity from wireframes to full screenshots). These would also have a lot of descriptive text and callouts for explaining and directing. 4) Full-scale/resolution state screens (when appropriate) 5) An index of all individual implementable graphic resources, along with location coordinates (if necessary) and behavioral documentation. One thing that my approach to documentation has made possible over the past decades is very close, if not perfect implementation of my spec. And this is why I continue to see my own approach to Interaction Design as that of an architect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Posted from the new ixda.org http://www.ixda.org/discuss?post=32403 ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
