Before You Build, Look Sideways

A founder recently shared a story about building a charitable giving startup—only to realize, months later, that donor-advised funds had already solved much of the problem.

It started, as these things often do, with a frustrating form. A clunky nonprofit donation flow. Confusing language. Too many fields. He did what many of us would do: sketched a better version. Then he prototyped it. Interviewed friends. Built momentum. Eventually, he discovered an entire ecosystem—financial products, tax structures, established platforms—that had been quietly addressing the underlying need for years.

He shut it down.

I’ve been thinking about that story because it doesn’t read like failure. It reads like something much more common in our field: mistaking friction for opportunity without understanding the system around it.

In the last week alone, I’ve seen conversations about scaling without clarity, AI generating beautiful interfaces that users still abandon, and frameworks for building “high-trust” SaaS systems. Different domains, same tension. We are very good at building. We are less disciplined about situating what we build inside the broader landscape.

As a design lead, I’ve learned this the hard way. The most expensive mistakes I’ve been part of weren’t poor interfaces. They were products that solved something already solved—or solved the wrong layer of the problem entirely.

The Seduction of the Local Fix

There’s a particular thrill in spotting friction. A broken form. A slow workflow. A confusing dashboard. Designers are trained to see these micro-moments.

And often, they are real problems.

But friction exists at different layers:

• Interface friction – unclear labels, bad hierarchy, awkward interactions.
• Workflow friction – misaligned steps, redundant tasks, context switching.
• Systemic friction – policy constraints, financial structures, regulatory realities, market incentives.

That charitable startup began with interface friction. The form was poorly designed. That’s real. But the deeper problem—how individuals manage tax-advantaged giving—had already been addressed at a systemic level.

When we don’t zoom out, we risk over-investing in what I call the local fix: polishing the surface while ignoring the underlying architecture.

I’ve seen teams spend six months redesigning onboarding for a B2B tool, only to discover that activation issues were tied to procurement policies and internal IT approval—not button placement. According to Gartner, the average B2B buying group now involves 6–10 decision-makers. No amount of microcopy can simplify that reality.

Sometimes what looks like a usability problem is actually an ecosystem problem.

Designers are uniquely positioned to notice this, but only if we expand our lens beyond the screen.

Growth Without Orientation

Another conversation this week focused on scaling before clarity—when user numbers rise but the experience fractures.

Growth can mask misalignment. A product can gain traction while still being conceptually confused. In fact, momentum often reduces the incentive to step back.

A McKinsey study found that companies with strong design practices outperform industry benchmarks by as much as 2:1 in revenue growth. But what gets less attention is why: high-performing teams don’t just ship interfaces—they align experience with strategy and ecosystem realities.

Clarity isn’t just about a sharp value proposition. It’s about understanding:

1. What layer of the problem you’re operating on.
2. What adjacent systems already exist.
3. What constraints you cannot design away.

When teams skip this orientation phase, they often scale the wrong thing. They refine conversion funnels before validating positioning. They automate workflows before confirming whether those workflows should exist at all.

In one product I worked on, we optimized task completion time by 18% through careful interaction design—simpler states, clearer hierarchy, better defaults. It was meaningful work. But churn barely moved. Why? Because the core value proposition didn’t integrate with the accounting tools customers already relied on.

We had optimized in isolation.

That’s a humbling realization. And a necessary one.

AI Can Draw the UI. It Can’t Map the Terrain.

There’s another thread running through recent discussions: AI tools that generate UI in seconds. Entire layouts, color systems, responsive states—done.

The Vietnamese headline put it bluntly: users don’t need beautiful UI. They need usable UI.

I’d take it a step further.

AI can generate surface solutions quickly. What it cannot yet do well is understand where in the broader ecosystem your product sits—or whether it should exist at all.

Large language models can summarize competitors. They can propose feature sets. But they don’t feel the awkwardness of a donor navigating tax law. They don’t experience the politics of internal budget approvals. They don’t sit in the meeting where legal quietly says, “We can’t actually do that.”

That lived context matters.

In a recent internal workshop, we experimented with AI-generated design explorations. The visual quality was impressive. But every concept assumed we controlled the entire user journey. In reality, our product occupied a small slice between legacy systems and compliance requirements.

The designs were elegant—and strategically naive.

As designers, our responsibility is shifting. It’s no longer enough to craft interfaces. We have to understand the terrain those interfaces sit within.

That requires a different kind of rigor.

The Discipline of Looking Sideways

When I mentor early-stage founders or new product managers, I often suggest a simple exercise before building anything substantial:

1. Map the Ecosystem

Not just competitors. Map:

• Adjacent tools users rely on.
• Financial or regulatory structures influencing behavior.
• Informal workarounds people use today.
• Stakeholders who benefit from the status quo.

If your product disappeared tomorrow, what system would absorb the need?

The founder of that charitable startup discovered donor-advised funds late in the process. An ecosystem map early on might have redirected his energy—or helped him identify a truly underserved layer.

2. Identify the Constraint You Cannot Design Away

Every product sits inside at least one non-negotiable constraint.

In healthcare, it’s compliance. In fintech, regulation and risk. In enterprise SaaS, procurement cycles. In social platforms, network effects.

When we pretend those constraints are design problems, we waste cycles. When we design with them in mind, we build more resilient solutions.

3. Clarify the Level of Innovation

Are you:

• Improving an interface?
• Reconfiguring a workflow?
• Introducing a new business model?
• Challenging policy or infrastructure?

Each level requires different evidence, different patience, and different humility.

A surprising amount of startup energy goes into level-one innovation disguised as level-three ambition.

That’s not a moral failure. It’s a clarity issue.

Trust Is Earned in Context, Not Isolation

There’s also a strong theme right now around building “high-trust” systems.

Trust doesn’t emerge from a polished landing page or well-written privacy policy. It emerges from coherence across touchpoints.

Stock photography, for example, might seem like a small aesthetic choice. But research from the Nielsen Norman Group has consistently shown that users respond more positively to authentic imagery over generic stock visuals. Generic visuals signal distance. Authentic visuals signal presence.

That’s not about aesthetics. It’s about alignment between what you claim and what you show.

Trust compounds when:

• Your visual language matches your operational reality.
• Your promises reflect constraints you’ve actually accounted for.
• Your growth doesn’t outpace your ability to support people.

High-trust systems aren’t built through features alone. They’re built through ecosystem awareness.

If you understand the terrain—legal, financial, cultural—you make fewer overpromises. And that restraint builds credibility.

The Emotional Arc of Realizing “It’s Already Solved”

There’s a quieter layer to that founder’s story that I respect deeply.

He shut it down.

That moment—the realization that your elegant solution isn’t as novel as you thought—is painful. It confronts ego. It forces you to admit you fell in love with the build before fully understanding the landscape.

But it’s also a sign of maturity.

In product design, we don’t talk enough about the skill of letting go. Of recognizing when your insight isn’t differentiated. Of choosing to redirect energy rather than defend sunk cost.

I’ve been there.

Years ago, I championed a redesign initiative aimed at simplifying a complex reporting tool. We produced beautiful prototypes. Clean typography. Clear information architecture. Usability tests showed moderate improvements.

Then a customer conversation shifted everything.

They didn’t want simpler reports. They wanted automated exports into their existing analytics pipeline. The complexity wasn’t the core pain—manual transfer was.

We had been solving the visible layer.

We pivoted. It was the right call. But it required admitting that our carefully crafted solution wasn’t addressing the deeper need.

That humility is part of the craft.

Building With Context Is Slower. And Wiser.

There’s pressure right now to move quickly—especially with AI lowering the cost of prototyping. The barrier to building has never been lower.

But the barrier to understanding remains the same.

And understanding still takes:

• Conversations beyond your immediate user base.
• Research into regulatory and financial structures.
• Honest competitive audits.
• Reflection on whether your insight is local or systemic.

This isn’t about discouraging experimentation. It’s about elevating discernment.

Before you build, look sideways.

Ask:

• Who else is already addressing this?
• At what layer?
• Why hasn’t the problem been solved the way I imagine?
• What constraints shape this space?

If the answers reinforce your idea, you build with conviction. If they undermine it, you’ve saved yourself—and your team—months of misplaced effort.

Either outcome is progress.

The Craft Is Bigger Than the Interface

As designers, we’re trained to care about hierarchy, spacing, interaction patterns, accessibility. And we should. Details matter. They shape daily experience.

But our real leverage often lies earlier—in deciding what deserves to be designed in the first place.

That’s not glamorous work. It’s quieter. It involves reading industry reports, talking to adjacent stakeholders, mapping incentives, and sometimes realizing the problem is already solved—just not in the way you expected.

There’s dignity in that realization.

Because the goal isn’t to build something new at any cost.

The goal is to build something that fits—within systems, within constraints, within the real lives of the people we’re trying to serve.

And sometimes, the most responsible design decision is not the one that ships.

It’s the one that pauses, looks sideways, and chooses clarity over momentum.