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
1 - Diagrams
- use case
- site map
- use case scenarios
- data and search dictionaries
- general design notes
- technical specifications
- data entities
- wikis or other intranet sites
- stakeholder interviews
- page layouts
- graphic mockups
- navigation maps
- photographic and other images
- 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
- a news or new features page
- rotating images
- customer feedback in a forum
- 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.
Essential areas to understand are:
- business objectives and constraints
- site content
- visitor requirements
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.