I. As with ALL technical writing the first question to ask is:
A1: Other designers. NOT the customer!! NOT end users!!!
II. Again, with ALL technical writing the second question to ask is:
A2: First, to explain your team's design so other designers can provide constructive feedback.
Second, in the process of doing the design your team flushes out the design and improves it. In this case, the PROCESS is more important that the final outcome.
III. Another question to ask:
A3: Ask yourself the following question -
"What would you like to see in a design document?"
A good analogy which might help you is to think in term of designing your own house. You want to see a floor plan of each floor. You DON'T want to see/think at the level of individual electrical wires or water pipes. What would you include in a document about the design of your house???
IV. Another question:
A4: One useful technique is to WRITE several possible scenarios of the user using the program. You probably will quickly arrive at the conclusion that the team has a VAGUE notion of the workings of your program. If true, your team needs to decide on a concrete image of how your program works for the assignment.
I highly recommend EACH team member WRITE several scenarios, individually. And then the team critically analyzes each in a meeting to explore ideas.
This technique of writing to thoroughly explore ideas or writing to think is an extremely useful technique. For those of us who "HATE" writing this can be a painful experience. (I count myself in that group by the way!) BUT it WORKS!! And when it works, it can be very rewarding.
Several members of class have asked what they are to do for FINAL Version of Design Document (Assignment 2). Very good question! I have decided to make a MAJOR change.
First, the FINAL Design Document is NOT due Wednesday Feb 25th.
Here is what we will do.
2. Create a new web document version 0.2 which incorporates any changes from the design review and and work since writing version 0.1.
3. Later in semester the team will hand in version 0.2 and start a version 0.3. And so on
Our goal is to keep a history of the versions of your teams design document. As your team make progress towards a firm design, your team should try to document the major design changes and they should be reflected in the different versions of the document. Use the organization of version 0.1 as a starting framework and add sections you find appropriate.
Therefore this week, rather than spend time working on finishing the design document, I want you to spend time working on the program. For those who have done work on the "final" document just make them part of version 0.2. Your effort has not been wasted, you will have less to do later.