The Feedback Paradox: Building With Families, Not For Them

The research team showed families a prototype. The families liked it. They said the right things — it was clean, intuitive, easy to use. They pointed out a few things that could be better. The researchers nodded, took notes, went back, and built exactly what the families had said they wanted.

The product launched. Families didn't use it the way they'd described. Some features they'd asked for sat untouched. Some moments the researchers had assumed weren't important turned out to be the ones families cared about most. The feedback had been genuine. The product had been built faithfully. And somehow, neither the feedback nor the faithfulness had been enough.

This is the feedback paradox at the center of designing genuinely new categories of technology. Families are extraordinarily articulate about their problems. They are much less able to envision solutions — especially for something that would require them to imagine using a tool that doesn't yet exist.

The limits of asking#

Henry Ford's apocryphal quote — "If I had asked people what they wanted, they would have said faster horses" — gets cited too often in technology circles, usually to justify not listening to users at all. That's the wrong lesson. The right lesson is more specific: asking people what product they want is different from understanding what they are trying to do.

Families who struggle with fragmented digital memory don't think of themselves as customers in need of a new product category. They experience specific, discrete pains: the birthday video is on one phone, the Christmas photos are on another, the voice message from a grandmother who passed is buried in a chat app that isn't backed up anywhere. They articulate these problems with clarity and feeling.

But ask them to describe a solution and they will tend toward one of two failure modes. They'll describe an incrementally better version of something that already exists — "like Google Photos but with better organization" — or they'll describe something so ambitious it functions more as a wish than a requirement — "I just want everything in one place and I never want to think about it again." Both kinds of feedback are real and valid. Neither tells you how to design the thing that would actually help.

Dr. Donald Norman, whose work on human-centered design has shaped product development for decades, has written about the gap between what people say they want and what their behavior reveals they need. People routinely describe their desires in terms of the familiar, because the familiar is what they can articulate. The genuinely new — the thing that would solve the underlying problem differently from anything that currently exists — often can't be envisioned until it already exists.

The lead user insight#

Eric von Hippel at MIT Sloan School of Management spent years documenting a paradox in product innovation: the most valuable design input often comes not from typical users, but from those who have experienced the need most acutely — and who, out of necessity, have already improvised partial solutions on their own.

Von Hippel called these people "lead users." In the family memory space, they are the parent who has spent hundreds of hours manually migrating photos from platform to platform before a service shutdown. The adult child who has been calling elderly relatives to record their stories because she realized, suddenly, that the people who know those stories are getting older. The person who has tried every family-sharing app and jury-rigged a combination of four of them that half-works, in a way that only they can maintain.

These families cannot describe the product that would solve their problem, because they've never seen it. But they can describe the problem with unusual specificity and depth, because they've lived it at a level of intensity that typical users haven't reached. They've made decisions under that pressure — kept some workarounds, abandoned others — and those decisions are data.

The insight isn't that you should only talk to extreme users. It's that families who have felt a problem most acutely, and whose lives show evidence of real attempts to solve it, are better design guides than families who experience the same problem only mildly. The severity of experience sharpens the feedback in ways that surface-level preference surveys simply cannot replicate.

What co-design actually means#

The field of co-design, developed most fully by researchers like Elizabeth Sanders and colleagues across participatory design practice, argues for something more fundamental than better user research. It argues that the people who will live with a product should be active participants in creating it, not passive evaluators of prototypes presented to them for approval.

This sounds more radical than it is. It doesn't mean families write the code or design the interface. It means their experiences, their improvised workarounds, their language for describing what they're trying to do, and their stories about what has gone wrong all become primary material for design decisions — not just inputs that someone else interprets into requirements.

When families describe privacy concerns, they rarely use the language of data governance or compliance. They use the language of dignity. "I don't want my kids' faces used to train some AI model." "I don't want my grandmother's voice used to advertise something." "I don't want my family's moments to become content for other people to see." These are moral intuitions about what memory means — and they are more precise than any privacy specification that would be written without them.

The IDEO Design Kit methodology, developed through years of work in human-centered design, offers a concrete framework for accessing this level of insight: immerse in what people do, not just what they say they want. Observe behavior without narration. Build quick, rough prototypes that make abstract ideas concrete enough to react to. Test with the same families across iterations, so the relationship develops enough trust to surface honest feedback rather than polite feedback.

The distinction between honest and polite feedback is critical. Families in a single-session user test are performing evaluation — they are visitors to your process, and visitors tend to be courteous. Families who have been in a co-design relationship long enough to feel genuine investment will tell you when something is confusing in a way they couldn't describe to a stranger. They'll show you how they actually use the thing, which is often different from how they said they would.

The most important feedback you'll ever receive from a family about a tool for their most intimate memories won't come in a survey. It will come in an unguarded moment — when they're not performing evaluation, just trying to use the thing, and either succeeding or quietly giving up.

The honest contradiction at the center#

Here is the paradox that co-design cannot fully resolve: families cannot give you feedback on something they haven't experienced, and they can't experience something that hasn't been built yet.

Design researchers distinguish between three levels of user knowledge: what people can say, what they do, and what they feel or dream. Surveys capture the first. Observation captures the second. Participatory design methods — creative probes, experience prototypes, generative workshops — try to access the third.

The third level is where the most important feedback lives. A family that has never had a place to store voice memories alongside the photos of the people speaking them cannot articulate that this is what they've been missing. But give them the experience — even roughly, even imperfectly — and the recognition is immediate. This is what I didn't know I needed.

This is why the most honest development process for genuinely new categories of technology moves iteratively between building and listening, rather than staging them as separate phases. Build something real enough that families can experience it, not just evaluate it. Then observe what happens in the ordinary moments of their lives — not in the controlled feedback session where everyone is on their best behavior.

The families who become co-creators#

The families who participate deeply in shaping a product they've helped build are different from customers who were shown a prototype and asked to approve it. They have a relationship with the thing they helped make. They know why certain decisions were made. They can explain those choices to other families in a way that no marketing language can replicate, because they were there.

They are also more forgiving of the inevitable imperfections — not because they've lowered their standards, but because they understand the constraints and tradeoffs that produced the limitations. And they are more invested in the product working, because something of their own lives went into it.

This matters especially for a category like family memory, where trust is the foundational requirement. A platform holding your family's most precious records needs to have earned that trust through demonstrated respect for what families actually care about — not claimed it through marketing that promises a connection it hasn't demonstrated.

What the feedback paradox teaches#

The feedback paradox is ultimately not a problem to be solved but a condition to be navigated. Families cannot design what they haven't seen. They can tell you, with precision and feeling, what their lives are like without it.

That gap — between the problem as lived and the solution as imagined — is where genuine category creation happens. Not by ignoring what families say, but by understanding it at a deeper level than the surface request. "Faster horses" is real feedback; it just requires decoding. The need beneath it isn't for speed — it's for reliable, accessible transport that reduces the burden of moving from place to place. Understand the underlying need, and you can invent something the person asking for a horse couldn't have imagined.

For family memory, the underlying needs are not mysterious. Families want to feel that their stories are safe. They want multiple generations to participate without requiring technical fluency. They want to discover things about each other that simple sharing wouldn't surface. They want the act of preserving memory to feel like it belongs to the family, not to the platform.

Building from those needs — rather than from the feature requests that try to approximate them — is the discipline that separates technology families actually live with from technology they install, evaluate briefly, and quietly abandon.

The feedback paradox isn't a reason to stop listening. It's a reason to listen more carefully — to what families are telling you about their lives, rather than what they think you want to hear about your product.