CS3724, Fall 2000

Due as per class calendar

Activities

Choice of client

Select a potential client organization (e.g., from Yellow Pages or Campus Directory), someone or some organization who needs a new system or a revision of an existing system, that will provide the setting for a hypothetical system your team will develop in subsequent projects. It is fine to use connections you already have (e.g., places you have worked, places where friends work). The client will be helping with requirements and design now, and evaluation later on. Although you may be able to set everything up for Project 1 over the phone or possibly e-mail, you will need to meet with the client directly several times during the semester so it is much better to have a local client. Choose wisely and don't use inaccessibility of your client as an excuse later.

In some cases, where your application system is for the general public, your client can be other students, friends, or family. In those cases, though, make sure you have contacts with the kinds of people you will need to represent all your different user classes.

It is acceptable to choose a client who is the employer of one of your team members. However, that team member cannot act as a client representative for this project.  That person must assume the role of developer and cannot be a significant source of client information, especially for clients interviews.  Otherwise it is a conflict of interest.

Contact your client organization, explain your assignment, and get someone at the organization to agree to participate as the client contact for your team. If your first choice for a client cannot participate, keep looking for a client!

Choice of application system

First, be sure the system is the right size. Very large and complex systems are obviously not good choices as vehicles for learning the interaction development process. On the other hand, be careful not to select a system that is too small or too simple. The criterion for selection here is that you will need to identify about a half dozen somewhat different kinds of user tasks. That usually means, for example, that a Web site used only for information seeking is not a good candidate, because information seeking is only a single type of task. You should also choose a system that has more than one class of user. For example, an e-commerce web site for ordering merchandise will have users from the public doing the ordering and employee users processing the orders.

We are often asked if an extension to or redesign of an existing system would be an acceptable choice. The answer is yes. You will still do the up-front analysis for the new part of the existing system you will be working on. Your work should lead to a new design for this part of the system.

We are also asked if a real project can be used, with the idea that what you learn and do in this course can be leveraged and applied on a real project. In selecting your design topic, remember that the goal is not for you to develop a real system. I recommend against using this project to develop a system or interaction design that might, for example, apply to part of your job or to something like an independent study or thesis. The reason is that real projects have constraints and requirements that usually compete or interfere with the goal of learning the user interface development process. Since the purpose of the course project is to serve as a vehicle for learning the usability process, conflicts with other aspects of a real project make this a bad choice for this course. Some rare exceptions can be made, if you can convince me that you are truly willing to relinquish control and allow the design to go where the team and the course requirements take it. However, if you have your own fixed ideas about the design or you are not willing to see others messing with your pet project, do not choose that for your team design topic. The rule is that the pedagogical goals outweigh all other possible goals for this project. It is intended to be an exercise through which you learn the user interaction development activities by hands-on experience. If you do choose a real project, you have to agree to this simple rule: Whenever other needs and constraints conflict with the use of this project as a vehicle for learning the usability process in this course, the course has to take precedence. (You can follow up in any way you want, of course, after this class is over.)

In any case, you must keep it simple. More of the time spent can be for learning, it will be less work load, and it will be more fun and easier to carry out all the development steps. If one of your team tries to get you to accept such a real project as a topic, try to talk them out of it. It that doesn't work, let me know right away and I will talk with them about it and we can decide.

As examples of the kinds of systems you might choose to develop an interaction design, consider these:

• System for cataloguing CDs, records, and/or tapes
• System for giving directions (e.g., a campus kiosk)
• System for cataloguing personal book or manuscript collection
• Video tape location and rental system
• Menu-recipe management system
• Auto parts store sale and inventory support system
• Foreign language drill system (you don't need to know any foreign language for what I have in mind)

Deliverables

Get a binder to hold all deliverables for the semester. You will add the deliverables for each stage of the project as it comes due. Punch and bind your project deliverables in this binder. The best type of binder to use is an Accopress or a Duo-Tang, both available at any office supply place or the bookstore. Do not use a regular 3-ring binder; they are too bulky for us to carry for the whole class. Put a label on the outside of the binder with (in this order, please):

• Your team number
• Your overall project name (e.g., Acme Pizza Inventory System)
• Name of client organization
• One-line overall project description (e.g., New inventory system, including point-of-sale inventory adjustment and wireless "terminals" for verifying inventory on shelves)
• The names of all team members
• "CS3724 – Fall 2000"

• "Project 1: Topic, client"
• Team number
• Project name
• Name of client organization
• One-line description of project
• Team member names
• "CS3724 – Fall 2000"

1. Name of client organization
2. Name of client contact person (name, phone and/or e-mail)
3. High-Concept Statement (high-level conceptual description of systems): A short and sweet (up to 75 words) summary of your project, to be used as a "boilerplate" description of your project in all of the deliverables. This is a high-level mission statement of the project. Include the name of the system, name of client organization, kinds of users, brief statement of what users can do with it, and why it's useful (what problems it solves).  Your audience for the High-Concept statement is broader than that of the rest of your project documentation.  The audience here includes your manager, your manager's manager, potential investors, and the general public.
4. Further project description (as needed or useful): You can further motivate usefulness and capabilities in terms of what users can do. Make it clear if the system exists or not. This is a proposal, so use the future tense and state capabilities in terms of what users can do. For example, say, "This system will allow such-and-such a kind of user to do . . ." If the system itself does exist, make it clear what you will do to improve it, distinguishing what is new and what is not.

The product of this stage (high-concept statement) is a much broader description of the system than you will actually develop in subsequent projects.  To get started, we want you to take a broad view of the system and in later stages you will select a few key parts (subset) of the overall system.

The 75 words (or fewer) you write here will be the most important words in the whole project; they should be highly polished.  That means you should spend a disproportionate amount of time and energy thinking about, writing, reading, editing, discussing and re-writing it. If you don't know how to do this, ask in class. Don't wait until you get the graded deliverable back to find out.

In your High-Concept Statement, to be efficient with words. Chop out "empty" words that don't say anything new. On the other hand, be as specific as possible within the word limit; do not be vague and try to communicate by implication. I.e., don't leave it to the reader to fill in the blanks.  You should use positive statements about what will be done.  This point is best made by example.

EXAMPLE: "This information system allows user to keep track of which products are currently products in stock at the store." This (by implication) seems to be an inventory system (more specific than "information system").  Plus, doesn't it help keep track of the products that should be ordered, too?  If so, say so.

EXAMPLE: "The goal is for the XYZ System to be easy to use."  It's more specific to say how you  expect it to be easier to use, such as "Sales clerks on the floor will be able to update inventory as a routine part of sales."

EXAMPLE: "The XYZ System handles accounting information and allows the accounting people to post results."  What does "handles accounting information" mean?  Those words are to vague. What kind of accounting information and what operations are implied by "handles"? Is it used by all accounting people?  There could be lots of different kinds of accounting people and only some are users. What does "final results" mean? That is the most vague term of all here.  What does "posting" mean? In accounting statements, on the Web? Are they printed and put on a bulletin board?

Audience for all reports

The audience for all your project reports is your technical manager, who is not involved in the day-to-day development activities and is not highly knowledgeable about the usability engineering process, but wants to be kept up to date. Use clear, plain English. Don't use esoteric, domain-dependent terminology, jargon, or acronyms.

Grading

Read what you write, because someone else will! Work on writing as a team. This is the time to really get the spirit of this project and nail this assignment! Beyond trying to assess objectively whether all requirements are met, we try to assess subjectively how well requirements are met. This is based on our own knowledge and can sometimes be somewhat relative among the projects of the class. Your grade is based on our perception of how much you put into it and how well you understood, interpreted, and applied the material covered in class to your project. You can be sure this is done is the fairest way possible. Please don't expect us to just skim each deliverable and hand out all high grades.