Wednesday, August 26, 2009

Information Architecture, part 4

Artifacts and Processes.

-- Artifacts --

Several kinds of artifacts show up during the development process.
Input Artifacts are:
  • mission statements
  • organization charts
  • records from previous projects
  • vision documents
  • analysis of the competition
  • documented business models
  • documented visitor personas
Output Artifacts are diagrams, documents, and different prototypes.
1 - Diagrams
  • use case
  • navigation
  • interaction
  • sequence
  • site map
2 - Documents
  • use case scenarios
  • data and search dictionaries
  • general design notes
  • technical specifications
  • data entities
  • processes
  • wikis or other intranet sites
  • stakeholder interviews
3 - Prototypes
  • page layouts
  • wireframes
  • graphic mockups
  • navigation maps
Input/Output Artifacts. Several types of items may both go into the process and also emerge from it. They might be modified along the way as well. Some are:
  • photographic and other images
  • data
  • logos
  • business color schemes
  • sound and audio files
  • marketing documents
  • technical and help documents
-- Processes --

There are many processes involved in information architecture. Just because there are many doesn't mean that anyone has to get hogtied by details. Processes exist not to stymie you but to help. Use the processes that are appropriate, and only as much of them as you need. But do plan on being thorough. These were developed to help, and they will. But only if they are used, and used well.

1 - A process to define functional requirements.

Defining functional requirements determines what content your site needs and how to access it. Content can be static, dynamic, or transactional. 1 - Static content
  • copyright notices
  • privacy statements
  • other boilerplate
2 - Dynamic content is anything that changes frequently, like
  • a news or new features page
  • rotating images
  • customer feedback in a forum
3 - Transactions
  • logon pages
  • signup pages (for newsletters or other services, including shopping pages)

2 - A process to define a site structure.

Do this by keeping your site's purpose in mind. Brainstorm. Gather people and generate ideas, then review and evaluate. Don't discourage anything while brainstorming. Anything. Instead get all ideas out in the open and filter them later. It's easy to kill a good idea but hard to find one.

Get the basic items knocked out, then repeat. Keep repeating and refining until done.

3 - A process to develop an architectural blueprint.

Developing your site's structure results in an architectural blueprint. This blueprint helps everything else to fall into place and makes it easy to define navigation.

Structural and navigation plans together make page layout and template design easier. One mistake that many companies are tempted to make is to copy the company's org chart as a design, but this is not good site design. Customers don't care about corporate structure. In fact, a customer could care less who reports to whom, or how the business units are managed. If they did, you would know about it. Customers have their own needs, which are not reflected in the way the business is organized.

Start with a general overview and then get into the details.

Describe the larger sections of your site and and the groups of pages that define them. Then move to individual pages, and then to the elements that comprise them.

Define the links that connect the parts of your site to each other, and the links that lead off site.

Document everything. Keep the overall goals front and center.

4 - A process to integrate metaphors.

Fold in metaphors. There are two kinds.
  • Functional metaphors relate tasks on a site to other common tasks that may exist in other environments. Think of "cut," "copy," and "paste". Those are functional metaphors. You know them. They can apply to many different things in many different environments. Similarly, you can use other metaphors to design, create, and maintain your site.
  • Visual metaphors are graphic elements that are common and familiar. Think of "start," "stop," and "pause" icons on an audio player or video player. Use similar ideas for your site.

5 - A process to develop the visuals.

You have to create a visual design. Visual design creates a unique sense of place. It defines landmarks.

A visitor creates a mental map of your site while exploring the sites visual design and structure. Graphic designers, art directors, creative directors, and developers collaborate to create this.

Design sketches establish a look and feel. They are often done concurrently with other parts of the development process.

One way to overlay a site's structure onto a visual design is by using a grid pattern. This is a well known technique in graphic design, and ensures that elements are consistently aligned. While doing this, define the site's structure and organization all the way down to the page level.

You can use sketches to establish a general look and feel, and then move into page mockups by combining the sketches with grids, finally using the page mockups as prototypes for the finished pages.

Grids are really handy for defining overall layout, and help to block out global and local navigation as well.

To use grids, first create a rectangle representing a page, then block out the major design elements on that page (content, branding, advertising and sponsorship, navigation, page titles, header graphics, footers). Then refine. Iterate as often as needed.

6 - A process to create mockup.

Page mockups represent your site at a nearly finished stage. Integrate design sketches with layout grids to produce the mockups.

Mockups come in when the development team is almost ready to start programming and they establish the basis for more refined prototypes (or the basis for building the actual site, if it isn't too big).

Keep the design documents up to date. The design document's visual design section records what layout grids were selected and why. It includes diagrams and illustrations of page mock-ups. You can think of these as static prototypes.

7 - A process to enhance understanding.

Understand everything.

Essential areas to understand are:
  • business objectives and constraints
  • site content
  • visitor requirements
To understand business issues, study existing documentation, previous research, previous projects, and vision documents. Don't' forget to include mission statements and organization charts.

Remember to interview stakeholders for insight into the business context, and keep digging to uncover issues that might not be obvious to everyone.

Create inventories of content to hone your understanding of what the content is. Content inventories are collections of both content and potential content. It's important to identify it, to know where it is and who owns it, to be aware of the relationships between pieces of content, and how those pieces relate to the project.

8 - A process to define Goals.

Clearly define your site's goals. This ensures that everyone on the team moves in the right direction. Keep basic questions in mind:
  • the purpose of the organization
  • its short term and long term goals
  • the short term and long term goals of the site
  • the site's intended audience
  • what the site's draw is supposed to be

Then rank the goals, document them, and publish them for all team members to see.

9 - A process to understand visitors.

Don't forget to understand your visitors. They are what your web site is all about. To understand visitors you first have to define who you think your site's audience might be. Ask questions like who will be using the site and why. Use narratives and scenarios to visualize your proposed visitors and what they might do at your site. Then rank potential audiences by importance (and plan to deal with the most important ones first).

Use your scenarios. Visualize the site's operation, and its users. Using scenarios is a great way to validate the design. To create scenarios, interview typical visitors, concentrating on those who represent the most valuable audience. At the end of development, your actual site should match the scenarios.

10 - A process to evaluate the competition.

Dissect your competition through competitor analysis. How? Study the strengths and weaknesses of actual and potential competition and evaluate your site in that light. Then create a list of ways to better what your competition is doing. Download time, page size, attractiveness of layout, usability, and look and feel are all important, as well as specific products or services. If you have an existing site, then evaluate that too. Publish the results for everyone on the team to see.

11 - A process to tidy up loose ends.

Identify content and functional requirements. If you know the content then you know what your site will contain. If you know the functional requirements then you know what it has to do.

After listing the content and functional requirements, have the development team reach a consensus about them.

Create an inventory of content. Content types (as noted earlier) can be static, dynamic, functional, or transactional. Roll individual lists of content types from various team members into a master list, which will be your "content inventory."

Review the requirements. Determine the feasibility of each functional requirement. Ask if the technology and skills to meet them are available. How about the time and money to buy or build the needed functionality?

Rank your requirements. You can't fulfill all of them, at least not at first. Concentrate on the most ones important first, even if they're the hardest. Putting off the hard things until last ensures failure.


Wednesday, August 12, 2009

Information Architecture, part 3

Roles in information architecture.

Information architecture needs people filling many roles. On a small project one person may take on several, or all of the following.

Information architect.

This person defines your site's structure, its content, and its functions. The architect does this with an eye to both business and visitor needs. But information architecture is an art. It's abstract. It is hard to communicate sometimes. Because of this the architect has to work well with others, and has to be good at communicating complex ideas.

Every information architect should be a generalist, but especially needs decent skills in visualizing, defining, and organizing information.

The architect needs to think like an outsider (remaining sensitive to visitor needs) while being an insider (who understands the business and its mission).

The architect needs to have empathy, and should be a quick study.

Creating a site that mirrors a product brochure is a mistake. Creating a site that mirrors an annual report is a mistake. A decent information architect can help avoid mistakes.

Remember that the average new visitor gives a web site only four seconds. Four seconds to get the message across. Four seconds to tell a compelling story. And then that person can simply click away, never to return.

So the information architect has a role to play. A crucial one, in making sure that each web site can entice, hold, entertain, inform, and repay visitors for time spent at a web site.

User interface designer.

Works to make a user's interaction with a site as efficient and pleasant as possible. Good interface design helps usability without drawing attention to itself. It is often overlooked or assigned to someone as a second role, but user interface design is critical, and should not be handed off to someone as an afterthought. Especially not to a programmer.

Usability engineer.

Is an expert at testing and evaluating systems. Concentrates on measuring system performance from a human angle.

Marketing experts.

Understand target audiences and how to communicate with them. Marketing expertise ensures that the business message is presented properly and not buried in jargon, or lost.

One drawback: marketers are geared toward selling, but helping users is extremely important too, sale or no. Make a good impression, provide some value at no charge, and you may have a customer. Word of mouth can make or break a business, and rarely shows up on sales reports.


Programmers, database designers, operating system and network specialists and others have the technical skills for modeling content and creating working databases and web pages. They usually are not trained in user-centered approaches to designing information systems. And even if they are, they don't have the time to do it justice, except on very small projects. These folks deal in nuts and bolts. Important things. Very important things, but done behind the scenes.

Graphic designer.

This is a person who oversees the layout of site-wide visual elements and creates a site's overall visual identity.

Graphic artist.

Creates specific images, logos, and pieces of artwork that contribute to the larger visual design.

Copy writer.

Copy writers focus on language. They write, proofread, edit copy, and massage content so a site has a consistent voice.

Project manager.

This is the person who keeps things on schedule and within budget. This person is a facilitator and a communicator, not a dictator. The project manager is a negotiator among team members and stakeholders, a go-between, and must be dedicated to maintaining a comfortable and productive working environment.

The project manager's job is to juggle the needs of staff, the needs of the schedule, and the tasks to be done. The project manager's job is not to give orders but to take them, to ensure that everyone can work at full potential.

And finally...

Back to the information architect for a moment. This person needs to know at least a little about each one of the other specialties as well. The architect's work affects each part of the process, and all team members. The architect is the keeper of the big picture, but has to stay flexible enough (and creative enough) to come up with new ideas on the fly, as required.

Wednesday, August 05, 2009

Information Architecture, part 2

The consumer perspective.

There is a consumer or site visitor perspective. It has two aspects, reflecting who comes to the site.
  • Targeted searchers. These people know exactly what they want. They know that what they want exists and they know what it's called. They want to find it, take care of business, and then leave. As painlessly as possible.
  • Casual browsers. These are people who don't know exactly what they're after. They come by with a vague idea, or maybe by accident. They explore. They bump into things, and learn about products or services that maybe they'd never even heard of before. Do your site right and they'll come back again.
Many users switch between targeted searching and casual browsing. A good architecture supports both.

Great graphics and reliable technology contribute to making happy visitors, but they aren't enough by themselves. Any site must actually deliver value.

The producer perspective.

This is the business view. And as you would expect it is a little different from the consumer perspective.

A well-designed architecture, one that scales, can prevent an expensive and early do-over. It does this because it keeps the big picture front and center. This is important for a business.

Too many site builders dive in head first without planning. You can get a site that is a confusing jumble of options, a site that tries to serve several different audiences while failing at everything. These things happen when you lose perspective, or never have it to start with.

Committees in large organizations with conflicted goals and messy politics can design sites that look the part. Competing visions and uncertain deadlines prevent issues from getting resolved. Sites built this way can't work well, even after huge amounts of time and money. Adding more people to a project only makes it slower and more likely to fail.

Problems in information architecture don't go away. No problem does. Resolve problems before a site goes live or those problems will get dumped onto the internet. Onto your site's visitors.

A frustrated customer will leave after a bad experience. A potential customer will never become a real one.

And another thing.

Without a clear information architecture as a guide the site's maintainers won't know which end should be up. They won't know where to put new features or how to update the existing ones.

Instead they will try their best but can end up adding to the mess. No matter how good they are and how hard they try there is no substitute for getting it right the first time.