

Introduction
Definition
Architecture
Design
Implementation
Summary
Resources & Credits

Build the Architecture

Your Role

In the Architecture phase, we start to build the structure of the product. We identify the major content areas, then analyze, prioritize, and categorize them. We make decisions about navigation and media types. And we build preliminary prototypes and storyboards. You might be able to get all of this together in one major brainstorming session, but it can easily turn into weeks of information mapping for complex projects.

Organize the
Content

The first thing to do is examine the content. In the Definition phase, you nurtured your idea, wrote your objectives and identified content sources. Now it's time to find those key elements that teach what you want the students to learn. Go through the content and compare it to your objectives. Is all the content relevant? What parts can you leave out? Then start to prioritize what you have left. What are the most important concepts you need to get across? Remember, you're still thinking in general terms here. Specifics come a little later in this phase.

Categorize

Establishing priorities should lead you into categorization. This is more difficult than it sounds because projects with any complexity can be organized in multiple ways and individual items often fit into multiple categories. Some information designers write the main concepts on 3 by 5 cards and ask potential users to group like concepts together in small stacks. Some content naturally fits neatly into categories, other content does not. If yours doesn't, do the best you can at grouping like items together.

Categorization is a precursor to Navigation. If you create a project called The Nutrition of Common Foods, how would you classify cucumbers? Would you call them a fruit, a vegetable, or a melon? You may know that a cucumber is technically a fruit ("Fruit" is often defined as the part of a plant that holds the seeds.), but do your users know that? What about a tomato or a pumpkin? Your classification is going to determine where the user is going to find the information they want.

In the end, you should try to limit the number of categories to between 5 and 7. The human brain can only process so many bits of information at a time. Too many categories will overwhelm your users. Think about how many 7 digit phone numbers you can recall at this moment. They've been broken into a group of 3 and a group of 4 to make it easier for you. What's your social security number? They've grouped it into 3 sections. How about your credit card number? Starts to get harder (unless you've been giving it a workout, recently!).

If you have too many categories, see if you can consolidate any of them or create a meta-category and add subcategories. Once you have a fair idea of how you'll break down the information, move on. Prototypes and storyboards will help you refine the categories later.

Decide on
Media Types

Now that the content is organized, what's the best way to present the concepts? Reading tons of text on the screen isn't very much fun. Is there a large chunk of text that could be better illustrated with a picture, photograph or animation? Can you use audio narration? When you do need text, stick to the key ideas and use some bulleted lists to break up large text blocks. What parts really need video or animation? Is there something that the students need to pick up and view up closely? Maybe 3D or virtual reality would work.

As in other areas, there are always trade-offs. Talk with ITS about which media may be most appropriate for your needs and how long each may take to implement.

Define the
Structure

The structure refers to how your content is organized and how your users might access it. Take a look at the content structure page for common examples. You may combine structures if your content is complex. For example, on a CD-ROM or web site, you can click a category, then a subcategory, then play a video. Flowcharting software, like Inspiration, can be very helpful in building the structure of your program.

Build Navigation

As the architecture starts to take form, think about how the user will navigate through the information. If it is hierarchical, do you let users move between categories freely, or must they come back to a main menu? Do you provide access to all previous levels from the current level? If the structure is more like a spider web with lots of cross connections, will your users lose track of where they are or where they've been?

Good navigation building is tremendously underappreciated. You've probably visited a web site or used a CD-ROM where you just couldn't find anything and nothing was categorized as expected. What did you do? You left or quit or struggled needlessly while cursing the designer. And what happens when you visit a pleasant web site and find exactly what you need? Nothing. You may comment on its usefulness, but you don't think about the navigation. Next time you use a CD-ROM or visit a web site, pay attention to the navigation and content structure. See what works and what doesn't work. How might you have done it?

Users don't notice when navigation is perfect, but will bitterly complain or leave your site if they have any problems. You have to realize that if you don't get any complaints, you've done an excellent job.

Create
Preliminary
Prototypes

It's time to starting thinking about a prototype. A preliminary prototype will help us figure out what we've missed so far. Prototypes at this stage usually consist of paper based sketches or, in some cases, brief computer based presentations. In any event, we aren't worried about what the prototype looks like. There are no fancy graphics and only one screen is drawn for each major area. And if it is computer based, the screens certainly do not function correctly. We are only considering where the content goes and how the navigation works. Once you've ironed out any problems you (or a few of your friends) can find, it's time to show the paper sketches to a few intended users and get their feedback. Do they think the structure of the content makes sense? Does the navigation make sense to them? If not, it's a lot easier to use an eraser now than it is to redo months of production work later.

Create
a Storyboard

The sketches made while creating preliminary prototypes eventually become part of a storyboard. The storyboard is a diary of all the screens in the project. Each storyboard screen shows the placement of all elements on that screen -- text, graphics, video, buttons, etc. It also gives instructions for what should happen when you click the buttons, when the sounds play, and anything else that happens on the screen. Here's a example of a storyboard page.

When storyboarding, realize that screen sizes vary. Most people now assume that the user is using a 800 X 600 resolution monitor at 72 dpi. That's usually the default size of any computer screen when first turned on and is considered by many to be the least common denominator.

When storyboarding a CD-ROM project, take a blank sheet of paper and draw a box that is approximately 11 inches by 8 inches. Place all of your objects (text, graphics, buttons) inside this box. If your project is on the web, draw a box that is 10 inches by 6 inches. Even though you can scroll on the web, put the most important information in a box this size at the top of the screen because that's what people see first. You'd be amazed to hear the statistics on scrolling.

Moving On

Until now, we've been massaging content, building navigational structures and creating storyboards. We have a content map and know which elements should be included on each screen. There's been a lot of research and many decisions have been made. All of this work has been critical to insure that the final two phases move as smoothly as possible. What will the product actually look like? That's determined in the Design phase.