Information architecture (IA) means so much to our projects, from setting requirements to establishing the baseline layout for our design and development teams. But what does it mean to your clients? Do they see the value in IA? What happens when they change their minds? Can IA help manage the change control process? More than ever, we must ensure that our clients find value in and embrace IA—and it’s is our job to educate them.
If we want our customers to embrace IA, we must help them understand why we need it. IA is about selling ideas effectively, designing with accuracy, and working with complex interactivity to guide different personas (potential customers) through website experiences.
The following talking points may help your clients understand the value of IA.
IA incorporates requirements, goals, and user paths
Explaining the purpose of IA to the client should be easy once you discover a project’s purpose. Is it to increase awareness of a product or service? Is it to make the purchase path easier? IA incorporates these requirements and marketing goals and outlines traffic patterns so that the website can become a successful extension of a product or service.
I often tell clients that IA establishes the baseline, or foundation, for a solid site structure. It helps create the traffic patterns and navigational routes that get the customer from A to B in language that is helpful and easy to understand. In fact, IA is the first step in meeting customer goals and can therefore increase brand awareness and product or service sales.
IA mitigates scope creep
Since requirement gathering usually takes place at the same time as IA, IA can serve as a guide, keeping the project on track. IA ensures that project requirements are met since it establishes functionality, customer flows, and design.
With a solid IA, the customer’s project gets delivered on time and on budget. Changing requirements means changing IA, and that means the entire downstream process will need to be adjusted.
IA validates the site’s purpose and goals
When working with your client to gather requirements, there are ways to validate whether or not you’re on the right track. Take those moments to step back and explain to the client what you’re doing and/or thinking, and validate current and future work. Once your IA is defined and agreed on, help clients understand that redesigning or adding development time after this point compromises schedule and adds cost.
If the client asks for changes to the IA, cost out the hours, resources and overall effort. Supply a cost analysis or a quote for the additional work so that they understand the consequence of changing direction.
Well-executed IA can be used to defuse any future questions in both design and development. Barring any large changes in scope, the IA will document and protect the project, so long as you educate the client along the way.
Defining IA’s deliverables for the client
All project members should have input into the architecture. That seems pretty simple, but as the project moves from phase to phase, from iteration to iteration, keeping the deliverables tight becomes more difficult. Since this can be applied to any type of website, we’ll keep things generic and worry about the deliverables.
Phase one: discovery and initial approval
Not all deliverables listed here need to be part of your project, but the team should understand the associated expectations as they work through the design process from concept to production.
|Deliverable||Phase One Expectations||Audience Notes|
|Deliverable||Phase 1 Expectations||Audience Notes|
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.
Use Case / Requirements Document
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.
Phase two: design and development
As the team moves from concept to development, deliverables get updated and are worked into the project flow. Expectations for each deliverable will change and should be communicated to the team as either an edit or an official change, depending on the level of complexity. Here’s how expectations change for deliverables during design and development:
|Deliverable||Phase Two Expectations|
|Deliverable||Phase 2 Expectations|
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.
Use Case / Requirements Document
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.
Can you spare some change?
The change control process makes or breaks your profit on a project. In some cases, change control can be tricky for you and your client. After all, your client expects you to complete the work they give you, even if it isn’t part of the initial set of requirements. The change control process protects the project, your costs, and the client’s best interests.
The following table outlines the process and some decisions on how to effectively use a standard change control process:
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.
Use Case / Requirements Document
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.
Websites are flexible and every deliverable must be able to grow (or shrink) with the site. Changes can come from outside forces as well, including focus group data, usability testing, and even server architecture or hosting changes.
Transparency—educating the client on standard processes and deliverables—is tantamount to the success of a project. By using these standards, IA can more easily help manage both the decision-making process and the overall cost. The team lead must take on the responsibility of training the client for the designers and developers to produce accurate work.
Proper IA, when done with an informed client, becomes the flexible fuel that drives the user experience.