As many people may have read before, 37 Signals’ Jason Fried has been doing a lot of hollering about his ‘getting to real’ methodology. Scoffing at the use of typical functional specifications, he advocates that building the interface first is the best way to come to an agreement with your client about what the software will do and features it will contain.
This is great for web applications, but how does this relate to informational sites? Or does it?
For a few recent projects I have been experimenting with a concept that I thought worthy to share. I have recently been using HTML prototypes as a means of discovering Information Architecture. In much the same way that ‘getting to real’ helps to define and innovate the interaction design, it can also help create unique and useful architectures as well.
Death to the site map, long live the site map
For quite a while site maps have proven indispensable in communicating to clients the size and scope of a site. They are also built with the visitors in mind, with the top-level pages matching the mental model of the different user segments. While site maps are effective for this purpose, how is it you can put these ideas to the test while changes are still relatively cheap to make?
Creating site maps, much like a functional specification, is done in ‘I think this will work’ world. This means that there’s no physical product yet that matches your architecture idea. There’s no way to really test it and experience it like a visitor does.
Iterating between fantasy and reality
By creating an early mockup of the site in HTML, you can test and experiment with the architecture first-hand. I’ve used these mock-ups very iteratively which meant working a little in the site-map world, then building it and testing it out. If the content is still in development (which should be iterative as well) Then I start to fill it in and see how the pages act. Is the page too long? Do two pages seem to relate but are not linked together? Using the navigation and reading each page puts you in the seat of the visitor, and the same question, or problems the visitor has, you will have as well.
What the prototype has:
- All the global / top level navigation
- All the content developed up that point, placed in semantic markup
- Basic typographic styles to give a realistic reading experience
- In-text links and other content links to related pages
- Placeholders for known imagery such as an illustration or complimentary photos. Only items that could be considered content by themselves.
What it doesn’t have:
- Any graphical treatment or colors
- Any complex layouts. Only what’s necessary to show relationship such as side-by-side equality, or indents for hierarchy.
- Any actual photos or other images, even if they are known and exist.
The perspective
Some of these things may seem beyond what a standard IA may do, well your right. Keep in mind, I really don’t work on large enterprise level sites consisting of thousands of pages. Most of my work is in small teams, and working closely with the client, and on sites that are having content rewritten or created for the first time. In these situations this ‘try it first’ process has been indispensable in not only communicating with the client, but creating more effective site architectures. Give it a shot on your next project.
Published on March 19, 2005
Resides in Information Architecture
Comments feed | TrackBack URI
2 Responses to “Getting Real with IA”
1
Nemrut on December 29th, 2005
This can be good way to iterate in small,informal teams but tends to break down for larger projects with multiple stake holders.
In the latter, it is often more efficient to seperate the content/funtionality/presentation layers in parallel or sequential paths.
Nemrut
2
billg on January 4th, 2006
“…building the interface first is the best way to come to an agreement with your client about what the software will do and features it will contain.”
Having spent several years at the taxpayers’ expense as the government point guy with both the internal client and the contractor building the site, I can second that. People need a frame of reference. Specs don’t provide that for them. Looking at the site, even a mockup, does.
If you just show them the specs, invariably they’ll wander off trying to translate what they’ve, probably, poorly understood into a visual image of the site. Equally invariably, they’ll get it wrong. That means the customer thinks you’re building a different site than you actually are building. That way lies unhappiness.
Show them the interface, often and early.