Winter 2007

Course Web page:
http://polaris.gseis.ucla.edu/pagre/is282.html

Notes on the design project.

Recall that there exist two general schools of design, engineering and architecture. Now it is time to combine these schools in whatever way seems best.

This is conceptual design rather than design based on detailed requirements. The important thing is to articulate a single idea and work it through in a thorough and incisive way.

Phil and Christine are your clients and the other students in the class are your users. You will be managing all of these stakeholders. They will have lots of good ideas, and they probably have knowledge about the domain that you lack. And it's their money. But you are the designers. You are the only people who know how all of the pieces go together.

You will have five opportunities to discuss your work in class with your stakeholders. Decide how best to use the time. If you will be using A/V equipment in class other than a Macintosh and a screen, please reserve it ahead of time. In general, your first two iterations will probably be divergent in nature, so that you think up all of the possible good ideas, and your other three iterations will be convergent, so that you understand thoroughly how to put the pieces of your project together cleanly. For your first iteration, your main goal will probably be to introduce your stakeholders to the specific domain you have chosen for your project. This could include artefacts and multimedia. It will probably involve specific design ideas, though maybe not diagrams. Design a group process that gets you a good strong outline of your stakeholders' thinking about the domain, hopefully including lots of brainstormed design ideas. For your second iteration, your main goal will be probably be to get the stakeholders to talk through the issues related to some potential designs. Your third, fourth, and th iterations will probably be about working out the specifics of one design, although it is common to make important discoveries about the design problem even late in the process. Your sixth iteration, which you'll turn in during finals week, will be detailed enough that someone could implement it.

Your data needs to be stored in relational databases. This means that free-form documents and other media objects with lots of internal structure are out, though simple media objects are okay. This is your major design constraint. Note that most metadata is relational, so that a system could include, for example, a library of audio clips.

Process diagrams are more difficult to prepare than entity-relationship diagrams. They are also less important. Although your final write-up will include a process diagram, you will want to make rational choices about whether and how to include process diagrams in the earlier phases of the design process.

Assume the technology of ten years from now. Cheap flat screens. Portable supercomputers. Terabyte hard drives. Ubiquitous broadband wireless. Grid computing.

We haven't talked about user interface design, but that's just as well. Invent your own interaction protocols. These might involve a desktop monitor with keyboard and mouse, or they might not. Computation, communications, and interaction can be embedded in anything.

Some other issues that we aren't emphasizing in this class: making your system work as a business, what hardware and operating system it runs on, what legacy systems it has to interoperate with, and generalizing it to other situations (e.g., other types of shopping or places) than the particular one you have chosen for the assignment.

Things to include in the final project: an entity-relationship diagram, clear definitions of what each of the entities means, a process diagram (hand-drawn diagrams are fine), some rhetoric that makes clear in a concise and sloganistic way what your system is and how it is valuable, what the user therefore experiences in using your system, and the main design problem that your group had to solve. Remember that the number one mistake that designers make, especially when they are tired at the end of a project, is mentally identifying with the internal guts of the computer rather than with the user's experience.