What K-12 Outreach Taught Me About Product Design

While I was a STEM instructor for HKN, I taught Python and Scratch to K-12 students from underserved communities in San Diego. I thought I was just giving back and making STEM more accessible. What I didn't expect was how much it would transform the way I build software.

Turns out, teaching an 8-year-old to code and designing a user interface have a lot more in common than you'd think.

The Problem with Building in a Bubble

Before outreach, I explained topics in a way that made sense to me, and I assumed the students thought like me. I thought that my peers and I were on the same page. I'd code algorithms that made perfect sense to me, write documentation that seemed clear to me, and wonder why people struggled with code I thought was obvious.

I was oblivious to my own bubble. Then I stood in front of 30 middle schoolers trying to explain variables.

"So you put the number in the box..."

Blank stares.

"The container. You store it."

More confusion.

"Okay, imagine you have a backpack..."

Suddenly, everyone got it.

That moment changed how I think about coding, and eventually, design. If you can't explain it to a 12-year-old, your explanation is probably too complicated.

Lesson 1: Simplicity Opens Doors

One of the first things I learned was that complexity isn't impressive. Clarity is.

I watched a group of 5th graders build their first game in Scratch. Scratch is incredibly simple on the surface (drag-and-drop blocks, colorful sprites, immediate feedback), but students were creating complex games with loops, conditionals, and event handling without even realizing they were coding.

The interface didn't insult their intelligence. It removed friction so they could focus on the creative work.

The students who picked it up fastest weren't necessarily the "smartest" ones. They were the ones who felt safe experimenting because the barrier to entry was so low.

Lesson 2: Meet People Where They Are

During a field trip to UCSD, I showed students how engineers use Python for data analysis. I started by opening a terminal and typing commands.

Half the students had never seen a command line before.

I had to stop and rethink the entire demo. Instead of starting with "here's how professionals do it," I started with "let's look at some data together." I used Jupyter Notebooks with colorful graphs and interactive widgets. The content was the same, but the entry point was completely different.

You can't force people to adapt to your world. You have to meet them in theirs.

Lesson 3: Feedback Needs to Be Instant

Kids have zero patience for delayed feedback. If they write code and nothing happens for 10 seconds, they assume it's broken and move on.

Adults are the same way. We're just better at hiding our frustration.

During workshops, I learned to structure activities so students got immediate visual feedback. Change a number, see the sprite move. Add a loop, watch it repeat. Break something, see the error right away.

The faster the feedback loop, the more confident students became. They'd experiment, fail, adjust, and try again because they could see the results instantly.

When there's silence or delay, people assume something's broken.

Lesson 4: One Size Doesn't Fit All

Working with students from different backgrounds and learning styles forced me to present information in multiple ways.

Some students needed visual examples. Others needed hands-on practice. Some thrived with written instructions, while others needed me to walk them through it step by step.

The students who struggled the most weren't "bad at coding." The material just wasn't presented in a way that worked for them.

I learned to:

• Use multiple formats (text, visuals, hands-on examples)
• Make instructions clear and readable
• Provide multiple paths to the same outcome
• Never rely on a single method to convey information

When I stopped assuming everyone learned the same way I did, more students succeeded.

Lesson 5: The Goal Is Independence

By the end of each workshop, my goal wasn't for students to memorize syntax. It was for them to feel confident enough to keep learning on their own.

The best moments were when a student would figure something out, turn to their neighbor, and teach them. They'd rephrase my explanation in a way that made more sense to their friend. They'd discover shortcuts I hadn't shown them. They'd break things in creative ways and debug them together.

That's when I knew the workshop worked. Not when I taught them something, but when they felt empowered to explore and teach themselves.

The goal was never dependence on me as the instructor. It was independence.

How This Changed the Way I Build

It took me a while to realize these lessons weren't just about teaching. They were about communication, empathy, and understanding how people actually interact with unfamiliar systems.

Which is exactly what product design is.

When I started applying these lessons to building software, everything clicked:

Simplicity opens doors. The products I build now prioritize clarity over cleverness. A simple solution that everyone understands beats an elegant solution that confuses half your users. If it doesn't work for someone with zero context, it doesn't ship.

Meet users where they are. I stopped building for how I think users should behave and started building for how they actually behave. What mental models do they already have? What tools are they comfortable with? The product has to adapt to their reality, not the other way around.

Instant feedback builds confidence. Loading states, helpful error messages, microinteractions. These aren't nice-to-haves. When users feel like the product is responding to them, they trust it. When there's silence, they assume it's broken.

Design for different people. Accessibility isn't a feature. It's recognizing that people interact with technology in different ways. Color alone can't convey meaning. Text needs to be readable. Keyboard navigation matters. When you design for accessibility, you don't just help people with disabilities. You help everyone.

Create independence, not dependency. Can a new user accomplish something meaningful in the first 5 minutes? Do they feel confident enough to explore on their own? If they get stuck, can they figure out how to fix it without contacting support? The best products empower users to teach themselves.

These aren't just design principles. They're lessons in empathy.

The Unexpected Gift

I started doing outreach because I didn't want other students to feel the way I did when I first learned to code: intimidated, underprepared, and unsure if I belonged.

What I didn't expect was how much teaching would make me better at everything else.

When you teach someone with zero context, you're forced to see your work through fresh eyes. You can't hide behind jargon or assume prior knowledge. You have to make things simple, clear, and intuitive, or people just won't get it.

That's exactly what good product design requires.

The best way to learn how to build better products isn't to read more design books. It's to teach someone who knows nothing about what you're building and watch where they get stuck.

If you're a developer or designer, I challenge you to find an opportunity to teach. Volunteer at a coding workshop. Explain your project to a non-technical friend. Watch someone try to use your app for the first time without any guidance.

You'll learn more in an hour than you would in a month of building alone.