You may have already been bombarded with the idea of information architecture. Information architecture is the method by which sought data is represented and structured. Good information architecture is usually equivalent to intuitive user interface design — visitors to a well-organized Web site won't spend much time searching for what they want. More recently, the term "user experience design" is also bandied about, to refer to intuitive and user-centric interface design, organizing menus, buttons, navigation controls, and so on around the practical use of a product.

We mention information architecture because the steps in Phase I are similar to the steps that traditional architects take to build a comprehensive design and production strategy before they start to build any structure. Although this may seem obvious enough, the sad fact remains that many Internet sites (or projects) are planned as they're constructed. Indeed, we're told that production must move at Internet speed; thus, directives may be given without thorough research into other solutions for a given problem.

As the authors of this book mention earlier in this chapter, the first step in developing a Flash site, or any other type of site, is to define the information architecture. In this tutorial, I'll show you how to define the goals and mission of the site.

Defining the goals and mission of the site

When you define the mission and goals for your project, you lay the foundation upon which to build it. To create a solid project foundation, you must begin by questioning everything, especially the company's business model. Start with these questions:

The list of questions can go on forever. After you've gathered a list of questions, you need to get the answers. Ask around the organization, ask your friends, ask strangers, ask anyone. After you've collected the answers, filter through them to create a list of goals based on the responses. From this list of goals, you must further define the answer to the question, "Who is the audience?"

Defining the audience

The audience can be defined as the potential users of the site and their intentions or tasks when they come to your site. Are they kids or adults? Are they Generation X, Y, or Z? Are they into rave music or country music?

So, who is your audience? It's not an easy question because there are so many possibilities. Start with a list of all the possible audiences that the organization would like to reach, and then rearrange the list in a ranking order of most important audience to least important audience. From the audience-ranking list, create a list of the possible goals and needs each audience has.

Creating character scenarios

With the list of possible goals, take the process one step further by creating scenarios for the users. Think of it as writing a screenplay for your Web site. Create multiple characters who represent the majority of the visitors, giving them hobbies, likes, dislikes, and, most important, a task to complete on the site. The object of the scenario game is to get into the characters' heads to learn why and how they would use your site. Approaching the design from their viewpoints makes it easier for you to create a list of the needs and wants of the characters, a wish list if you will.

After you write the scenarios, the next step in the process is to gather the team together and analyze the Web sites of the competition.

Note from the authors: Character scenarios are often referred to as use case scenarios.

Analyzing the competition

Studying the competition gives you the chance to generate a list of the kinds of features they are offering and to determine whether your feature list, the one that you created from the scenarios, is missing anything. If your wish list lacks anything in comparison to your competition, now is a good time to expand the user's functionality requirements, and to return to the scenarios to determine whether the competition's functionality matches your characters' needs. If it does, you should try to elaborate on the competition's functions and create new functions of your own — the classic case of outdoing your competition.

Reaching a consensus on what good design is

At this time in the process, have the team come together to develop a definition of what is "good site design." This step is most beneficial for any contract designer trying to gain an understanding of the client's design viewpoint. To create this "good design" definition, the team should observe a good number of sites and document everybody's likes and dislikes for each one. This way, everyone on the team will have a better understanding of what to strive for and what to avoid.

Structuring the content

Now you should have several documents to refer to — the project mission statement, the user functionality needs (wish list), and the organization's definition of good design. With these three documents in hand, the next step is to blend them into one master menu of content inventory. Think of each item on this list as a building block. You now have all the blocks needed to construct the site. The only problem is that these blocks are in a big pile and lack organization (structure). Naturally, the next step is to begin creating layouts of the site, providing structure. But before you can begin the page layout process, you need to educate yourself on some Web site usability issues.

Identifying factors of usability

Usability is a much-debated concept, but generally it means creating a site/project/interface that is functional and that your audience understands. A usable site aims to be a natural extension of a user's expectations and needs. A user-friendly site tries to mirror its structure to that of the user's experience and goals. Just to make the task at hand a little more complex, keep in mind that user expectations learned in other areas of life affect how the user will think your site works. So, how can you design a site to meet your user's expectations? Well, if you did your homework on your audience and wrote the character scenarios, you should have a pretty good idea of the target audience's expectations. Given that you know the general background of the user, you could include metaphors in the structure of the site. Using metaphors is a great way to help users draw upon knowledge they already have, thereby making the site easier to use. Matching the site structure to the user's experience minimizes the amount of time it takes for the user to learn how to operate or navigate the site. The shorter the learning curve for the site, the better. If you come to a site when you have a specific goal in mind, and it takes you ten minutes to figure out how to achieve your goal, would you call that a positive experience? Most likely not!

Your goal as the designer is to create an attractive site without distracting users from their goals. Forcing users to spend a noticeable amount of time trying to learn how to achieve their goals is very taxing on their patience, and it is a good way to create a negative experience. If you're trying to sell something, chances are you want customers to be happy, not annoyed. One way to make your customers' experience more enjoyable is to make it as easy as possible. So, how do you create a positive experience? Let's start with the most basic of user needs: the ability to navigate.

Users need to know at all times where they are in the site, where they have been, and where they can go. When developing a navigation system, be sure to keep the navigation visually consistent. Inconsistency in the navigation can confuse and frustrate the user. A great concept for a navigational aid is the use of a breadcrumb trail. The breadcrumb system is a visual way to show users the path they took to get to their current position in the site. This navigational convention is used on many resource sites and even in the Flash authoring environment itself — as you click to edit grouped shapes or symbols, the steps you take appear as text labels on the bar above the Stage. Beyond displaying the path of the user, this system gives the user the ability to backtrack to any page displayed in the path. However, remember that navigation is not the goal of the user, only an aid. The user is there to find or buy something; the user is there for the content. So, make the content the first read on all your pages. Navigational elements are there to support the content, not eclipse it.

Of course, navigation isn't the only factor to consider when designing for usability. Other variables, such as the length of text on a page, can affect the usability of a site tremendously. It's a fact that reading text on a monitor is far more taxing on the eyes than reading text on paper. Therefore, people are less inclined to read large amounts of text on the Web. As designers, we must accommodate these changes in reading patterns. Keep these simple guidelines in mind when writing text for the Web. Try to make the text scannable, because readers skim Web content. Bold the important ideas or put key information in bulleted lists. But most of all, keep the text short.

In addition to the treatment of text, there are several other tips to help improve the usability of a site. The concept of redundant links is an excellent method to support users with different backgrounds and goals. With redundant links, a user has more than one way to get to the desired content. The user may have the option to click a text link, a graphic link, or even a text link that is worded differently. Each redundant link should be designed to accommodate a wide range of users. So, where on the page should all these usability elements go?

I can't tell you where you should place your navigation system or your redundant links. However, I can provide you with some information from eye-tracking studies that will help you make an educated decision. Yes, it is true that usability researchers are able to actually monitor and record what you're looking at when you're viewing a Web site. Researchers have found that when a Web page loads, our eyes are looking at the center of the page, then move over to the left, and then sometimes to the right. Of course, these findings are dependent on the user's cultural background. Nevertheless, the scary finding is that the users rarely look to the right! This is most likely because most sites use the right side of the page as a place to add sidebar elements, items of lesser importance. This is also a good example of how a user's experience can affect his future experiences. So, how does Flash fit into Web site usability considerations?

Flash is a great design tool to create amazing interfaces. Flash gives the designer the freedom to create almost anything he desires. But the flexibility Flash gives to the designer is also the tool's greatest weakness from a usability perspective. Flash is great for creating animation; however, inexperienced Web designers can easily go overboard. Just because you can animate an object doesn't mean that you should. The eye is very sensitive to the smallest amount of animation or movement in its peripheral view, pulling the viewers' attention away from the site's main content. On the plus side, animation used as a transitional element is very beneficial for the user. Animated transitions enable the user to follow the navigation process, and gain a better understanding of how the site might work.

Similar to the problem of animation abuse, Flash enables the designers to create their own graphical user interface (GUI) elements. This is great for the designers, but users are often left out in the cold with all this newfound freedom. This design freedom forces the user to learn, almost from scratch, how to operate a scroll bar or a navigation bar. If you recall, I mentioned earlier the importance of a short learning curve for the users. The extreme creative versions of standardized GUI elements might rank high on the "cool" scale, but they really throw a monkey wrench into the user's goal and expectations. GUI standards are developed to help create a consistent experience across all platforms, thereby eliminating any unpleasant surprises. Again, these usability problems can be avoided in Flash if you understand the issues at hand and are able to find solutions based on the set standards.

Other usability issues with Flash arise from the actual plug-in nature of Flash. Unfortunately, because Flash requires a plug-in to work in Web browsers, Flash movies are unable to take advantage of some of the browser's built-in capabilities, such as the Back button and the tool's capability to display history for the links by changing the color of the links that have been clicked. The problem with the browser's Back button is that when a user clicks the button, the browser takes the user back to the previous HTML page, not to the previous state in the Flash movie. It's not a nice surprise for unsuspecting users. One solution to this problem is to pop up the Flash movie in a new browser window (via JavaScript) with all the browser's navigation elements removed (in other words, no toolbar, no location bar, no menus, and so on). No Back button on the browser, no problem right?

Building mockups of the site

You are now ready to begin mocking up the site structure using index cards, sticky notes, and other common office supplies. Creating these paper mockups saves the development team a large amount of time. The beauty of the paper mockups is that you can quickly create a navigational system and find the major flaws without spending long hours developing a beautiful rendering of a structure that may be flawed. There is nothing worse than spending months developing a product with a faulty structure only to discover the mistake just before launch!

Testing the site on real users

Testing the site is the most important step in creating a usable site. The key to testing the site is not to test it on people in the organization, but to test it on people in the target audience. Test the site on the real users. It's usually easier to test the site by using people who are familiar with the project. The problem with that practice is that the people are familiar with the project. You want to test fresh eyes and minds in order to get optimum feedback. For testing purposes, create a list of several tasks to complete on the site. The tasks should be pulled from the list of possible users' goals defined in the early steps of the project. As the test subjects navigate through your project, pay close attention to how long it takes them. How many times did they have to click to find what they were looking for? How many had to resort to using a search feature (or wished that they could)? What elements seemed to cause confusion or delay? What elements attracted or held the users' attention? After each test subject has completed a task, or tried, give her a post-task questionnaire with questions such as:

"How would you rate the quality of the content on this site?"

Unacceptable −3 −2 −1 0 1 2 3 Excellent

Also, leave some room for the test subject to elaborate on the questions. After the testing is finished, review your findings and determine what needs to be fixed. After the problems are fixed, test the site again, but on new users. Repeat the process until you have a product that meets the defined goals of the organization and the users. Keep asking yourself this question: Is the interface helping the users accomplish their goals? When all else fails, you can always depend on the greatest guideline of the century: keep it simple. Oh, how true.