Final Project

As part of this class, you will produce a final project that demonstrates the skills you learned throughout the semester, in partnership with a third-party.

Project selection

You will be expected to produce a project that meets a real need. In many cases, you will be exposed to appropriate technologies in the class and provided "recipes" that solve the technical part. A great deal of your time will be spent on "soft" skills, not writing code.

You may find it helpful to take a look at What Should You Use Docassemble For? and the chapter on Choosing a Project.

Phase 1: Coming up with a project idea

You must select a project and a partner by week 4.

See Project ideas for some possible project ideas and partners. You do not have to have a project idea before approaching a partner, but think about the technologies that we discuss in class and how they might address your partner's needs.

One source of project ideas might be your employer, a substantive clinic, or a need that you have encountered through a family or friend. I can help you approach a partner if you have an idea but are not sure which partner would make the best fit.

Phase 2: Work on your project

In week 5, you should start working on your project. We will still have regular assignments, but by the second half of the semester they will have ended so you have time to work on your project. Use the user-centered design framework of:

• User research
• Ideating (brainstorming)
• Prototyping
• Gathering feedback / testing
• Iterating

You should use one of the annotated project templates as a starting point, which are available here.

The samples include:

• An intake to Google Sheets
• Filling in a Word template
• A non-linear menu-driven interview that someone can return to over time (a ledger)

Watch a video that describes the project templates (40 minutes).

Watch a video that explains how to install the templates into your own Docassemble playground (1.5 minutes).

Phase 3: Turn in your work

Your final deliverables will include:

• A github repository of your work, completed one week after our final class session. (April 29, 2020 at 12 noon)
• A slide deck and presentation
• A letter from your project partner
• A detailed narrative describing your work process, documenting user testing, and describing the research you did to produce the final project.

Grading

Process (40%)

Category	Exceeds expectations	Meets expectations	Below expectations	Weight
Framing: how well does the student define the problem?	Enough detail for highly tailored solution	Enough detail for a well-tailored solution	Does not fully describe the problem
Research: how well are existing solutions reviewed?	Substantial review of existing solutions, including relevant technical and content-based solutions (e.g., form banks) and involving consultation with practitioners	Substantial but no-exhaustive review of existing solutions, including relevant technical and content-based solutions (e.g., form banks). May involve consultation with practitioners.	Cursory or no review of existing solutions, far below that done for other projects.
Ideation and Prototyping: How well does the student explore the available space of potential solutions?	Considers and weighs the costs & benefits of multiple technical solutions or design configurations. Creates prototype only after considering at least three alternatives. These may be the subject of A-B testing below.	Considers and weighs the costs & benefits of multiple technical solutions or design configurations. These may be the subject of A-B testing below.	Fails to consider and weigh the costs & benefits of multiple technical solutions and design configurations.
User Testing: How rigorously does the student engage in user testing, and how realistic are such tests?	Makes use of two or more of the following in close to real-world conditions: A-B testing, multiple testers other than themselves for each type of user, potential real-world user(s). Captures user feedback in a uniform comparable manner. Student provides copy of user feedback.	Makes use of at least one tester other than themselves for each type of user in close to real-world conditions. Captures user feedback in a uniform comparable manner. Student provides copy of user feedback.	Fails to make use of a tester other than themselves; or fails to replicate close to real-world conditions; or fails to capture user feedback in a uniform manner.
Refinement: How well does the student integrate feedback from user testing into subsequent versions of their solution?	User feedback is thoughtfully integrated into the final version of the solution (where the solution includes both the technical product and any documentation). At least two rounds of user testing were conducted with iterative improvements to the solution after each round. Use of multiple tests amount to more than testing for testing's sake.	User feedback is seriously considered and used to inform the final version of the solution (where the solution includes both the technical product and any documentation). The final version is not the same as the original version (i.e., there are at least two versions).	Fails to seriously consider user feedback in final version of solution or fails to create multiple iterations of the solution.

Deliverable (60%)

Category	Exceeds expectations	Meets expectations	Below expectations	Weight
Intro Pitch: A five-minute presentation, with slide deck, that introduces the problem the student aims to address, including the general shape of their nascent solution.	Clearly presents a problem facing legal practitioners or consumers, including: (1) a definition of relevant stakeholders / users; (2) options currently available to users, remember doing nothing is an option; (3) an introduction to their partner; and (4) a rough sketch of how they intend to develop a solution. Quality, clarity, and focus of presentation and slide deck greatly exceed that of other presentations.	Clearly presents a problem facing legal practitioners or consumers, including: (1) a definition of relevant stakeholders / users; (2) options currently available to users, remember doing nothing is an option; (3) an introduction to their partner; and (4) a rough sketch of how they intend to develop a solution.	Fails to clearly present a problem facing legal practitioners or consumers, including: (1) a definition of relevant stakeholders / users; (2) options currently available to users, remember doing nothing is an option; (3) an introduction to their partner; or (4) a rough sketch of how they intend to develop a solution.
Complexity/Robustness. To what extent is the project taking on a substantial process?	Involves non-trivial use of at least two of the following: an expert system; document automation; data scraping from a data source not in the student’s control; a machine learning algorithm trained by the student.	Involves non-trivial use of an expert system, document automation, data scraping from a data source not in the student’s control, or a machine learning algorithm trained by the student.	Fails to make non-trivial use of an expert system, document automation, data scraping from a data source not in the student’s control, or a machine learning algorithm trained by the student.
Impact & Efficiencies: Does the project offer the prospect of greatly increasing the efficiency or expanding the reach of existing practice?	Expands the reach of a single practitioner by more than 100 or decreases the amount of time expended on the automated task by more than 50%. Note: expanded reach must account for all work flowing from the solution such that this work will not result in new work for a practitioner. That is, it assumes the practitioner is already working at full capacity. So increased lead generation doesn’t count. More efficient selection of high-value clients, however, can count when this is reasonably projected to lead to a more than 5% increase in revenue.	Expands the reach of a single practitioner by more than 10 or decreases the amount of time expended on the automated task by more than 10%. Same reach considerations as Exceeds Expectations. More efficient selection of high-value clients, however, can count when this is reasonably projected to lead to a more than 2% increase in revenue.	Fails to expands the reach of a single practitioner by more than 10, fails to decreases the amount of time expended on the automated task by more than 10% and fails to improve selection of high-value clients. Same reach considerations as Exceeds Expectations.
Fit/Completeness. How well does the project address the stated problem and known needs of the identified users? Does it do what it was designed for?	Produces viable output. UI is intuitive / well-documented. Directly addresses the stated problem for the stated user types such that it is reasonable to assume almost all users of any user type would find the solution a great improvement over the status quo in nearly all conceivable use cases.	Produces viable output. UI is intuitive / well-documented. In broad terms, the solution address the stated problem for the stated user types such that it is reasonable to assume most users of any user type would find the solution an improvement over the status quo except for a small set of edge cases.	The solution as executed would reasonably be expected to create confusion or frustration when used through poor design or incompleteness.
Documentation. Is there sufficient documentation to address user needs? Note: your partner is a user. Documentation includes all “help” text, including that found inside your solution. It need not be an external document.	Well written and approachable for the overwhelming majority of potential users. Sufficient to address all likely user concerns as well as important edge cases.	Clearly written and accessible for most potential users. Sufficient to address all likely user concerns.	Unclear or insufficient to address all likely user concerns. This includes failing to provide documentation, where appropriate, for a user type.
Real-world viability: How far is the project from production?	Ready for real-world use as is. This includes a working technical solution and all supporting documentation. It need not include placement on a server or user authentication.	Identifies what steps are needed before real-world use, and such steps are estimated by the instructors to be less than two day’s work, excluding placement on a server or user authentication.	Fails to identify what steps are needed before real-world use, or such steps are estimated by the instructors to be more than two day’s work, excluding placement on a server or user authentication.
Sustainability: How robust is the plan for continued operation?	There is a clear plan for continued operation, updates, and maintenance, and the partner seems ready and willing to implement it.	There is a clear plan for continued operation, updates, and maintenance.	There is no clear plan for continued operation updates, or maintenance.
Project description: A short written description of the project’s development, structured to address each of the enumerated categories in this rubric, minus this one. May also include a video presentation (if aiming to exceed expectations).	Sufficiently descriptive to answer almost all instructor questions regarding the above categories when combined with a copy of your working solution, user documentation and user feedback. These materials alone would be sufficient to grade the project on the preceding categories.	Sufficiently descriptive to answer the majority of instructor questions regarding the above categories when combined with a copy of your working solution, user documentation, and user feedback. Only a few follow-up questions are needed in addition to these materials to grade the project on the preceding categories.	Insufficiently descriptive to answer the majority of instructor questions regarding the above categories when combined with a copy of your working solution, user documentation, and user feedback.

Sample grading sheet

Grading rubric courtesy of David Colarusso