Back to Homepage

Homework 2: Design specification

You know that problem you defined this past week? It's time to solve it. Your task for this homework assignment is to design a solution to it that has the following characteristics:

• Your design should adequately address your problem. It doesn't have to a perfect earth shattering solution to a big problem; a meaningful, incremental solution to a small problem is just fine.
• Based on your best estimates, your team can implement a solution in less than 3 weeks of part-time effort. Your solution should be a “minimally viable product,” which provides value to your target audience, but doesn't necessarily achieve all possible functionality. That means real functionality and real content (if appropriate), but not all the functionality you can imagine or all of the content you can imagine. Think of YouTube, but just video playing, basic video uploading, like and dislike buttons, and ten of the best cat videos you've ever seen. That's enough to provide the smallest possible value that YouTube can provide (and probably pretty close to what they initially launched).
• You should be able to build your solution using free components and services. (Don't spend your own money. You can if you want, but you're not at all required to).

For this assignment, you don't need to write any code. Instead, you'll be writing a design specification that details the visual and interaction design for your solution (as you've likely done in INFO 360). You should include enough detail that you'll be able to use this as a reference in later deriving requirements.

Your specification should have the following sections:

• Problem. This is a refined version of the problem statement from last week. A good problem description is a logical, substantiated argument that proves the existence of a problem. Your problem description should cite evidence from your user research, as well as any scholarly literature you can find about the problem. This doesn't need to be long; a few paragraphs is usually enough to clearly define the problem you're solving.
• Solution. This section must detail every design decision necessary for engineering your solution, including every screen, every error, every algorithmic functionality, and every detail about the textual and visual content of your design (aside from content created by users). It must also detail the design rationale for every decision. How much detail is enough? If your solution is software, a software engineer should be able to read your specification and build your solution without asking you any questions. Embed mockups of screens throughout the text of this section to visually specify your design. Because of the short timeline, it's okay if these are hand-sketched.

Write your specification in a Markdown document in your repository's wiki.

Note that you only have a week to do this. That means that your design really can't be that complicated from an interactive perspective. Keep your solution simple. Our focus in this class will be on something that is architected well, defect-free, and shipping, not something that is multifaceted and powerful.

Also note that what you build doesn't have to be a graphical user interface. If you want to build something command line based or even an API, that's okay too. You still need to specify how someone interacts with your design, detailing the commands or APIs that you want to build and explaining in natural language what their behavior is.

Grading Criteria

For homework credit, submit a link to the design specification committed to your GitHub repository.

• Problem (1 point). Full credit for something that is logically sound and clearly defined.
• Details (3 point). Lose 0.25 points for every interactive detail that is critical to solving the problem that is not specified. It's okay if visual details are not specified, since those can be changed easily. I want to see the core functionality of your application fully specified.