Let's start at the beginning. What was OrCam Learn for School, and what were you asked to design?

I pushed for user research, and I had to fight for it. Twenty-five hundred dollars. That sounds trivial, but in a small startup, asking for budget to validate something everyone assumed they already understood was a hard sell.

The pushback was essentially: we know our users, why are we paying to confirm it.Then I made a decision I think mattered more than the budget itself. I refused to run the research on Figma mockups. Static screens tell you what people think they'll do. They don't tell you what people actually do. So I spent two weeks building a working prototype in Lovable — real data, real interactions, the whole thing clickable and live.

That distinction — between what people say and what people do — turned out to be the entire project. If I'd tested mockups, I'd have shown users a picture of the hierarchy and they'd have nodded and said yes, that makes sense, I'd click here.

And I'd have learned nothing. The prototype was the only thing that could have caught what happened next.I want to be honest that this wasn't pure methodological wisdom. Part of it was instinct, part of it was stubbornness. But it's the decision the whole story hinges on. You don't get the four-second moment if you're showing someone a screenshot.

When did you start to suspect the assumption was off?

It started when I actually examined what the device was measuring. The data was genuinely sophisticated — reading fluency, comprehension rates, where a child hesitated, what kind of text tripped them up. And the more I looked at it, the more I had this quiet feeling: this is clinical data.

This is the kind of thing that takes training to interpret.So I asked the question that should have been asked at the start. Not "how do we show this to parents" but "can parents actually use this?" And to answer it honestly, I needed to talk to the people on both sides — parents and teachers. The product manager and I set up interviews. I wrote the scripts and questions, he ran most of the sessions.

What came back reframed the whole project. Teachers lit up at the data. They had a professional framework for it — they knew what a fluency score meant, they could distinguish a child compensating from a child improving, they could turn a number into an intervention by next week. The data was oxygen to them.Parents had the opposite reaction.

The same numbers made them anxious. They didn't know what a comprehension score of 62 meant or what to do about it. The information didn't empower them — it made them feel like they were failing a test they didn't know how to study for.

So the dashboard you'd been building for parents was actually a teacher's tool. What did you do with that?

I stopped treating it as one dashboard with one audience and started treating it as two fundamentally different relationships to the same data. That reframe is the spine of the whole project. The teachers needed depth and granularity. The parents needed something else entirely — reassurance and direction, not raw analytics.

For the school product specifically, that meant I could finally design for the right user. A teacher isn't a passive recipient of data. She's a professional managing twenty or thirty students, already triaging in her head — who's urgent, who's hiding it, who needs me today. The dashboard had to match the way she already thinks, not impose a new structure on her.

That was liberating, because it freed me from designing for the lowest common denominator. I didn't have to dumb the data down for a parent who'd be overwhelmed by it. I could build a genuine professional instrument — dense where density helped, prioritized the way a teacher prioritizes.

The deeper lesson, which I only fully understood later, was that the same information presented to two different people is essentially two different pieces of information. The data that empowered the teacher was the data that paralyzed the parent. Identical numbers. Opposite effect.

You've said a teacher has almost no time. How did that shape the actual interface?

A teacher opens this dashboard at seven-thirty in the morning and has about ninety seconds before a student walks through the door. That constraint became my design brief more than anything in the original spec.

Every element on the screen was competing for attention that simply didn't exist.So the first question wasn't what to show — it was what to surface first. I built the hierarchy around urgency. Not which student scored lowest overall, but which student needed attention today. A ranked list of scores is data. A prioritized list of who-needs-you-now is a decision. I wanted the dashboard to deliver a decision.

There was a specific failure in testing that taught me a lot. I'd designed a single reading-comprehension graph that showed several variables over time. It made perfect sense to me, because I'd been staring at it for weeks. Teachers couldn't read it. They kept asking what the graph was telling them to do.

So I split it into two separate graphs, each carrying one clear signal — and I resisted adding any further charts that would demand new learning.I also noticed teachers would fixate on the first problem they saw and miss a second one sitting right beside it. So I arranged the problems in a hierarchy — the primary issue prominent with a general tip attached, secondary issues present but quieter. The order things appear in isn't neutral. The sequence itself tells the teacher what to do first.