INFO 360 Design Thinking

Schedule • Grading • Activities • Reading • Midterm • Project

In this class I'll teach you how to think like a designer. You'll learn what designers do, how they do it, and how to do some of the things they do. We'll focus on the design of user interfaces and information systems. By the end of the course you won't be a great designer, but you'll learn what you need to practice to become a great designer. This will empower you to learn more about design by engaging more deeply in the Puget Sound UX design community.

The structure of this course is simple:

I teach you about design for 5 weeks through a series of readings and in-class practice.
A midterm to see how much you learned.
With a teammate, you design something useful for one of your classmates.
With a teammate, you write a design specification that details your design thoroughly.
With a teammate, you create a video prototype that communicates your design persuasively.

Sound good? Let's get started!

Office Hours

I'm available to talk about jobs, careers, graduate school, research, class, and anything else. My office hours this quarter are Wednesdays 3:30-4:30, right after class, though occasionally I need to schedule things over it. To guarantee I'll be around, write me in advance to secure a time.

Devices in Class

We will use smartphones and laptops throughout the quarter to facilitate activities and project work in-class. However, research and student feedback clearly shows that using devices on non-class related activities not only harms your own learning, but other students' learning as well. Therefore, I only allow device usage during activities that require devices. At all other times, you should not be using your device. I'll help you remember this by announcing when to bring devices out and when to put them away.

Schedule

Week 1 — Introductions
1/3	Lecture	Who am I? (10 min) How I will teach you? (5 min) Growth mindset Deliberate practice My role and TA's role in providing constructive feedback Your role in seeking feedback What is it like to design? (20 min) Read syllabus, syllabus Q&A (10 min) Emergency preparedness (5 min)
Week 2 — Design
1/8	Lecture	Reading (30 min): What designers do Activity (45 min): What do you want to do?
1/9	Lab	Activity (50 min): Empathy
1/10	Lecture	Reading (30 min): How to design Activity (70 min): Compare two paradigms
Week 3 — User Research
1/15	Lecture	NO CLASS, Martin Luther King Jr. Day
1/16	Lab	Reading (10 min): How to understand problems Activity (40 min): Contextual inquiries
1/17	Lecture	Reading (30 min): How to define problems Activity (80 min): Define a problem
Week 4 — Ideation and Prototyping
1/22	Lecture	Reading (30 min): How to be creative Activity (80 min): Creativity in context
1/23	Lab	Activity (50 min): Brainstorming
1/24	Lecture	Reading (30 min): How to prototype Activity (80 min): Sketching
Week 5 — User Interfaces and Critique
1/29	Lecture	Reading (30 min): How to design user interfaces Activity (80 min): Paper prototypes
1/30	Lab	Activity (50 min): Digital prototypes
1/31	Lecture	Reading (30 min): How to be critical Activity (80 min): Critique
Week 6 — Evaluation
2/5	Lecture	Andy's in Germany at a Dagstuhl workshop (Abdulla teaches) Reading (30 min): How to evaluate empirically Activity (80 min): Design and test an alarm clock
2/6	Lab	Andy's in Germany at a Dagstuhl workshop (Abdulla teaches) Activity (50 min): Heuristic evaluation
2/7	Lecture	Andy's in Germany at a Dagstuhl workshop (Abdulla teaches) Reading (30 min): How to evaluate analytically Activity (45 min): Walkthroughs
Week 7 — Define your Problem
2/12	Lecture	Midterm (45 min): Did you learn everything from the last 5 weeks? Discuss (20 min): Project requirements Teams (5 min): Pair up! Activity (40 min): Plan research
2/13	Lab	Activity (45 min): Research Credit (5 min): Sign in for credit
2/14	Lecture	Due: Problem definition draft Activity (110 min): Critique problems, ideate solutions
Week 8 — Build Your Low-Fidelity Prototype
2/19	Lecture	NO CLASS, President's Day
2/20	Lab	Due: Two low-fidelity prototypes Activity (110 min): Prototype critique and iteration
2/21	Lecture	Andy's at the SIGCSE 2018 conference in Baltimore (Abdulla teaches) Due: One low-fidelity prototype Activity (110 min): Prototype critique and iteration
Week 9 — Build Your High-Fidelity Prototype
2/26	Lecture	Due: High-fidelity prototype Activity (110 min): Evaluate and plan Select a method: interviews, usability test, heuristic evaluation, GenderMag walkthrough, or any other appropriate method Gather evidence
2/27	Lab	Activity (50 min): Brainstorm limitations
2/28	Lecture	Activity (110 min): Video storyboarding
Week 10 — Make Your Video Prototype
3/5	Lecture	Course evaluation reminder Activity (110 min): Video and specification workshop
3/6	Lab	Activity (50 min): Video and specification workshop
3/7	Lecture	Q&A about deliverables (10 min) Lecture and activity (50 min): Design and your future Activity (50 min): Video and specification workshop
Finals week
3/13, time 6 pm		Video prototype due (upload here with team # from Canvas) Design specification due (upload to Canvas)
3/15, time 6 pm		Video prototype evaluations due (fill out survey)

Grading

There are 100 points you can earn in this class:

Activities (30 points, 1 point each). Engage to get credit.
Reading (20 points, 2 points each). Prove you read and understood the reading.
Midterm (20 points). Prove you know and can do everything in the first 5 weeks of the class.
Design specification (20 points, team score). Prove you can design something that solves a problem.
Video prototype (10 points, team score). Prove you can persuade someone that you solved a problem.

After mathematically rounding your points to the nearest point, I'll map your points to a 4.0 scale using the table below.

≥95	4.0	≥88	3.3	≥81	2.6	≥74	1.9	≥67	1.2
≥94	3.9	≥87	3.2	≥80	2.5	≥73	1.8	≥66	1.1
≥93	3.8	≥86	3.1	≥79	2.4	≥72	1.7	≥65	1.0
≥92	3.7	≥85	3.0	≥78	2.3	≥71	1.6	≥64	0.9
≥91	3.6	≥84	2.9	≥77	2.2	≥70	1.5	≥63	0.8
≥90	3.5	≥83	2.8	≥76	2.1	≥69	1.4	≥62	0.7
≥89	3.4	≥82	2.7	≥75	2.0	≥68	1.3	≤61	0.0

Note that 70% of your grade is individual and 30% is team. If you do perfectly on the individual parts of the class and contribute nothing to the project, you can't pass the class. So be a good design partner!

Late work receives no credit. There are some exceptions:

If you can provide a note from a health care professional documenting the reason for your absence, I may accept late submissions (but not for activities, since those can't be reproduced).
You can miss up to 3 activities without penalty and without documentation. This should be enough to allow for sickness, unavoidable travel, or other personal matters.
If you miss a reading quiz, you can make up the quiz credit by sending a critique of the reading to me within a week of the due date that reports at least three improvements to the content, including high level issues such as topics that should be discussed or points you think are wrong, to low level issues including spelling, grammar, or clarity.

Activities

Each day in class we'll practice some skill. You'll get 1 point if you engage in and complete the activity. How to get credit for the activity will depend on the activity; sometimes being present will be enough, sometimes being to class on time will be enough, and sometimes you'll have to turn something in. Because there aren't exactly 30 class periods in class, the total number of points you receive will be scaled to 30 points as follows: (30 x (# activity points earned) / (# of activity points possible)).

Reading

Readings are due twice a week, and each time, involve reading two things: 1) the chapter I wrote and 2) something related to the chapter I wrote, selected from links in my chapter, or from anything else in the world (but you have to find it).

The day that each reading is due, we'll do the following:

Anonymously share what you're confused about.
I clarify confusions.
I give you a question to answer individually about the assigned reading.
You spend 5 minutes writing a polished answer, using only the knowledge in your head.
You turn in your answer.
You discuss your answer with your neighbor.
We discuss the correct answer as a class.

If your answer is correct, you'll receive 1 point. I will give partial credit for partially correct answers, at my discretion.

Your selected reading assignment is your choice. Before class, read one of the articles linked in the reading or choosing something design-related book, blog post, magazine article, newspaper article, or online video that that is relevant to the topic of the chapter. If you choose a book, it's okay to just read the first chapter of the book. For your additional 1 point of reading credit, submit to Canvas a summary of no more than 500 words that:

Summarizes the point of the article.
Describes the thing you found most interesting about the article.
Includes a citation to what you read.

In class, after we discuss the assigned reading, we will:

Break into groups of four
Discuss your selected readings as a group, identifying one insight from the readings that connect with the topic of the day to share with the class
Elect someone to share the insights with the class.
We'll hear from 3-4 groups about their most interesting insight.

Midterm

The midterm will be the same exam that I gave you on the first day of class. It will cover every topic in the assigned readings and every skill practiced in class. The midterm score will not be curved or scaled; however, any questions that more than 80% of students in the class get wrong will be excluded from the final score as they were likely confusing or concerned material that I poorly taught.

The purpose of the midterm is to find out what you know, not to penalize you for not knowing something. To this end, for every question you get wrong on the midterm, you can earn half the credit you lost by submitting to Canvas, for each problem:

The question
Your answer
How many points you lost on the answer
Why your answer was wrong

If your explanation is correct, you'll receive half of your points back. You'll submit these on Canvas no later than 2 weeks after the midterm.

Project

When choosing a problem to solve, it's temping 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 a video prototype.
Evaluate the solution your classmates designed for you.

This process has elements of human-centered design (in that it studies problems to inform design).

What counts as good design? Anything that actually addresses the problem your classmate has is acceptable. As I've noted, I think good design is relative to values, so make your values explicit, perhaps adopting the values that your classmate expresses about what would make a good design to them.

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 the following tools, which are based on decades of HCI research on rapid prototyping:

OmniGraffle or other diagramming tools to create medium-fidelity screens.
Prott or other similar tools for high-fidelity web, iOS, or Android designs
InVision for its strong collaboration and workflow support
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 time 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.

Video

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.

The video you upload must be:

An MP4 file (to ensure we can play it).
No longer than 3 minutes in length (to respect everyone's time).
no higher than 480p resolution (to respect poor Canvas).

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.

To inform the grade we choose, you'll fill out a peer evaluation survey, evaluating each of the videos submitted to class (including your own!). If you don't fill out the survey, you'll get 0 points for your video score. You'll have 48 hours after the video submission deadline to view and evaluate your classmates videos.

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.