INFO 360 Design Thinking

Schedule • Grading • Activities • Reading • Midterm • Project

Projects Portfolio

These are the great projects developed by students in the last month of activities for the Fall 2018 quarter.

BookSwap	CollegeSource
Discourse	Globridge
HireMeFelony	MentorMe
RampUp	SeeCC
SpeakingWeb	VolunTool
Annotia	Vote

Project Description

When choosing a problem to solve, it's tempting to choose something incremental and familiar. Make a better Facebook. Make choosing dinner easier. Fine-tune students' task management. While these are all worthwhile problems, they all tackle relatively minor inconveniences. This quarter, I want you to tackle big, wicked problems with simple designs.

Therefore, the project theme for this quarter is:

structural inequalities

That's a big phrase, but it actually refers to something quite simple: sometimes, our institutions are built in a way that leads some people in society have unequal status, opportunities, and resources. Some structural inequalities are just unintended side effects of society evolving over time (e.g., English is the single dominant language in America, which creates barriers for non-English speakers). Other structural inequalities are intentional (e.g., creating a law that prohibits public signs from being in languages other than English).

Because this is a class about the design of information, information technology, and information systems, we'll be focusing on structural inequalities that arise from information gaps. Here are some examples of information gaps, and how they result in structural inequalities:

Many youth in rural areas are less aware of high-paying careers because there are few people who have those careers in their community. This results in youth not developing interest in those careers, and not pursuing those careers, ultimately reinforcing a cycle of poverty.
Youth whose parents did not go to college often lack knowledge about what it takes to get into college, such as the importance of Advanced Placement classes, extracurricular activities, and other factors in admissions. This lowers chances of admission to college, limiting educational attainment among low socioeconomic status youth.
Many low-income youth assume that college is too expensive, and do not know that there is substantial financial aid available to heavily subsidize their education. This deters students from pursuing college, reinforcing poverty.
Many K-12 schools now communicate critical information about student learning and experiences via email, but 13% of U.S. families do not have access to the internet. This disempowers parents from supporting and advocating for their children at school.
Students who are blind or low vision often perceive a lack of accommodations in introductory computer science classes and assume the rest of the classes in the major will be similarly unsupportive. This results in students with disabilities avoiding becoming CS majors, resulting in an extremely low percentage of software engineers who are blind or low vision.
In the U.S., nearly all teaching and teaching materials are in English. Therefore, students who do not speak English as their native language must put forth more effort in classes to succeed than students who are native English speakers.

For the project, you will form a team two or three classmates and:

Investigate a structural inequality
Identify informations gaps that cause that inequality
Articulate your understanding of that information gap
Become an expert on that problem through interviews and research
Ideate solutions to the problem
Prototype solutions to the problem
Detail one solution in the form of a design specification
Communicate the solution as an interactive prototype (and/or a video).
Evaluate the solution your classmates designed for you.

What counts as good design? Anything that actually addresses the problem an underserved population has is acceptable.

Prototypes

If you wish to quickly convey what your design does, try creating a storyboard. You can also use site mapping tools to lay out the relationships between pages in a site or application.

As part of creating the specification and video prototypes below, you'll need to create high-fidelity prototypes of your designs. If you're doing screen-based user interface design, I recommend using some combination of the following tools, which are based on decades of HCI research on rapid prototyping:

InVision for its strong collaboration and workflow support
OmniGraffle or other diagramming tools to create medium-fidelity screens.
Prott or other similar tools for high-fidelity web, iOS, or Android designs
Axure for more interactive, data-driven prototypes
Moqup for interactive prototypes
MockPlus for interactive prototypes
Marvel for simpler collaboration around static prototypes
Balsamiq for lower-fidelity interactive prototypes.
Figma for collaborative web-based prototyping.
Adobe XD, a powerful experience design tool

There are also many simple, quick tools for making basic graphic design choices about fonts, colors, and icons. You shouldn't have to use advanced graphic design tools like Adobe Illustrator, Photoshop, or Experience Design in this class. If you already know them, feel free to use them, but they have learning curves that are a bit too high to excel with them. That said, if you want a challenge, find someone who can tutor you and dive in!

Specification

The point of a design specification is to document all of the decisions you've made about your design, from the high level details about the problem it is solving and how, to the low level details about fonts, colors, and layout. Your audience for a design specification is an engineer whose job it is to build your design. A great specification is unambiguous and carefully argued so that the engineer knows exactly what to make, doesn't have to do any design themselves, and doesn't decide to change any of your design choices.

Here are two examples of specifications that scored higher than a 90%:

Both are simple, clear, concise, and well-argued.

Your design specification must have the following sections:

Problem. This section must be a sequence of paragraphs, each with a topic sentence, that 1) convinces a reader that a problem exists in the world, 2) convinces them that no existing solution solves it, 3) teaches the reader what causes the problem, and 4) isolates which cause you're going to address through design. In doing this, you must use one or more of the following forms of evidence to substantiate your claims about the problem:

One or more research papers supporting claims about the problem.
One or more existing solutions that fail to address the problem.
Evidence from your own user research

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). How much detail is enough?

If your solution involves software, a software engineer should be able to read your specification and build your solution without asking you any questions. This means providing two classes of specification: what information to compute (but not how) and what to information to store (but not how). For example, if you have an application that is going to compute a recommendation, you must specify exactly what kind of recommendations the system will compute with example data and data structures, but no details about algorithms for computing it. Additionally, you must give design rationale for major decisions of your design ensuring that the engineer who builds it doesn't change your decision. This might come in the form of empirical evidence, a citation to a research paper, or a convincing argument. "Major" decisions include anything that influences how well your design addressing your problem. For example, for most designs, the color you choose to render a button won't influence a design's merits.
If your solution involves content (e.g., words on a website), you should specify the information architecture of the content, including different categories of content, how it will be organized on a site, how much of it needs to be created, how it will be created, and give examples for each kind of content. This provides enough detail for someone to generate the content according to your specifications without you having to create the content for the specification. Just as with software, you must give design rationale for major information architecture decisions, ensuring the content writers don't change your decisions.

Evaluation. This section must present some form of empirical evidence of the quality of your design. This might be an interview with an expert on the problem you studied, a series of interviews with representative users about the utility of the design, or a some other form of investigation about how well your solution addressed your problem. The only requirement for the evaluation is that you do more than nothing.
Limitations. This section must detail all of the ways in which your design does not work, including who it doesn't work for, the situations it doesn't work in, and the assumptions it makes about how someone uses it for the design to effectively address the problem. A good limitations section is thorough and transparent, critically discussing the major ways in which the design can fail.
References. This section should include all scholarly publications and websites you cited in the main text of your specification.

Throughout, you should include annotated mockups of all of the screens in your design, where appropriate for clarity.

Your specification must satisfy the following formatting constraints:

8.5"x11" PDF
1-inch margins
11 pt for body and larger for headers.
Figures and Tables must include numbered captions (e.g., Figure 6).
The text should cite figures explicitly (e.g., "as Figure 6 shows...").
Single column.
Single spaced.
Cover page with names, team name from Canvas, and optional name of design.
To ensure brevity, your entire document should be roughly 2,500 words. Don't worry about being lower this limit exactly; just recognize that the more over it you go, the more likely you're not being concise, and will likely fatigue your poor instructors.

Write your specification in Google Docs. This simplifies obtaining feedback from peers and from the TA and I.

Grading

Your specifications are worth 20 points. We will grade your specifications by deducting a certain number of points for flaws that detract from the completeness, clarity, and convincing qualities of your specification (the words in caps are the shorthand we'll use in final grading):

Problem
-0.5 points	LOGIC	Illogical claim.
-0.5 points	SUPPORT	Unsubstantiated claim. Cite research, critique a design critique, or describe user research.
-0.5 points	PRIOR	Overlooked existing solution to problem.
Solution
-0.5 points	DETAIL	Missing detail that engineer would have to design.
-0.5 points	AMBIGUITY	Ambiguous design detail.
-0.5 points	REASON	Missing or unconvincing rationale for a design detail.
Limitations
-0.5 points	LIMITATION	Missing limitation in design.
Presentation
-0.25 points	ORGANIZATION	Content that can't be understood without reading later parts of the document.
-0.25 points	CLUTTER	Visual design clutter in mockup.
-0.25 points	TYPO	Spelling or grammar issues.
-0.25 points	REDUNDANT	Repetitive content.
-0.25 points	LAYOUT	Cluttered document formatting.
-0.25 points	FORMAT	Violation of a formatting rule.

This will be a team grade. I expect your effort to be comparable, but your contributions to be complementary. If for some reason you feel that it should not be a team grade—because efforts were not comparable—you can write me a statement of 500 words or fewer providing background on why a team grade would not be fair. This statement is due at the same time as the specification and should be sent to me via email. If you submit such a statement, I will immediately reach out to your teammate for their response to your statement, to make sure that the grades we do assign accurately reflect contributions.

Feedback

Any design process, including the design of a document, requires feedback to achieve excellence. There are three ways you can get feedback on your design specification:

From peers in class. Built in to the course are several opportunities to get feedback from your classmates.
From me and the TA during class. Ask me or the TA for feedback during open work time in class. There will be many times where you're working closely with your team during class time; find us, ask for feedback, and we'll provide it on the spot.
From your reader via Google Docs. We'll assign either me or the TA as your reader. You can ask for feedback once from one of us before the deadline. To request feedback, email a link to your specification Google Doc with commenting enabled to either me or the TA and we'll will read the section you requested, providing detailed critique of the content. We'll do this within 24 business hours (counted as 9-5, Monday through Friday, excluding university holidays) of receiving the request to ensure you have time to revise your draft and get more feedback. Because of holidays and weekends, plan your requests carefully.

Website

We want you to create a presentation of your ideas. This should look professional and be something you would consider including in a design portfolio. What should it have?

2 points	Basics	Logo, Title, Proposition
4 points	Content	Problem, Features, Design process insights, Link to report
4 points	Presentation	Looks great, nice images, minimal and appropriate text

Some nice examples (these are from a quarter long project):

Video (Optional)

Video prototypes use the magic of editing to help someone else understand the problem you are solving and see how your solution would solve it.

ALERT: If your solution do not allow for an interactive prototype (like, you are building voice-based interactions or an non-digital solution, you will have to produce a video to present the solution in action.

The video should not be more than 3 minutes long, and has do be uploaded to YouTube (or your favorite video platform). It should preferably be publicly accessible, but can be password protected if you're shy! =)

Here are several examples of solid video prototypes that clearly convey a problem and solution through a concrete narrative. Note that none of these are framed as advertisements or product walkthroughs. They all focus on a person's problem and how the design helped them address their problem:

We'll grade your team's video as follows:

2 points	Problem clarity	2 points for a problem that is concretely illustrated 1 point for a problem that is abstractly illustrated 0 points for a problem that is not illustrated at all
2 points	Motive realism	2 points for character actions with entirely plausible motives 1 point for some actions with unclear motivation 0 points for character actions that were almost entirely unrealistic
2 points	Solution clarity	2 points for no ambiguity about how the solution addresses the problem 1 point for some clarity about how the solution helps, but some ambiguities 0 points for solution that has no apparent relationship to the problem.
2 points	Seamless A/V	2 points for flawless A/V that supported communication 1 point for some A/V issues that disengaged the viewer 0 points for a video so full of A/V issues it was hard to focus on the story.
2 points	Length	0 points for videos over 3 minutes in length.

This will be a team grade. I expect your effort to be comparable, but your contributions to be complementary. If for some reason you feel that it should not be a team grade—because efforts were not comparable—you can write me a statement of <500 words or fewer providing background on why a team grade would not be fair. This statement is due at the same time as the video and should be sent to me via email. If you submit such a statement, I will immediately reach out to your teammate for their response to your statement, to make sure that the grades we do assign accurately reflect contributions.