Design Thinking Slides
Teacher Script & Guidance
Welcome, students. Today we begin our journey into design thinking, specifically focusing on the first two phases: Empathize and Define.
In computer science, writing code is only half the battle. The most important step is understanding the human beings who will actually use your software.
This session will show you how to build solutions that solve real human needs, which is a critical skill for your Create Performance Task.
Essential Question
How does taking the time to understand the real experiences of people change the way a problem is defined, and why does that shift matter before any solution is proposed?
Keep this question in mind throughout today’s exploration.
Teacher Script & Guidance
This is our essential question for the day. Let’s break it down before we jump into any definitions.
Why do you think software developers often jump straight to writing code before fully understanding the user?
We are going to explore why rushing to a solution without proper definition leads to failure, and how empathy acts as a framework for success.
Learning Objectives
By the end of this session, you will be able to:
- • Explain the purpose of the Empathize and Define stages in the design thinking process.
- • Gather simple observations about a user’s experience and turn them into a concise, human-centered problem definition.
- • Value the practice of understanding people before inventing solutions, recognizing that a well-framed problem produces better results.
Teacher Script & Guidance
These are the three main goals we want to achieve today. We are looking at both theory and application.
First, we will understand why these stages exist. Second, you will practice gathering data from observations and turning it into a problem statement.
Finally, we want to build a design mindset where we naturally value the user’s real-world constraints.
AP CSP Connection
Why this matters for your AP exam
Big Idea 1: Creative Development
Computing innovations are built by people to solve human problems. A structured, iterative design process is essential.
Create Performance Task Requirement
You must describe the purpose of your program, the problem it addresses, and how it aligns with your target user’s interest.
Teacher Script & Guidance
Let’s connect this topic directly to the College Board curriculum.
The AP Computer Science Principles framework emphasizes Creative Development. This means you do not code in a vacuum.
When you complete your Create Performance Task, you are graded on your ability to explain who your program is for and how it solves their specific problem.
Core Methodology
What is design thinking?
A non-linear, human-centered framework used to understand users, challenge assumptions, redefine problems, and create innovative digital solutions.
1. Empathize
2. Define
3. Ideate
4. Prototype
5. Test
Teacher Script & Guidance
Design thinking is a framework pioneered by Stanford University and used by major technology firms like Google, Apple, and Microsoft.
It consists of five phases. Today, we are focusing on the first two phases: Empathize and Define.
Notice that this is a non-linear process. You will often jump back and forth between these steps as you gather more information.
Process Comparison
How do we build software?
Traditional approach
Developers assume they know the problem, jump straight to writing code, release the software, and discover that nobody wants to use it.
Design thinking approach
Developers start by researching the user, defining the core human struggle, prototyping, testing, and writing code that solves real needs.
Teacher Script & Guidance
Let’s compare these two models. In the traditional approach, developers focus on the technology first. They think: “What language should I use? How fast can I code this?”
In the design thinking approach, we focus on the human first. We think: “Who is struggling? What is their barrier? How can technology remove this barrier?”
This prevents wasting time and resources building software that fails in the real market.
Phase 1
The goal of the Empathize stage
To build a deep, personal understanding of the people you are designing for. You must set aside your own assumptions and look at the world through their eyes.
The primary rule of empathy
You are not your target user. Your experiences, technical abilities, and expectations are different from theirs.
Teacher Script & Guidance
The Empathize stage is all about gathering qualitative data. It requires setting aside your ego and assumptions.
As young software creators, you might be comfortable navigating complex database structures or advanced keyboard layouts. Your users might not be.
If you build an app assuming your user knows command-line arguments, your app will fail. You must observe them directly.
Course Context
Empathy in computational solutions
Computing innovations must account for diversity in access, background, and capability. Skipping empathy leads to biased, inaccessible, or harmful technology.
- • Accessibility for users with visual, auditory, or motor impairments.
- • Inclusion of populations with low internet bandwidth or older devices.
- • Respecting privacy and data security boundaries.
Teacher Script & Guidance
In AP CSP, we look at the societal impacts of computing. Empathy directly influences equity in computer science.
If we do not design with empathy, we end up creating software that excludes people. For example, video tools without captions exclude deaf individuals.
When you start designing your algorithms, you must consider these accessibility factors. This is what separates an amateur coder from an elite software engineer.
Failure Analysis
Real-world case study: the portal disaster
A major healthcare portal spent millions developing an online scheduling system. On launch day, elderly patients flooded customer support lines with phone calls because they could not use the interface.
What went wrong?
The development team did not observe senior citizens in their homes. They assumed everyone had high-definition monitors, steady hand coordination, and modern web browsers.
Teacher Script & Guidance
Let’s analyze a classic real-world case of empathy failure. A healthcare organization wanted to modernize and reduce phone traffic, so they built a web portal.
But they did not watch senior citizens try to navigate their screens. When seniors sat down, the tiny buttons and multiple multi-step navigation paths proved impossible.
The system was a failure because the developers did not build empathy with their actual users first.
Analogy
A doctor before prescribing medicine
What happens if a doctor hands you a prescription the moment you walk through the door, without asking any questions or running tests?
The software developer’s equivalent
Writing code before performing user research is identical to prescribing medicine without a diagnosis. You are guessing, and it can be dangerous.
Teacher Script & Guidance
To understand the danger of skipping empathy, think of this doctor analogy. You would never trust a medical doctor who gives you a pill before listening to your heart rate or asking about your symptoms.
Yet, in computer science, software engineers write thousands of lines of code based on a complete guess.
Always listen, observe, and run user diagnostic tests before you decide what code to compile.
Practical Methods
Three ways to build empathy
1. Observe
Watch users perform tasks in their real context. Notice physical workarounds, friction points, and hesitation.
2. Engage
Interview them using open-ended questions. Seek stories of struggle rather than simple yes or no answers.
3. Immerse
Place yourself in their position. Experience their environment and limitations physically and mentally.
Teacher Script & Guidance
These are the three tools of design empathy: Observation, Engagement, and Immersion.
Observation is purely visual. You stand back and watch without interfering.
Engagement involves conversation. We ask open questions. Immersion means doing the job ourselves to feel the raw friction. Combined, they give us a rich foundation of user insights.
Skill Development
How to observe without bias
- • Document physical actions rather than making immediate assumptions.
- • Look for temporary quick fixes or workarounds, like sticky notes on a screen.
- • Note physical reactions such as deep sighs, long pauses, or furrowed brows.
Teacher Script & Guidance
To be an effective observer, you must record what actually happens, not what you think it means.
Instead of writing “the user is bad at computers”, write “the user clicked the wrong button three times before locating the menu link.”
Also, look for sticky notes on monitors. That is a visual workaround indicating a direct user experience issue that software can fix.
Skill Development
How to ask open-ended questions
Avoid leading or closed questions
“Do you like this new software?” or “Is the interface fast enough?”
Use narrative-seeking questions
“Tell me about the last time you tried to schedule an appointment online. What happened?”
Teacher Script & Guidance
During user interviews, avoid questions that lead the user to a specific answer. Closed questions like “Is this app good?” yield a simple “Yes”, which tells us nothing.
Instead, ask for stories. Narrative questions like “Tell me about your experience…” prompt them to describe their real-world journey.
This reveals where they got lost, got angry, or gave up entirely.
Synthesis Tool
The Empathy Map
A visual template used to organize qualitative observations into four core aspects of the human experience.
SAY
DO
THINK
FEEL
Teacher Script & Guidance
An Empathize session yields massive amounts of raw text, interview notes, and observations. How do we make sense of it?
We use a structured tool called an Empathy Map.
We split our raw notes into four distinct quadrants: what the user says, what the user does, what they are likely thinking, and what they are feeling.
Synthesis Details
Empathy Map: external observations
The SAY quadrant
Direct quotes and key phrases spoken by the user during the process.
“I wish this screen did not reload every single time I select an option.”
The DO quadrant
Concrete physical behaviors, adjustments, or navigations you observed.
Clicks the submit button five times in frustration while waiting.
Teacher Script & Guidance
Let’s detail the first two quadrants, which are external and directly observable.
Say is literal. You write down direct quotes from the user, even if they seem minor. Do is visual. You write down the user’s physical actions.
Notice that these two quadrants are objective. They represent verified facts from your observation session.
Synthesis Details
Empathy Map: internal assumptions
The THINK quadrant
What you infer the user is thinking but might not say out loud.
“Am I doing something wrong? Is this program broken or is it just me?”
The FEEL quadrant
The emotional state of the user, derived from body language and tone.
Anxious, overwhelmed, frustrated, or alienated by complex terminology.
Teacher Script & Guidance
The next two quadrants are internal and require careful synthesis.
Think is your intellectual inference. Based on their hesitation, what is running through their mind? Are they worried about breaking the application?
Feel is the emotional mapping. Emotions drive technology usage. If an app makes a user feel insecure, they will stop using it entirely.
Micro-Activity
Analyze the student homework struggle
A high school student sits down to submit an assignment. The portal loads slowly. The submission button is buried deep under three sub-menus.
Your challenge
On a piece of paper, write down one insight for each quadrant of an empathy map for this student.
Teacher Script & Guidance
Let’s pause and do a fast, interactive exercise. Read the scenario about the student trying to submit their homework assignment.
I want you to write down one observation for each quadrant: Say, Do, Think, Feel.
I will give you a moment to write. Then, I will call on a few of you to share what you have mapped out.
Peer Collaboration
How to share observations
- • Compare your quadrant items with a classmate’s list.
- • Highlight any differences in your interpretations of what the user was feeling.
- • Group similar observations together to establish patterns.
Teacher Script & Guidance
Turn to the peer sitting next to you. Share the quadrants you just drafted.
Pay close attention to where your lists differ. Did you notice a different physical behavior? Did your partner infer a different emotion?
This discussion helps eliminate individual developer bias and ensures a more complete visual understanding of the user.
The Bridge
From raw notes to clear problems
The Empathize stage generates unstructured insights. The Define stage synthesizes those observations into a single, cohesive problem statement.
“If I had an hour to solve a problem, I’d spend fifty-five minutes thinking about the problem and five minutes thinking about solutions.”
Albert Einstein
Teacher Script & Guidance
Now we are transitioning from Phase 1 to Phase 2 of design thinking.
Empathy gives us divergent raw data. Definition forces us to converge on a single focus.
This Einstein quote perfectly illustrates our mindset: framing the problem correctly is the most important part of any computer science project.
Phase 2
The goal of the Define stage
To formulate a clear, actionable problem statement based on user insights. This statement serves as the north star for the entire development team.
The core goal
To keep the human need at the center of the solution. Every line of code written later must directly support this statement.
Teacher Script & Guidance
What is the Define stage? It is where we analyze our empathy map, locate the intersections, and write our problem statement.
This statement must be human-centered. It cannot mention computer languages, databases, or API protocols yet.
It must serve as the absolute guide for your developmental sprints.
Statement Anatomy
What makes a statement strong?
1. Actionable
It gives the development team clear parameters to explore creative solutions.
2. Concise
It is short, memorable, and easily understood by non-technical stakeholders.
3. Human
It focuses on the specific user’s core struggle, not a business or technical goal.
Teacher Script & Guidance
A high-quality problem statement has three defining qualities.
First, it must be actionable. It should inspire a brainstorming session. If it is too narrow, it stifles innovation.
Second, it must be concise. You should be able to state it in a single sentence. Third, it must be framed around human struggle, not mechanical efficiency.
Analysis
The danger of vague problems
Too vague statement
“The school portals have a bad design and need updates.”
Actionable, human statement
“High school students need an aggregated view of assignments because navigating multiple portals causes anxiety and leads to missed deadlines.”
Teacher Script & Guidance
Let’s look at the difference between a weak statement and a strong one.
The vague statement “The portals need updates” is useless. It does not explain who is struggling, why they are struggling, or what emotion is triggered.
The second statement identifies the user (high school students), the need (aggregated view), and the insight/emotion (navigating multiple portals causes anxiety).
Analysis
The solution-first trap
A common mistake is including the technology in the problem statement itself.
Incorrect statement (solution-first)
“We need to build a mobile Python application with SQL databases to schedule class meetings.”
Why is this bad? It shuts down alternative, potentially better methods before brainstorming even begins.
Teacher Script & Guidance
This is the solution-first trap. As computer science students, you love technology, so you naturally want to insert your favorite programming language or tool into the problem statement.
By saying “we need a Python app with SQL”, you have decided on the framework before confirming if a mobile app is even accessible to your users.
Never lock yourself into a solution prematurely.
Synthesis Tool
The Point of View (POV) formula
To build a strong, human-centered definition, we combine our empathy research into a strict architectural framework.
[User] needs [Need] because [Insight]
Teacher Script & Guidance
This is the Point of View formula, commonly called the POV formula. It is a critical design tool.
It acts as a literal equation for our problem statement: User, Need, and Insight.
By filling out these three brackets, we guarantee that our software project remains human-centered. Let’s look at how to define each bracket.
Framework Mechanics
The variables of the POV equation
USER: A specific person or demographic with unique characteristics. Avoid broad terms like “people”.
NEED: A human requirement expressed as a verb. It should never be a physical object or technology.
INSIGHT: A deep, non-obvious realization discovered during empathy research. The underlying “why”.
Teacher Script & Guidance
Let’s analyze these variables. The User must be highly specific, like “freshman students adjustment to high school.”
The Need must be a verb. Write “needs to collaborate” instead of “needs a chat tool.”
The Insight is the hardest part. It is the core discovery. It explains why the struggle exists and often references human psychology or structural friction.
Case Study 1
Example 1: student task management
User: A high school freshman managing multiple course schedules.
Need: To organize daily deliverables without feeling overwhelmed.
Insight: Academic anxiety increases when deadlines are distributed across disjointed software platforms.
Teacher Script & Guidance
Let’s walk through a concrete example. Imagine we interviewed high school freshmen.
We found that they struggle with their schedules. Our User is a high school freshman. Their Need is to organize daily tasks.
The Insight we discovered is that their stress is not caused by the quantity of work, but rather by the friction of checking five different portals every afternoon.
Case Study 1 Synthesis
Formulating the finalized POV 1
By combining these elements, we build a single, targeted statement:
“A high school freshman needs to organize daily deliverables in a centralized dashboard because checking fragmented portals causes academic anxiety and missed deadlines.”
Teacher Script & Guidance
This is the finalized POV statement. Read it carefully. Notice that it does not say “the student needs a Python website with a calendar widget.”
Instead, it states the user need: to organize. And it defines the core human struggle: checking fragmented portals causes anxiety.
Now, our design team can brainstorm multiple creative paths to solve this central tension.
Case Study 2
Example 2: digital medical access
User: An elderly patient managing medical scheduling independently.
Need: To coordinate monthly health checkups with confidence.
Insight: Complex navigational hierarchies and small interface layouts trigger sensory overload, forcing them to abandon digital pathways entirely.
Teacher Script & Guidance
Let’s look at our second example, which centers on digital equity and accessibility. We observed elderly patients.
The User is an elderly patient. Their Need is to coordinate medical appointments.
Our Insight is that multi-level menus and small screen components cause visual fatigue, making them give up. This means our software must prioritize simplicity and readability.
Case Study 2 Synthesis
Formulating the finalized POV 2
Combining these variables results in a direct development guide:
“An elderly patient needs to coordinate monthly health checkups in a highly legible interface because complex navigational menus trigger visual exhaustion and abandonments.”
Teacher Script & Guidance
By compiling our elderly research into this POV statement, we have a clear, non-technical blueprint.
Any developer looking at this knows they must avoid multi-step nested links, tiny fonts, and flashing alerts.
The user’s emotional friction, visual fatigue, is now our primary technical design boundary.
Transitioning to Ideation
What are How-Might-We questions?
Short questions that launch the next phase of design thinking by translating our Point of View statement into open opportunities for development.
The design bridge
They frame the problem as an exciting coding challenge, without restricting the physical structure of our future algorithm.
Teacher Script & Guidance
Once you have your Point of View statement, you need to transition into the next stage: Ideate.
We do this using a structured format called How-Might-We questions, or HMW.
These are short questions that start with the words “How might we…” and directly address the user need and insight.
Scoping Practice
Scoping your HMW questions
Too broad (unfocused)
“How might we make academic software better for high school students?”
Too narrow (pre-solved)
“How might we build a Python dashboard with green submit buttons?”
Balanced (optimal for ideation)
“How might we display academic deadlines in a single, stress-free location?”
Teacher Script & Guidance
Writing a great HMW question requires balance.
If the question is too broad, like “how do we make software better”, the team will not know where to start.
If it is too narrow, like “how do we write Python dashboard code”, you have already decided on the solution, killing all creativity. Aim for the sweet spot in the emerald box.
Create Task Strategy
Writing your AP written responses
During your AP Create Performance Task, you are graded on how clearly you describe the purpose of your software.
The grading secret
A program that solves a specific user’s need is infinitely easier to explain and document than an abstract block of code built with no user target.
Teacher Script & Guidance
Let’s talk strategy for your AP Create Performance Task. Students often fail to get full credit on the written response because their program’s purpose is vague.
By starting with empathy and definition, you can write: “My program’s purpose is to allow visually impaired students to input assignments audibly, addressing sensory barriers.”
This is crystal clear and guarantees points on the AP rubric.
Practice 1
Computational solution design
A successful developer translates human needs into physical input and output specifications before coding.
User specifications
“I need to record my daily blood sugar easily.”
Code specifications
Input: integer value via text field. Output: array update.
Teacher Script & Guidance
Computational solution design is about taking natural language user needs and translating them into computer variables, inputs, and outputs.
If a user says they want to track blood sugar, you translate that into an integer variable input, an append operation to a list, and a conditional filter.
Design thinking bridges the gap between natural human thoughts and systematic computer execution.
Glossary
Core terminology: Part 1
Empathy
The active effort to understand, share, and experience another person’s struggles and context.
User Persona
A realistic, data-driven profile representing your target user’s habits, skills, and goals.
Pain Point
A specific frustration or obstacle experienced by a user during their journey.
Teacher Script & Guidance
Let’s review the key technical terminology you must know. Please make sure you write these definitions down in your notes.
These terms are standard in the software industry.
Empathy is the core mindset. User Persona is a profile we build. Pain points are the exact visual or structural errors we discover during observation.
Glossary
Core terminology: Part 2
Point of View (POV)
An actionable framing of the user, their verb-based need, and the deep emotional insight.
Human-Centered Design
A framework that prioritizes the user’s cognitive, social, and emotional constraints throughout development.
Problem Statement
A clear statement naming the user, need, and insight, guiding developers during ideation.
Teacher Script & Guidance
These are the remaining terms for our glossary. Point of View is the formula we studied.
Human-Centered Design is the broad philosophy that covers all of these design frameworks.
And the Problem Statement is the concrete result of the Define phase. Make sure these are written down and understood as they will appear in your assessments.
Workshop Launch
Activity: Daily frustration redesign
You will work in pairs to select a daily user frustration, perform simple peer interviews, and draft a finalized Point of View statement.
Step 1: Empathize
Step 2: Define
Step 3: Share
Teacher Script & Guidance
It’s time to apply what we have learned. We are launching our practical workshop.
You will work with a partner. You are going to choose a daily frustration that you both experience at school or home.
You will run through the interview phase, synthesize your raw notes, write your POV statement, and share it with the class for feedback.
Workshop Step 1
Interview your partner
Take turns interviewing each other about your chosen daily frustration.
- • Ask open-ended questions like: “Explain what happened the last time you...”
- • Document what they say and do. Look for physical tells like sighing or tapping.
- • Do not suggest solutions. Listen to their struggle exclusively.
Teacher Script & Guidance
Let’s start Step 1. Find your partner and decide who is the interviewer first.
Interviewer: your job is to ask questions. Remember our rules: no leading questions. Ask them to tell you a story about their last struggle with the frustration.
Listen carefully, take raw notes, and do not mention any technology ideas. This is about their experience.
Workshop Step 2
Synthesize and draft the POV
Now, analyze your partner’s interview responses and map them out. Combine your findings into the Point of View architecture.
User: [Who is struggling specifically?]
Need: [What is their verb-based requirement?]
Insight: [Why is this a struggle? Underline the emotion.]
Teacher Script & Guidance
Now, switch roles if you haven’t already so both partners are interviewed.
Once both interviews are complete, work together to synthesize your raw notes.
Take those observations and fit them into our Point of View brackets. Make sure your User is highly specific and your Need is a strong verb. Write down your finished POV sentence.
Peer Evaluation
Evaluate your partner’s statement
Exchange your drafted statement with another pair. Grade their statement using this rubric:
1. User Specificity
Is the target demographic specific and clear, avoiding general terms?
2. Verb-Based Need
Is the need written as a verb, free from any physical technology solutions?
3. Emotional Insight
Does the insight explain the psychological why behind the user struggle?
Teacher Script & Guidance
Exchange your finished Point of View statement with the pair sitting behind you. You are going to evaluate their work.
Use these three simple checks. Is their user specific? Is their need a verb?
Did they fall into the solution trap by mentioning apps, coding languages, or systems? If they did, give them constructive feedback to revise it.
Reflection & Assignment
Homework and metacognition
Answer the following questions in writing:
1. Why does beginning with empathy reveal needs that a quick brainstorm misses, and what risks appear when the Empathize stage is skipped?
2. How does a well-crafted problem statement guide later developer decisions, and what happens when the problem remains vague or too broad?
Metacognitive Paragraph:
Write a paragraph describing which part of the Empathize or Define process felt most useful, which was challenging, and how this focus will influence your AP Create Performance Task design.
Teacher Script & Guidance
We have reached the end of our session. To solidify our learning, you have a written homework assignment.
Answer the two analytical questions on the screen. Be thorough. Your explanations should reflect our discussions on developer bias, user accessibility, and POV formulas.
Additionally, write a brief metacognitive paragraph. This is about your own design habits. Reflect honestly on what was easy and what was difficult about empathy research.
