Information architecture
Any system created to fulfill a goal needs a structure. Without it the thing you create won't feel like a unified whole - it'll be a mishmash
of disconnected globs. The defined structure of any data-driven campaign or programme is its information architecture.
The information architecture of a textbook is one page long: the table
of contents. The architecture of a dictionary is just three words: 'A to Z'.
The architecture of the human body, by contrast, takes up 3GB: three billion
DNA base pairs describing how 30,000 different proteins develop in sequence.
And the architecture of a big website or application can reach thousands of
crosslinked pages of information. To get it right, you need to look at three
areas: organising structure, interaction modelling,
and navigation design.
The organising structure is driven by user needs,
not your needs. (If your site map looks like your org chart, it's wrong.)
Those needs will give rise to a finite number of information types, which
you can organise into page types or database tables. Grouping and ordering
each page type, or joining database tables with strict many-to-one or one-to-many
relations, gives you the structure of your website or marketing application.
In contrast to the networked web, relationships between pages or information
tend to be hierarchical. (And often wall-sized, sketched on huge charts of
stuck-together A3 with ten colours of marker. It is definitely one of the
fun parts.)
Interaction modelling maps out a user's travels among the data: how he moves from page to page or consumes items of information in sequence or parallel. Flowcharts are useful; interaction modelling takes place over time; they're the pathways through the site different customers might take.
The navigation design defines the choices the user has for getting around your site or application: the links. Not all links are created equal. Links to top-of-section pages (primary navigation) differ from links between pages of the same type, as do links leading backwards and forward (breadcrumb trails) or links to other sites. Links should be organised to make sense horizontally (across the sweep of subject areas, or 'main nav') and vertically (the list of sublinks within each area, or 'subnav'). All ranked by level of importance to the user. Of course, contact information ranks top.
(With today's database-driven web apps, sets of links aren't static: the subset on each page type changes according to what else is on the page. That's why navigation design is about more than sketching the lines between boxes. But it's fun, too.)
And that's information architecture. Not graphic design or copywriting; site design, not page design. When you've decided what your users need, IA is the framework for delivering it to them. Next: content strategy.