Site maps – and by that I mean the information architecture documents used in the web site design and production process, not the catch-all navigational monstrosities found lurking in footers far and near like some trenchant swamp-thing biding time to attack – are pretty much the de facto method of visualising site structure in a way that can be documented. They’ve been around for years, Jesse James Garrett has come up with a formalised visual vocabulary for expressing them. Known, perhaps not loved, but certainly tried and tested.

Site maps generally fall into two different categories:- those that document the navigational structure of the site, and those that describe interaction flow. As the days of enormous, static sites vignette to make way for sites driven by logic not links, we naturally see a shift in emphasis from navigational maps to those which document interaction. The question worth exploring, however, is can this form of documentation continue to prove both useful and a valuable investment of resources?

Drawing a distinction

Both Garrett’s visual vocabulary and traditional flow-chart systems use special diagram items to represent decision points. These are used when a choice has to be made, usually as a result of user input. The experience can then follow distinct paths for a time, ready to merge again, if necessary, once the condition has been satisfactorily handled.

Garrett’s recommendation and intent is that interaction flow diagrams are distinct from, and should be complimented by, navigation diagrams. In practise, I’ve seen this point to be largely missed, and the day-to-day reality can that one is (ab)used to incorporate the other. Either way is bad, as things fall apart when we encounter decision points. The concept of each object representing a page or group of pages is shattered with objects representing choices. Clearly this cannot work for a complex web application.

From navigation to logic

So I think it’s reasonable to assume that the idea of a navigational site map as the complete blueprint of a site has to be put to one side for development of a web application, with the purer concept of the interaction flow diagram – as detailed by Garrett – being a more logical and useful replacement.

For the implementers on the ground, this could involve quite a shift in working practises. A navigational site map is a very practical tool for implementing a big static web site. It can be used to work out the structure of a site before the visual design has been done, and then used again during production to work out just what is supposed to go where. It very practically answered that age-old question “what the heck does that link to?”.

Working with an interaction flow diagram helps answer that question too, but in a rather more abstract way. It won’t tell you where to link to, but it tells you what you’d expect to see when you get there. It’s the picture postcard without the plane ticket. It lacks the implementation detail that was so much a benefit of the navigational map, replacing it with a higher-level concept.

Truthfully, I’m left wondering how much of a help the process of documenting every last aspect of the interaction flow actually is. Obviously parts of an application will require a great deal of thought, but in likelihood, much of it will be routine. It sounds very much like the right thing to do mapping everything out before you start, but consider all the routine logic in something like a login form, does it really justify mapping it all out on paper? Will that time expense be recovered?

Being pragmatic

I’m not sure I completely subscribe to the 37signals idea of the interface is the functional spec, but there are certainly pragmatic advantages to this approach when used in a measured way. Every minute spent documenting a completely obvious (or insignificant) feature or process is a minute lost from the project. Will having a process flow diagram for a routine login form help me implement it quicker? Unlikely, as the chances are it’s already been written in a past project or by the creators of framework du jour.

Perhaps an approach combining a number of different elements would be more appropriate for developing web applications. How’s this for starters.

A basic navigational map or maybe two if your logged in/logged out states are too different to clearly show on one diagram. This should be basic, listing the main sections and pages, but not attempting to unravel the complexities of individual features. Example: Checkout would just be a page stack.

An interaction flow diagram for each key feature. This is where you delve into that checkout process and define how it works. In pictures. Everyone’s checkout is different and most of them suck, so here’s where you go through the careful process of designing how it works. Make sure there’s a reference to the appropriate page stack on your navigational map so you can join the dots.

A URI map detailing the design of the URI structure for the site. If you’re building RESTful apps (and you are, right?) this should give you way more information about the technical implementation of the app than any database diagram or functional spec can. And quicker, for less work.

Does that sound like it could work? Perhaps there’s some useful trick I’ve missed. Let me know.

P.S. I wrote this over too many sessions and edited it too much and now it sounds like a damn essay. Sorry.