In the early 1970s, University of Oregon students and faculty were not happy. Sure, academics have a knack for disgruntlement, but this was a special sort of dissatisfaction: the kind that led to action.

They protested against over-logging, destruction of historic sites, the military draft, American invasion into Asia, and, particularly close to home, the new brutalist style architecture taking over their campus. After enough huffing and puffing, the university administration decided that, while they couldn’t stop all the wrongs in the world, they could take more control of their own facilities. So, they hired Christopher Alexander, a professor from Berkley, to put together a set of guidelines by which the university could conduct its own community planning and building construction—essentially an architectural version of a brand style guide.

What does all of this have to do with designing for digital? A good deal. For websites and applications today are much closer to buildings, or even cities, than they are to say, posters or brochures. Users don’t stand back separate from the visual space on the page, but move through it mentally, all the while envisioning where they are in relation to other areas of the site.

In one of the books resulting from Alexander’s work, The Oregon Experiment, he writes:

“A master plan is both too precise, and not precise enough. The totality is too precise: the details are not precise enough. It fails because each part hinges on a conception of a ‘totality’, which cannot respond to the inevitable accidents of time and still maintain its order. And it fails because as a result of its rigidity, it cannot afford to guide the details around buildings which really matter; if drawn in detail, the details would be absurdly rigid.”

While there are many ways designing digital experiences parallels designing for physical ones, one of the most obvious is the phase of the project called Information Architecture. In the past—something many people still do during this phase—site architects would create a fully-fleshed out sitemap that lists every page that will be on the future website. With our Berkley friend in mind, the problem with this should be obvious. It is a master plan approach to building a site. Too precise and yet not precise enough.

Like a master plan, a sitemap usually comes early in the project. It is a sort of roadmap. And because of this, it tends to get too precise too soon. Instead of giving the interaction and visual design teams the opportunity to decide what gets its own page and what doesn't, it goes ahead and makes that decision for them, without seeing how it looks and works in context.

In the early days of web design, this wasn’t nearly as much of an issue. Users weren’t really accustomed to scrolling, and all content was pretty much written content. Thus, you could assume most pieces of unique subject matter on a site deserved a unique page. Today, the fold is dead: users scroll. And content can come in a variety of forms like long copy filling an enormous page or a video that takes up little actual space. Maybe these five “pages” should all be on one? Maybe they should be split out? The time to make that call is during sketches and prototyping: not during information architecture.

The second problem is that, later in the project when detail would be appreciated, the sitemap stands mute. It doesn’t tell your team what actions the user should take, what key points should be covered on the page, or what assets they have to work with.

These stumbling blocks in the process have caused us to reconsider the sitemap. Throw it away actually. Unless you’re a client with large swaths of detail pages (e.g. big e-commerce sites), you won’t be getting one. And even then, it won’t be early in the project.

Instead, we’ve opted for a presentation that highlights what our team believes the core content categories should be, what assets we’re working with, and what actions users should take after viewing/using the core content. We’d like to think Alexander and the folks up in Oregon would like this approach. So far, our clients have.