I’m just starting a new website project at work, and one of the first things I’m attacking is the information architecture. I’ve learned the hard way that having a solid site architecture can save boatloads of redesign pain later on.
My method is to plan it out and it goes roughly like this:
- Learn everything I can about the topic(s) to be presented – past history, present situation, and future plans
- Discover who all the stakeholders are
- Perform an existing site content type and page audit
- Build a site map of the current site
- Wallow deeply in site metrics for top pages, visitor trends, referrers, search terms, and page flows
- Wallow deeply in customer data around segmentation, intent drivers, and key tasks
- Look for stuff that can be dumped overboard
- Figure out what will need to be added in the future
- Whiteboard out all the elements (content, information flows, external process connections, customer segments, etc.)
- Stare at whiteboard for hours, then erase and draw, erase and draw until a model and page pattern(s) appear
- Wireframe a few pages with the designers to get a feel if the model works across architectural segments
- Go back to whiteboard and fix the broken stuff
- Wireframe again
- Look for more stuff that can be dumped overboard
- Build high-fidelity comps, preferably on the deployment platform
- Lock it for usability/review
- Tweak after usability/review (if needed)
- Hand off to production when it’s complete
Easy, eh? 😉
Heather Kilbourn 