articles

Developing a Web Site Prototype

By Theresa Wilkinson, W-edge design
Reprinted with permission from the STC Intercom magazine - January 1999 Volume 45, Issue 6.

If you have been reading my last few Intercom articles, you know how to plan a Web site (December 1997), define content for a Web site (June 1998), and define Web site architecture (November 1998). Now what do you do? How can you find out if your ideas are what your users, the intended audience for your site, want or need? The answer is to build a prototype.

A prototype, both paper and online (and I suggest you build both) is a "mini" Web site, including content (or content ideas), graphics, multi-media etc., on a smaller scale than the final site. I have found that developing a prototype is a great way to present your ideas to upper management for approval to go "live." Also, and more important, an online prototype is an ideal application for user testing to ensure your site's success.

Organizing your team

I usually work with a team throughout the planning and designing cycles. I find a team invaluable, especially with brainstorming ideas. If you haven't worked with a team, now is the time to incorporate them. You should have the following people on your team:

• Producer. The producer's role is to organize all the pieces of the site into a coherent whole. The producer has to determine the overall purpose and vision of the site and communicate the purpose to all people involved. He or she should develop a coherent Web architecture that can grow over time, unify all the disparate elements and act as a single contact for legal issues involved, such as permission to link to other people's site. The producer should have experience with project management.
• Graphic Designer. The graphic designer is responsible for the graphic design work. He or she should be familiar with graphics programs and be in charge of generating all images used in your site. The graphic designer should also advise on different backgrounds and text/links colors to be used.
• HTML Author. The HTML author should have an extensive knowledge of HTML and all its variants. He or she should know how different browsers render the same tags and which tags break which browsers. The HTML author's job is to create a site that will look as close as possible to the original design on the widest possible range of browsers as well as being able to implement the more technical aspects like forms. Desirable knowledge: AcitveX, VB Script, Java, Java ++, etc.
• Server Specialist. The server specialist must be able to configure the server and should be able to provide the server-side programs required to make the site run, such as server-side image maps and form submission programs. He or she should also be able to handle any DNS configuration issues that arise.
• Content Editor. The content editor's role is to determine the content that will go up on the site, produce content schedules, and if needed, develop content.

In most companies, people can double up on roles. I have worn the hats of both the producer and the content editor. My HTML author also doubled as the graphic designer.

Planning your prototype

I begin a paper prototype shortly after completing my design document for the site. Drawing out the site helps me visualize it; then I can start to fill in all the blanks. I have identified and solved most, but not all, navigation, layout, content, and programming problems this way. To "mock-up" the site, I use blank, white 11- by 17-paper for scribbling ideas.

When my mock-ups are complete, I present these to my team, and we discuss everything page in detail. Yes, this process takes a lot of time, but it also sparks creativity, which also sparks enthusiasm. The more enthusiastic your team, the better the Web site you will create together.

One piece of advice I can offer to save you numerous revisions is to have the decision-makers to sign off on every page of your prototype at the time you reach your final draft. Then they can't keep adding areas and buttons as the mood strikes them. At the time of this writing, I am devising a form that illustrates each page of the prototype, with places for dates and signatures. The challenge is to give the decision-makers enough information as to envision the site even though you may not have the final content.

Testing your paper prototype

I have created hundreds of paper prototypes. Once you get one drawn out, have your team review it, make changes, and then do it again. When you reach your "final" version, clean them up so they are readable (not many people may have a problem with this, but I do). Have a few people look them over: Give them some tasks to perform, such as locating the stock ticker, and see which section of your paper prototype draws their attention. This is a very inexpensive usability test that really works -- it is much cheaper and easier to make changes on paper.

Using a design form

How do you get your ideas from paper into HTML? I created the prototype form out of frustration when the HTML author I worked with could not lay out the page the way I wanted it. This form allowed me to illustrate how I wanted the pages laid out and give directions if needed. I could also specify the number of pages within an area, such as company information, where everything is related. The author especially liked the menu and next page areas because he could see how this page related with others.

Building your online prototype

Don't spend a lot of time putting all the bells and whistles in your site just yet. For the meeting with the decision makers, put in just enough information so that they can get an idea of the look of the site, approve the graphics and colors, and can click around a little. Define your main page, with the content you want to go live with, and possibly two other areas. The decision makers always like to see company information, so start there, and possibly include a "Products and Services" or "Customer Service" area. Everything does not have to "work" at this point (you can fudge some functionality with HTML). At my former company, the multimedia click-throughs (demonstrations) were not ready for the meeting, so we just added a graphic of the top screen with the "dead" link that would activate them, and the viewers never knew the difference. Of course, if they had wanted to see the click-throughs, we would have told them they weren't ready, but they didn't, and we looked great!

Building the site

Once your site is approved to go live, start building the remaining sections of the site. This is assuming that the decision makers liked the design, graphics, and colors. If they didn't (and who hasn't had that happen?), try to get as much information as you can on what they do want. If they can't give you any clear direction, ask them to appoint someone to work with you. Also, remind them, if necessary, of the "live" date.

If you are lucky enough not to have to go back to the drawing board, gather the rest of your content for your site. If possible, use section templates to build your site. These will help those on your team that are less HTML-savvy.

Ensure all graphics created are appropriate for the purpose and audience of your site. Check on the domain name and server configuration. Check all links, at least three times, to be sure they work. Enforce any standards and consider a formal code review. Make sure your ALT tags are descriptive. The last thing you want is your HTML author pulled off the project at the last minute and no one can make head or tails of your code.

Testing your prototype

When planning your test, think about what you want to learn. How do people interact with your site? What is difficult or easy for people to do? What do they really like -- or hate -- about your site? What information do you want to find out from test subjects -- navigation, labeling, content, and so on?

Consider the site as a whole: A usability test is a means of thinking about the purpose and function of the whole site.

Preparing your test questions

List several tasks (between five and ten) that a test subject should be able to accomplish with the site. The tasks should be simple, so that the novice test subjects have a chance of success. The tasks should be specific and clearly stated.

For example:

• How many software products does the company sell?
• What is the price of the company stock?
• What is the company president's middle name?
• Name four of the company's strategic partners.
• How long does it take via a 14.4 modem to download XYC-1000 product?
• Name three technical specifications for the XYC-1000 product?

These questions reflect a general view of my site. If I wanted to concentrate on a certain area, such as Customer Service, I would focus more of my questions with that area in mind.

Write each task on a separate page to avoid foreshadowing effects. Do not include any hints in the task questions.

Finding your users

Now that you have your questions finalized, it's now time to think about recruiting users. Will you recruit from within or outside your company? At my former company, I emailed my potential test subjects, people within my company but unfamiliar with my site and asked if they had about an hour to go through my site in exchange for a free lunch. I usually had no problem finding subjects.

Don't email just anyone unless your site is for the general public. Ensure your test subjects reflect your target audience.

Setting up

It is best if you can go to the test subjects' environment, where they are comfortable. This allows them to focus on the tasks and the site. Prepare yourself to be objective. It takes a lot of emotional and intellectual energy to listen and receive feedback that may be negative.

Take some time to explain how usability testing is part of the design and development process. Emphasize that they site is being tested -- not them, and not you. But do not explain the site or give them any initial help. Explain that you are trying to understand how the site could be improved.

Ask your test subjects to read the question out loud and to verbalize their thoughts as they performs the tasks on your list. Encourage them to say anything that comes into their mind during the process. Ask them to tell you when they feel they have completed the task.

During the test

Don't help. The goal is for the test subjects to try to solve the problems at each step on their own. The users won't have you sitting with them to give helpful hints, so don't give any to your test subjects.

Sit back, listen and observe. Take it all in, even the silence. Notice the sounds, behaviors, and comments that may be relevant. Take notes when you see the test subjects do something you don't understand or head off in the wrong direction, especially if more than one does so.

At the end of the test, ask follow-up questions to see if you can find out what they did and didn't like and why. For instance you may ask: "Why did you go to Press Room when looking for the stock quote?" Demonstrate how to complete the tasks they couldn't do. You don't want your test subjects thinking it was their fault if they become lost when the fault is in the design. Be sure to tell them that you will be improving the site based on their feedback.

Planning for change

Given the feedback, what parts of the site need to change? Some of your fixes may be as easy as adding a contents or index section or more descriptive labels. Other fixes may be more difficult because they may force you to rethink your navigation.

Prototypes are also one of my passions. With carefully tested prototypes and a little luck, your fixes will be minimal, and your site will be a great success when it launches.

References

Instone, Keith, User Test Your Web Site, Web Review Usability Matters column, Webreview.com.