You've said you started this project conceptually, before touching any screens. What were you thinking about?

Before I designed anything, I sat with what this device actually does, philosophically. OrCam Learn lets a child hear text instead of decoding it themselves. And that raises a real tension that I didn't want to gloss over — the question of functional independence.
Any assistive technology carries this conflict: you're helping someone accomplish a task, but you might also be replacing the very skill you're supposed to be building.

I mapped the child's activity with the device into passive and active modes, and as I did, I realized there were three levels of learning happening: listening, reading, and understanding. Understanding was the real output — the thing that actually mattered. Listening and reading were the means. And understanding is what links passive consumption to active learning.

That mattered because it told me what the product's core value actually was. It wasn't "the device read a page." It was "did the child understand it, and are they building toward doing it themselves." Any design that celebrated mere usage — look how many pages were read aloud — would be measuring the wrong thing and possibly encouraging dependency.

So before I drew a single screen, I had a thesis about what success meant for this product. And it pointed away from raw performance numbers and toward something more like effort and growth. That conceptual groundwork is what made the later design decisions obvious instead of arbitrary.

Then came the research. What did parents tell you?

The product manager and I interviewed parents of children with ADHD and dyslexia, and I also talked to teachers to understand the contrast. I wrote the scripts and questions; the PM ran most of the sessions. And the findings were strikingly consistent — almost uncomfortably so, because they contradicted the data-rich direction we'd assumed.

Parents wanted three things. Is my child actually using the device? Is there improvement compared to before? And what can I do to help at home? That was essentially the entire emotional and practical universe of a parent looking at this app. Three questions.

Everything else — the detailed reading-fluency scores, the comprehension breakdowns by text type, the session-by-session difficulty curves that teachers found so valuable — produced the opposite of what we intended. It didn't inform parents. It made them anxious.

They'd look at a complex metric and feel implicated by it, like they were being shown evidence of a problem without being handed any way to fix it.The core conclusion was almost a sentence: a parent cannot deal with complex analytics, because they don't know how to turn them into action. And data you can't act on isn't neutral. It's not just unhelpful — it actively generates worry. That reframed the whole product for me.

That led to your central design decision — replacing performance analytics with effort analytics. Unpack that.

This is the heart of the project. Performance analytics tell you what a child achieved — a score, a level, a measurement against some benchmark. Effort analytics tell you what a child did — how many sessions, how consistently, how much time they spent engaged. For a teacher, performance is actionable. For a parent, it's mostly a source of helplessness.

The reason is simple and a little bit profound: you can't tell a child to score higher. That's not a thing a parent can do anything with. But you can absolutely tell a child to practice for fifteen minutes today. Effort is within a family's control. Performance isn't, at least not directly. So designing around effort meant designing around the things a parent could actually influence.

Concretely, I restructured the hierarchy. The three primary operations — tied to that listening-reading-understanding model — went to the top of the main screen, front and center. The performance analytics that teachers prioritize, like difficulty level and reading fluency, got moved to a secondary layer.

Still there, still accessible for the parent who really wanted to dig — but not the first thing you hit, and not something you had to understand to feel oriented.We also gave parents three concrete goals for the child to accomplish, rather than a wall of metrics. Goals are effort framed as action. Instead of "here is your child's comprehension percentile," it became "here are three things, and here's how practice moves you toward them." That's the difference between a report card and a path forward.

You ran usability testing on this. What happened?

The usability process covered the whole onboarding flow and tested whether parents understood the features. And it was humbling in the way good usability testing always is. I genuinely believed the interface I'd built was intuitive — clear, simple, obviously legible. Then I watched real parents use it, and there was a significant gap between what I'd planned and what actually happened on the screen.That gap is the whole value of testing. It doesn't matter how clear something is to the person who designed it — you've been staring at it for weeks, of course it's clear to you.

What matters is the parent who opens it for the first time at their kitchen table, tired, a little anxious about their kid, with no design context whatsoever. That's the real test, and the prototype failed parts of it.

So I went back and analyzed the sessions, coded the recurring behaviors, and looked for patterns in where people got confused or stuck. The findings reinforced the core direction — parents didn't want interpretive burden, they wanted clarity and a sense of progress — but they also showed me specific places where even my simplified design was asking too much.

We rebuilt significant parts of the main screen before launch based on that. Not a cosmetic polish — a structural response to watching the gap between intention and reality. That willingness to be wrong about your own clarity is, I think, the difference between designing for yourself and designing for the actual person.