Projects -- Design

Assistive Technology
Spring 2005
Prof. Jen Mankoff

The "design" component of your project is due on Wednesday, March 2nd. You should come to class with a poster that you can use to tell the class about your project, and a 3 page writeup, plus references. You should follow these guidelines for reporting and writing about people with disabilities when writing this (and future) reports.

Your design document should begin by giving a brief overview of your project, documenting (in 1/2-1 page) what you know about related work, and then describe your implementation/testing plans (at least 1 page). In this section you can also talk about anything you have already implemented. You should tie the justification of your plans to the related work to the extent possible. Remember, you have two months to implement and test your project. Keep the scope feasible.

Normally at this stage of the project, I would also like to see a pilot study (or pilot implementation), however for IRB reasons, most of you will be unable to start that. So instead, it's important that you develop an understanding of the space you are working in (including related literature), what you are trying to prove, and the process by which you will prove it. This is an extension and expansion of certain pieces of your proposal.

In particular, your design document should include a more extensive literature survey than your proposal. If you have any questions about how extensive this should be, please speak with me. Unless you are re-designing a web site, your project will require you to understand what has come before. Typically this means developing familiarity with about 10-20 research papers, and/or products. If you are re-designing a web site, you should refer to the material about testing covered in lecture, and do additional reading as necessary to justify your testing choices.

Additionally, your design document should be more specific about your plans (if you are running a study, you will have to get specific to submit to IRB anyway). You should clearly state the goals of your project, and how you plan to evaluate whether you have succeeded. Your implementation or study description should mention any technology/algorithms/models you plan to build off of, or describe any studies you plan to run. For example, if your goal is to make a web page more accessible, how will you test it's accessibility? You might choose to test with users who are blind, or to test using a screen reader, for example. Which will you do? How many users will you test with? What tasks? And so on. If your goal is to create a better scanning interface, how will you judge whether you have improved the original? You might test whether the individual you are designing for can complete the tasks she cares about faster than before. Again, how many users, what tasks, etc? If your goal is to create a tool that can render a graphical interface in audio, how will you show that the tool is successful? You might show that it works with a number of different representative interfaces. And so on.

If you are able to start any implementation, your design document should also talk about what you accomplished