When Building Gets Easier, Understanding Gets Fragile

The moment that made me uneasy

Last week I sat in on a review of a tool that had been built—impressively—in under two weeks. Low‑code. Clean UI. Every workflow technically worked. The team was proud, and they should have been.

Then someone asked a simple question: "Who is this actually for on day thirty?"

The room went quiet in a way that felt familiar. Not awkward—thoughtful. We all knew the answer wasn’t in the backlog or the demo. It lived somewhere between the information architecture, the assumptions we’d made about user maturity, and the speed that had carried us here.

I’ve been noticing this pattern across product design and research conversations lately. Not just around low‑code, or AI‑assisted development, or even SaaS partner choices—but around how quickly we can now make decisions without realizing we’ve made them.

This isn’t a warning against speed. It’s a reflection on what speed quietly displaces.

Low‑code doesn’t remove research—it changes where it hides

Low‑code platforms are doing exactly what they promise. According to Gartner, by 2025 over 70% of new applications will be built using low‑code or no‑code tools, up from less than 25% in 2020. That’s not a niche shift—that’s a structural one.

What’s changing isn’t whether user research matters. It’s when teams realize they need it.

In traditional builds, research often gates development. In low‑code environments, it trails it. You can ship before you’ve really listened. Sometimes before you’ve even decided what questions to ask.

I’ve seen this play out in internal tools especially. One team I worked with built a powerful operations dashboard using a low‑code platform. It solved the exact problems leadership articulated. It also quietly confused the people who had to use it every day.

The issue wasn’t usability in the classic sense. Buttons worked. Data loaded. The issue was mental mapping. The product reflected how the builders thought about the system—not how operators experienced it under pressure.

Low‑code compresses the feedback loop for building. It often elongates the feedback loop for understanding.

What I’ve learned to watch for

When teams move fast with low‑code, a few signals tend to get missed:

• Early clarity feels optional, because nothing is expensive to change—until it suddenly is.
• Edge cases look ignorable, because the happy path is so easy to support.
• Language decisions harden invisibly, baked into labels and flows before anyone notices they’re decisions at all.

None of this is malicious. It’s structural. Speed rewards momentum, not reflection.

Information architecture is doing more work than we admit

One of the quieter trends I’ve noticed is renewed attention to information architecture—not as a deliverable, but as a retention lever.

There’s good reason. Research from Nielsen Norman Group consistently shows that users form a sense of confidence—or doubt—within their first few interactions, often before visual design or feature depth even matter. IA shapes that confidence.

I once reviewed analytics for a B2B SaaS product where onboarding completion was strong, but week‑four retention dropped nearly 18%. Usability tests didn’t surface obvious friction. The real issue emerged when we asked users to explain the product back to us.

They couldn’t.

Not because it was complex—but because the product’s structure didn’t mirror their mental model of the job. Navigation grouped features by internal team ownership, not user intent. It made sense if you’d helped build it. It felt arbitrary if you hadn’t.

Information architecture is the product explaining itself over time.

When we treat IA as something to tidy up later, we’re postponing the moment where the product earns trust.

A practical reframe I’ve found useful

Instead of asking "Does this structure make sense?" I ask teams to test three questions:

1. Can a user predict what they’ll find before clicking?
2. Can they explain why something lives where it does?
3. If a feature moved, would it feel wrong—or just different?

When the answer to the third question is “it wouldn’t matter,” that’s a signal. It means the structure isn’t doing any cognitive work yet.

Speed creates responsibility, not just opportunity

Another conversation that’s been resurfacing lately—sometimes uncomfortably—is about environments we don’t think users will ever see.

Staging environments. Admin panels. Internal dashboards. Early access builds.

A few years ago, a SaaS company learned the hard way that a publicly accessible staging environment had been indexed by search engines. User data wasn’t exposed—but the product logic was. Competitors learned more in a week than they should have in a year.

According to a 2023 Verizon DBIR report, over 15% of security incidents involved misconfigured cloud or staging environments. These aren’t advanced attacks. They’re oversights born of assumption: no one will look here.

What’s interesting is how this mirrors user experience failures.

We design carefully for the moments we expect people to be in. We’re far less thoughtful about the moments they stumble into.

Low‑code, AI coding tools, and fast SaaS builds all expand the surface area of these accidental moments.

The PM tension I feel most often

As a product manager, I feel this tension acutely. Speed is rewarded. Caution is invisible.

The work that prevents problems rarely shows up as progress. But it is progress—of a different kind.

I’ve started naming this explicitly with teams:

• What are we assuming users will never touch?
• What are we building that we don’t plan to explain?
• Where are we relying on context instead of clarity?

These questions slow things down just enough to matter.

AI can build fluency—but it can’t supply judgment

There’s been a lot of discussion lately about AI coding assistants and automated UX improvements. I use them. Many of us do.

They’re remarkable at removing friction from execution. They’re terrible at knowing why something exists.

One engineer shared notes recently about how quickly Claude helped scaffold features that would have taken days before. The surprise wasn’t that it worked—it was that it made it easier to build things they hadn’t decided were worth building.

That’s the real shift.

When effort drops, judgment becomes the scarce skill.

AI doesn’t ask:

• Is this the right abstraction?
• Does this create a new dependency for the user?
• What happens when someone encounters this out of sequence?

Those questions live with the team. And increasingly, with product leaders.

A simple practice that’s helped me

Before green‑lighting something that was easy to build, I ask for one of three things:

1. A sentence explaining what problem disappears when this exists.
2. An example of how this could confuse someone.
3. A scenario where we’d regret having shipped it.

If none of those can be articulated, we’re probably building to fill space—not to serve need.

Choosing partners, tools, and paths with eyes open

One trend I’ve noticed is renewed scrutiny around SaaS development partners. That’s not accidental.

When building gets faster, who you build with shapes your blind spots.

I’ve seen partnerships succeed not because of technical excellence—but because the partner was willing to slow the team down at the right moments. To ask questions that felt inconvenient. To surface trade‑offs instead of smoothing them over.

The best partners I’ve worked with didn’t just deliver features. They:

• Challenged assumptions about users we hadn’t met yet
• Flagged structural decisions early, when change was still cheap
• Treated information architecture and naming as first‑class work

Speed plus care compounds. Speed without it just accelerates debt.

What all of this is really pointing to

Across all these conversations—low‑code, IA, AI, security, SaaS partnerships—I see the same underlying shift.

We are moving from a world where building was the bottleneck to one where understanding is.

That changes what it means to be good at this work.

It asks product managers to be stewards of judgment, not just delivery. It asks designers to think structurally, not just interactively. It asks researchers to show up earlier—or risk being asked to validate decisions that have already calcified.

Most of all, it asks us to remember that every shortcut still lands somewhere in someone’s day.

Ending where the work actually lives

I keep coming back to that quiet moment in the review—the pause after the question no one had planned for.

That pause wasn’t a failure. It was a signal. A chance to notice that something important hadn’t been named yet.

In a landscape where tools keep removing friction, those pauses matter more than ever. They’re where judgment surfaces. Where care has room to breathe.

The future of product work isn’t slower. But it is more deliberate.

And the teams that hold onto that—who make space for understanding even when speed makes it optional—are the ones whose products won’t just ship quickly.

They’ll make sense when people arrive.