$(function() { $('a[href*=#]:not([href=#])').click(function() { if (location.pathname.replace(/^\//,'') == this.pathname.replace(/^\//,'') && location.hostname == this.hostname) { var target = $(this.hash); target = target.length ? target : $('[name=' + this.hash.slice(1) +']'); if (target.length) { $('html,body').animate({ scrollTop: target.offset().top }, 2000); return false; } } }); });

Diagram

We put an initial shape to the project, visually outlining its top-level organization.

Main Deliverable

Site Map

Other Deliverables

Features Roadmap, Use Cases, Taxonomies, Content Audit

Content precedes design. Design in the absence of content is not design, it’s decoration.
— Jeffrey Zeldman

With a firm conceptual grasp on the project, we can start outlining a top-level structure. We want to collective nail down the scope – exactly what functions, pages, and sections are being built. 

We also want to jumpstart any work that can be run in parallel. High-level development systems can be put in place, content might need to be written, advertising campaigns outlined, and so on. Laying out a schematic outline for the product can give each of these roles what they need to support the overall effort.

Since we’re putting initial shape to what was previously just words and ideas, these deliverables are diagrammatic. We’re using them to  answer questions like:

  • How many screens are there?
  • How many templates are there?
  • What sections are there?
  • What are the most important goals for the user?

 

You might see a similar phase referenced elsewhere as Information Architecture.

The house metaphor

Carrying our construction analog forward, we can imagine that now we’ve agreed on the vision of the project in the previous phase (e.g. “This is a substantial addition to make our kitchen area more functional for our growing family.”)

In this Diagram phase, we’d nail down the parameters and limitations of the project. We’d do site surveys, check visibility lines, understand lighting and other environmental factors, research materials, get our permits lined up. In short, we’d get the project ready for the next phase, in which we’d start blueprinting.

Main deliverable
Site Map

A sitemap is a hierarchical diagram of the pages (or views) in a product.

This is often where we'll first decide what the main groupings will be for the site. These buckets usually become primary (and secondary) navigation.

We’ll also often layer other information into a site map, including template identification, very high-level requirements per page/template, or even a very rough sketch of the main pages.

This informs – and is informed by – the content production, development architecture, and page-level sketches and designs.

Other deliverables

Features Roadmap

It's easy to lose focus when we're excited about building out a product. When we lose focus and change directions, we lose efficiency, and the product loses cohesiveness.

A roadmap is a strategic communication document that shows your team and other stakeholders what high-level initiatives will get us to your product vision. It helps keep the team focused on what we’re working on now, knowing that other much-loved features will get their due attention. It makes product decisions much faster and easier; we know we can "park" great ideas that might derail us (and which we're not ready for yet) in the plan. It helps our messaging plans so that we can communicate with users to prepare them for new features.

It's important to keep the roadmap at a high level. We don't show every detail of the development plan (and certainly doesn't include specific bugs or minor features). Often it doesn't even include dates.

Instead, the roadmap is focused on sequence. It's vital to wisely order feature launches so that those which build on earlier features are launched in the right order, optimizing efficiency and success.

Use Cases

For important or complicated interactions (e.g. checkout, find a location, etc.), a use case goes into more detail than a site map. It follows a user and the system through a flow, detailing the user actions and system responses at each step, along with any alternate routes.

This helps us make sure we’re not missing any key details as we address these important pieces of the product.

Taxonomies

A taxonomy details how we will categorize structured content.

Often, the site map will suffice for this purpose. But some projects – for example, a news site with a variety of topics, or an ecommerce site with an array of products – call for a focused effort on the categorization.

There are often lots of ways we could group content into categories. Sometimes the categories are based on users’ goals, a typical buying journey, or some kind of inherent structure.

Content Audit

A content audit is an exhaustive collection of all your of current product’s content.

This is particularly useful as a tool for content creation for the revised product. Mapped against some of the Dive work that shows what is and isn’t working, areas can be highlighted for rewriting (or identified as opportunities to go with what you’ve got).

It also provides a sense of the scale of the copywriting effort. Sometimes a Content Audit will highlight an otherwise low-importance section of the product that has a glut of content, or the opposite.

For each item, a content audit includes things like:

  • A unique identifier
  • URL
  • Page name
  • Page type (e.g. home, product detail)
  • Position in hierarchy
  • Mapping to strategy findings (e.g. steps in the customer journey)
  • Quality
  • Rewrite flag
  • Comments