Olde Schoole:  This list shows the ‘collateral flow’ over the course of a project.


In earlier times I was both a documentation manager and an information architect:

On the one hand, I know that:

“Process can be described as ‘a series of documents’.

But, I am also     well aware that:

“Nobody ever reads the documentation.”

Sooooo …. Here’s my take on it.  This is a progression – more or less in order

Put it in Writing

Putting it in Writing” gives your team :

  1. a common ground for understanding
  2. a level playing field for assumptions
  3. a point of reference for tracking changes

Content Inventory

It’s basic Discovery: A comprehensive listing of What Is There. It’s one of the fundamental pieces of the design infrastructure. 

  • Content – What’s There

from:  Legacy site

to:  Site Evaluation

Site Evaluation

This high-level analysis is pretty effective at identifying the low-hanging fruit of legacy problems. 

  • Rating – What’s Good, Bad, Missing

from:   Legacy site

to:  Design Specifications

Product Snapshot

This is an overview and intro document. This initial “framing” of the product is the first piece of collateral created for use by the product team. 

  •  Context – Framing, scope

from: Client info

to:  Business Requirements

Actors & their Roles / Personas

  • Who’s Who – Customer-centricity

from:  Client info

to:  Personas, Permissions


The Workflow provides a shared context for usage perspectives and interaction; not only for the customer, but also system administrators, and the business). 

  • Usage – Step-by-step

from : Actors & Roles, Legacy system/Site

to : Design Specifications

Business Requirements

Every design project encompasses several Tasks, their related Use Cases and the many Business Rules that define them.  

  • Rules – Functionality

from : Legacy site, Client info

to : Use Cases, Business Rules

Technical Specifications

The TechSpecs are rarely at issue in ‘design-oriented’ discussions, yet they determine a lot of what can, can’t, and must be done. They often define much of the operational parameters.

  • Constraints –  Usually Defined by tech team

from : Platform, Performance

to: the functional environment

Design Specifications

The Design Specifications establish how we organize and present the User Interface, Interaction and Workflow.  

  • Vision – Presentation


Hi-level or detailed, this gives a quick visual overview of the organizational – and functional – structure of the site. It’s often visualized up front as a guide and intro for team members and stakeholders.

Information Architecture

The “information architecture” infrastructure is how we establish a common interface to data entities that are shared across multiple applications within the enterprise.

Structure – the Infrastructure of Meaning

from : Content Inventory, taxonomy

to: Tagging, Content Management, Glossary

CSS Guidelines

CSS Tags are the common design elements which are shared across multiple applications within the site. Along with the layout templates, they define the essential design infrastructure of the site.

  • Expression – of Design and Meaning

from: Information Architecture, Semantic Structure

to: Styling Guidelines


A working Model

  • Implementation
  • Design Specifications


Show how it works

Branding & Icons

Visual shorthand & clues

  • Information Architecture
  • Design Specifications
  • DemoSite

Best Practices


  • Design Ground Rules
  • Industry standards
  • Enterprise criteria
  • Design Specifications
  • Demosite

User Assistance

Self Help

  • Feedback
  • Workflow
  • Business Rules
  • Glossary


Explain it


This article still in progress…


© The Communication Studio LLC