A prototype of a website, for our purposes, is a draft version of a website hosted live (what is called a high-fidelity prototyping). It usually consists of three pages: home, second page, and contact page. Images are placeholders and most information is presented as a "concept".

Building a website prototype can be done at any stage of the project, but we build prototypes as soon as the discovery stage has been completed. Building a prototype very early in the project offers many advantages:

1. Eliminates risks for clients: clients get to see a "preview" of the future website and have a chance to provide feedback
2. Saves time: it is cheaper and easier to make changes early in the development process
3. Ensures higher level of customer satisfaction: clients provide feedback and clarifications as well as approvals after each milestone
4. Simplifies QA: as prototype evolves into a full website, usability flow is tested and reviewed both by developers and the client - before the final QA even begins
5. Provides sufficient time and opportunity for reviews, thus preventing contract disputes and other unpleasant miscommunications
6. Ensures better quality: ownership of the project is shared with the client, hence developers feel more pressure to perform better
7. Simplifies project management decreases risks to a minimum, i.e. there is always plenty of room to correct potential errors and catch misunderstandings.

Those are the main advantages of creating a high-fidelity website prototype early in the project. There are, of course, some disadvantages - but only for developers, none for the clients. The main disadvantages for developers of a live website prototype include the following:

1. More communication time required: clients receive a link to their website's prototype early in the project, and then they check every day, send emails and small questions on the fly
2. More detail work required: client feedback is incorporated in three or four review cycles. But even after the official reviews have been completed, and client's approval on the interface design has been received, many clients change their mind and request tiny tweaks here and there
3. Higher level of frustration: not all clients are familiar with current web design standards or best practices. They often request things that developers are reluctant to incorporate (for example, instead of adding a Site Map link in the footer, some clients request it to be added as a main menu item; some clients request adding a link to an external website as a main menu item, etc.). In most cases, they can be convinced to follow current web design standards, but not always. In some cases, clients' personal taste prevents designers from including the final website in the portfolio display (it happens more often that we thought it would!)

But overall, whatever the differences in opinions or tastes - clients have the final say. As long as clients are happy with the development process and the final results, the project can be considered a success. Client satisfaction is the ultimate measure of success. Our own opinion is just that - an opinion.

Whether you are planning on having your website run on Joomla, Drupal, WordPress or any other content management system, if your website is expected to have some user activity - you need to create a set of main use cases before the design process can commence. 

Not Writing Use Cases Costs You

In practice what often happens is that when marketing managers source a web design agency they usually provide some basic description of what they would like the website to do and expect the design agency to recommend the best "flow". Later, after the flow has been completed by the design agency, clients often request "changes" because the recommended flow does not reflect their vision adequately, and then those changes can sometimes be very significant, which often leads to additional charges. In other words, clients first pay for the recommended flow and then for its adjustment to their vision.

There is a simple way to reduce this two-stage - unpleasant to the client - process to one: develop a set of uses cases before starting the design process. 

What is a Use Case

In web design a use case is a detailed description of how users will perform a particular task on your website. For example, download a whitepaper, post a resume, search for a job, complete a payment, register for an event. etc.

Each use case should begin with defining a goal of a particular task and then establishing a starting point for it. Each use case should end with the "last step" in the process - and not only from the user's perspective but also from the perspective of a website administrator who will be gathering and analyzing the website activity information on a regular basis.

In other words, for each use case you need to determine the following: what you want your users to do on your website and what they might want to do on your website (which is not the same thing!)

• Your goals or what you want users to do (e.g. download white paper and then call you to order your products)
• Specific sequence of steps you expected them to perform
• Users' goals for performing these tasks (e.g. read useful informaiton free of charge and not necessarily order anything)
• Users' expectations of what type of information they should be offered

When you determe both perspectives, you will be able to find "overlaps". And this will help you determine how the website should be structured and how it should respond to a user action.

How to Write a Use Case

The easiest way to write a use case is by writing text - with detailed description of what happens or should happen at what point. Your narrative would be exceptionally useful if you also find an example website that has the exact (or very similar) flow that you would like to have. 

But before you do that, you need to establish the main purpose/goal of your website. Is it to educate? to sell something? to promote something? Write down all your goals specifically and then proceed with defining those use cases that would affect your goals the most.

Here is a short list of how to write an effective use case:

• Identify the type of users you expect to use your website (accounters, students. board members of your company, event participants, etc)
• Create use cases for each type of users. Start with the most important one. TIP: To define the most important users, focus on the $$ or authority. Does a user type affect your revenue? Does it affect your company? Start with those users who affect these two things the most.
• Define what that user is expected to do on the site (download, register, buy, etc). Each one of those expectations will be a separate "goal" and it will have its own use case.
• For each use case, decide on the normal course of actions. For example, a user comes to a website via an email invitation by clicking on a link from that email. The user "lands" on a specific page where you present them with an option to register in order to receive something. The user registers (clicks the call-to-action button). What happens then?
• The user receives a thank-you email? What would that email contain? Will the website send one thank-you email or will it also send a follow-up auto-reminder of some kind?
• It is assumed that all user registration information will stored on your website, otherwise, why would you need a website? What kind of registration quesitons would you need to ask in order to generate more $$. 
• Would you allow sales people to call users who registered on your website to follow up? If yes, then you need to ask for the user's permission during the registration process.
• Can the user do more than one action?
• Can they create an account and view their activity history on your website? 
• Can this user come back and repeat the same action? 

All this information needs to be captured in a use case. That is why it is called "developing a use case", because it takes a few rounds to editting to establish the right amount of information. 

After you've developed a written text-based use case for each important (business-affecting) task and user type, it is best to provide an example website that utilizes something very similar to your goals.

After your web designers analyze your use cases, they might still have questions for you! And after they've clarified all the details, the will be able to create a use-case flow diagram.

Use Case Flow Diagram

Creating a flow diagram is a very important step and yet very few design agencies do that. A master diagram showing interconnections between various user types prevents a lot of miscommunications. It also simplifies Quality Assurance and Project Management. 

One of the easiest way to create a use case flow digram is to set it up in a series of PPT slides. Once you "glue" them together, you will be able to see where your "holes" or "missing steps" might be. 

If your site is simple, then a verbal text-base use case description might suffice. But if your site has several inter-connected user activities - a diagram in addition to the textual description is a must.

If your web design agency did not volunteer to create a master use case flow diagram, request that they do. Depending on your contract, there maybe a portion of the budget allocated for the "discovery stage". If it is the case, then the use case flow diagram should be provided to you. If there is no discovery phase covered by the budget, still request it from your designers. And if they refuse (unlikely!), then you need to create such a diagram yourself. 

What happens if you don't? Well, nothing terrible, the skies won't fall down on you. You will end up spending additional time writing emails, clarifying and explaining, calling and asking for revisions - and also paying for all additional changes. That's all.