Not every product comes with a clear user base, an established market, and a shelf of research to borrow from.
Sometimes you’re designing something that doesn’t quite exist yet. You’re building an MVP in a domain that’s still forming. The buyers aren’t fully defined. The people you can interview aren’t the people who will actually use the product — they’re adjacent, informed, but not quite right.
I’ve been there. And the honest answer is: you don’t wait for clarity. You work with what you have, make your assumptions explicit, and let the product teach you the rest.
1. Talk to everyone who holds a piece of the puzzle.
When you can’t talk to the real user, go to everyone who knows something about them.
This isn’t passive — it’s deliberate. Make a list of every person in the organization who has touched the problem: engineers who understand the technical constraints, PMs who’ve spoken to potential customers, customer-facing employees who’ve seen the pain firsthand. Each of them holds a different piece of the picture.
The goal isn’t to find one person who knows everything. It’s to collect enough fragments — about needs, goals, frustrations, workflows — to build a working hypothesis about who you’re designing for and what they actually need.
Ask each person: who do you think this product is for? What problem are they trying to solve? What would make their day meaningfully easier? You’ll be surprised how much a team collectively knows about a user that no one has ever fully articulated.
2. Name your assumptions — especially about who the user is.
When the user isn’t defined yet, the most important assumption isn’t about the UI. It’s about the person.
What’s their role? What does their day look like? What are they responsible for — and what would make their work meaningfully easier?
In one project I worked on, we were building an MVP in a space where the eventual buyers were still hypothetical. So we went to the people closest to the problem: employees who had worked directly with customers, and the PM who understood what those customers had asked for.
From those conversations we built a working hypothesis — not a validated persona, but an honest best guess. A specific role, with specific responsibilities, specific pressures. Enough to design toward something real.
We held that hypothesis loosely. Every time we showed something to someone who touched the domain, we asked: does this feel right for the person you work with? Does this match how they think?
That feedback loop — between assumption and reaction — is what slowly brought the user into focus.
3. Anchor on what doesn’t change.
In an uncertain domain, some things are always true. Find them and hold on.
Even when the user profile is fuzzy and the market is undefined, there are usually a few stable truths. Someone needs to understand a complex situation quickly. They need to know what to act on. They need to trust what they’re seeing.
Those aren’t UX assumptions — they’re human constants. Speed of comprehension, hierarchy of information, confidence in the data. Design toward those, even when everything else is uncertain.
When you don’t know exactly who your user is, design for what any intelligent person in that situation would need. You’ll be closer than you think.
4. Use the data you have as a design material.
In data-heavy products, the data itself tells you what matters.
When there’s too much data — more than any user could reasonably process — that volume is itself a design problem. And a design signal.
Ask: what would someone look for first? What would make them stop scrolling? What’s the difference between “interesting” and “urgent”? Those questions shape the hierarchy, the visual weight, the structure of every screen.
The data won’t tell you who the user is. But it will tell you a lot about what they’d need to do with it.
5. Iterate toward clarity, not toward perfection.
You won’t get it right the first time. That’s not a failure — it’s the process.
The first version won’t be the right one. It can’t be — you don’t know enough yet. But it gives you something to react to. Something real enough that the people you show it to can say “yes, this” or “no, not that.”
Each iteration narrows the unknowns. Each conversation with someone who touches the domain — even indirectly — adds something to the picture. Slowly, the user comes into focus. Not because you found them, but because you built your way toward them.
That’s often how it works when you’re first. You don’t discover the user. You design until they appear.
Designing without a map is uncomfortable. There’s no checklist that makes it clean, no framework that removes the uncertainty.
But that’s the nature of an MVP. You’re not designing the final answer — you’re designing the first question.
An MVP doesn’t need a perfect user. It needs a good enough hypothesis and the courage to test it. The unknowns don’t disappear — they just get smaller, one iteration at a time.