Analytics apps don't tell you much about usage behavior. You might be able to see how many users performed an event, or how many times they did it. But none of the analytics packages out there are good at showing you how often people do things. Are they using to-dos once a week? Every day? Only signing into the app once a month but happily paying for years?
Time matters. You can't understand usage without time.
Here I describe an approach for defining new information architectures for large organizational websites managed by many stakeholder groups.
Broadly speaking, there are four general phases to the approach:
Auditing. Begin by immersing yourself in existing content and encourage stakeholders to adopt a critical, audience-minded perspective of their content.
Diagramming. Work with stakeholders to develop new conceptual categories that better serve audiences and organizational direction.
Elaborating. Think through content in detail and test new categories against specific instances and edge cases.
Producing. Prepare content teams for production using a shared database of new sitemap pages and editorial considerations that you’ve developed incrementally.
Many systems are organized hierarchically. The CERNDOC documentation system is an example, as is the Unix file system, and the VMS/HELP system. A tree has the practical advantage of giving every node a unique name. However, it does not allow the system to model the real world. For example, in a hierarchical HELP system such as VMS/HELP, one often gets to a lead on a tree such as:
HELP COMPILER SOURCE_FORMAT PRAGMAS DEFAULTS
only to find a reference to another leaf: Please see
HELP COMPILER COMMAND OPTIONS DEFAULTS PRAGMAS
and it is necessary to leave the system and re-enter it. What was needed was a link from one node to another, because in this case the information was not naturally organized into a tree.