Educating the Client on IA – A List Apart

A high-level content assessment. These larger, more loosely-defined chunks help the team understand the scope of the entire project. The content survey should be delivered to the team as soon as it’s approved.

Every project member should have interest in this document, but the client project team should have the majority of the input.

The content map is a box-and-arrow graphical representation of content by section. It should eventually transition to the site and navigation maps. As pieces are moved between sections or areas of the site or application, the content map helps manage the traffic and controls content edits. The design and development team should receive an early iteration of this to understand which sections intersect.

Client subject matter experts (SMEs) and the designers should be well aware of this direction.

Walk through this document with the user interface (UI) developers once this is set in stone.

A detailed audit lists pages of content with unique identifiers. These identifiers are then used on the site maps and user flows where space is tight. These unique identifiers are especially helpful for new content.

The client SMEs, the developers, and the quality assurance (QA) team should have copies of this once it is approved to use as a guide for the project.

In the early stages, the site map needs to, at a basic level, reflect the combination of information and functionality to be accessed by the user. The site map is not, in my opinion, a navigation tool. Using unique identifiers from either the detailed audit or established in the site map itself, the flow of the user experience should be detailed as if the user is interacting with it. The site map, of course, is a critical deliverable in the early stages of design and should be signed off by the client before design enters the post-concept stage.

All project team members should use this as a baseline guide.

At the onset, a navigation schema will be hard to define without help from the client’s SMEs. Defining taxonomy and the navigation between interactive elements can be one of the longest tasks on a complex project. Not only are you dealing with the constraint of real estate, but you are also dealing with multiple-language factors, marketing preferences and the initial user experience. Get as much as possible set in stone at a high level before you begin design.

The entire team will benefit from this deliverable. The main audience for this is the client’s SMEs and the design and development teams.

Early persona definitions should be available from the client product or project team. These personas can be enhanced to meet the demands of the online environment. Persona enhancement depends on how many personas there are and any common elements that may be reused. The usability and design teams should be part of this task. Client SMEs and the marketing groups must provide input.

Once definitions are in place, the design and usability teams will need to use them as they do their tasks.

Typically the responsibility of the business analyst or client SME, the use case or requirements document must define tasks to be performed. Most times, a set of use cases needs to be submitted to help define user flow. For example, Use Case 1: Log in, Use Case 2: Forgot Password, etc. Without detailed requirements, it is incredibly difficult to scope, design, and develop a website. At the very least, a list of use cases should be presented to the team at the same time as the site map. This helps everyone see the correlation between form and function.

The business analysts, project managers, client’s SMEs, and IA team members need this documentation to do their jobs. The project manager or the business analyst should update this during the project.

Another “gold standard,” the wireframe must be complete before post-concept design can begin. In many cases, internationalization and multiple-language points must be addressed, as well as basic layout guidelines for the breadth (or lack) of content. Don’t allow the client to dictate the design unless you’re incorporating the work into an existing website. Always work with the usability specialist and designer before you hand off the wireframe for approval. This is one of the most critical project deliverables. It’s something that everyone on your internal team should see before you seek approval.

This set of deliverables is for all project team members. Along with the site map and requirements, wireframes will guide the team as they complete their tasks.

The content survey should not be updated. It should be placed in the project repository as a completed asset.

The content map is a living document. During design and development, the content map helps identify scope creep. New requirements should be added and communicated as quickly as possible.

If a detailed audit was completed, the document should note delivered content and content edits. If new content is added and the project can withstand it, update the detailed audit at the same time as the site map.

At this point, the site map should be updated with new drive-down flows and any additional supporting information on how pages or functions interact. The site map is a living document and must be updated when content or functionality is either completed or changed.

In phase one you defined the basic navigation schema, taxonomy, and user flow. In phase two, changes should come from either usability testing or from direct user feedback. Change decisions must consider layout, design, and functional elements.

Persona definitions should not change after phase one. Designers and usability specialists often refer to persona definitions to make sure that the user’s needs are met.

In phase two, use case lists and high-level user flows must be expanded and the true functionality defined. In the “Log In” use case, the expanded definition will include the ways in which users will log in, both technically and in visual design terms.

In phase two, wireframes are added to complete the design process and assist production. If a major change is introduced during phase two, produce a new template and get it approved. All new wireframe tasks must stem from the template. Changing legacy wireframe documents once they’ve hit production can be a fruitless and costly exercise.

Sign-off occurs when your client has given you all the content to be used on the site or application.

Initially, minor adjustments mean minor influence on the project. Once this is signed-off, any large edits will affect the entire IA process.

Complete an initial sign-off as soon as the main requirements are set.

Changes to the content map mean changes to the requirements. Be aware of this and you’ll have the documentation you need to manage project changes.

Sign-off the detailed audit as soon as you are ready to start documenting requirements.

Most projects will not have a detailed audit. If one is created and updated, use other deliverables, such as the content map and site map to manage change.

The site map requires sign-off any time a change is made (past the initial review). The site map can drive the entire process.

Site map change is huge. It’s critical to keep the site map up to date and call out any major changes. It will directly influence the design and development phases.

Sign-off the navigation schema as soon as the team agrees on the site map and taxonomy.

As you move into the navigation and user flows of the project, you’ll need the navigation schema to dictate the influence on other phases. Late-phase edits to this deliverable can be costly because they mean changes in the entire development cycle.

The sign-off for these should happen before you begin design. As personas are created, vet them against the navigation schema.

Different folks will take different paths. Be aware of who the audience is and what they need to manage any changes.

The sign-off for this documentation is paramount to your project. Whether you receive completed requirements from the client or are helping to create them, you must get sign-off before you begin the design process.

Any edits to the requirements should be taken into consideration for scope creep. Changes to the requirements influence the entire project.

Complete sign-off for certain pages (home, drill-down, specific functionality) before you start to design.

Before changing the wireframes, make sure the changes are either template level or page level. Page-level changes can be conveyed in the design, but template-level changes should be completed and signed off.