The Iceberg Model is a systems thinking tool that helps uncover the root causes of problems by looking beyond immediate, visible events. It uses the metaphor of an iceberg to illustrate that events (the tip) are driven by deeper layers that are hidden below the surface.

In UX design, it means that instead of merely tackling immediate issues with short-term fixes, we should research and solve the underlying causes for long-term solutions.

ORIGIN

The Iceberg Model comes from systems thinking, a field concerned with understanding how interconnected parts of a system produce the outcomes we observe.

The metaphor is simple: only a small portion of an iceberg is visible above the water. Most of it remains hidden below the surface.

At the surface are events: the immediate things we notice. Below them are recurring patterns. Deeper still are the structures that produce those patterns. At the bottom are mental models: the assumptions, beliefs, and values that helped create the system in the first place.

The deeper you go, the harder the problem becomes to see – and usually the harder it becomes to change.

WHEN

If your team keeps winning small battles against the same problem, you’re probably staring at the tip of the iceberg. Other indications for icebergs ahead include the following:

• You’ve fixed the same issue three times
  It keeps returning, occasionally wearing a different hat.

• Small UX problems appear everywhere
  One confusing screen might be a screen problem. Twenty confusing screens suggest something deeper.

• Local improvements don’t improve the overall experience
  Every team is successfully optimizing its piece. The complete journey remains terrible.

• Stakeholders keep proposing surface fixes
  “Can we just make the button bigger?”

• Nobody wants to ask why the system works this way
  Changing the interface is easy. Questioning the organizational assumptions behind it is Tuesday afternoon gone forever.

WHY

The Iceberg Model helps us examine problems at four increasingly deeper levels:

Events (the tip): What happened?
Users aren’t clicking the button. Something happened, we can see it, and we’d quite like to fix it before Friday.

Patterns (below the surface): What keeps happening?
Users aren’t just missing this button. They’re struggling with primary actions throughout the product.

Structures (the system): What keeps producing the pattern?
Perhaps every team adds its own buttons, there is no shared hierarchy, and nobody owns the complete experience.

Mental Models (the deep end): Why did we build the system this way?
Perhaps the organization believes more options = more value, so removing anything feels like taking value away.

Most teams naturally react at the event level because that’s where problems are visible and solutions feel achievable. Going deeper is harder to identify and fix. And that’s why the same problem keeps coming back.

HOW

The recipe for fixing superficial problems sounds easy: Start at the surface. Then resist the urge to stop there.

Here are some tips to get to the bottom of the iceberg:

• Describe the event without solving it
  Start with what actually happened: “Users abandon checkout at this step,” not “The checkout button needs to be bigger.”

• Look for patterns
  Ask where else the problem appears, how often it occurs, and whether it has happened before.

• Trace the structures
  Examine workflows, ownership, incentives, technology, policies, information architecture, and processes that could be producing the pattern.

• Surface the mental models
  Ask what assumptions make the current system seem reasonable. Users want more choice. Every feature deserves visibility. More engagement is always better.

• Choose the right depth for the intervention
  Not every UI problem requires organizational therapy. Sometimes the button really does need fixing. But recurring problems deserve deeper investigation.

• Fix causes as well as symptoms
  You may still need the immediate patch. Just don’t confuse stopping today’s leak with repairing the plumbing.

• Watch what happens afterward
  If the problem returns, that’s evidence that you haven’t reached the layer producing it yet.

PRO TIP

As designers we need to remember that taking shortcuts may be fast, visible, and feel productive. But fixing structures and following mental models is the bread and butter of our jobs. It’s hard, requires effort and courage, and sometimes forces us to attend a meeting we don’t want to be part of. But at the end of it, this work separates the good from the great designer.

EXAMPLES

• Users repeatedly miss important actions because every team adds its own controls, driven by the belief that more options mean more value.
• A map remains overwhelming despite repeated visual cleanups because every available dataset is expected to be visible by default.
• New features consistently have poor adoption because teams measure success by shipping features rather than whether users discover or need them.
• Onboarding gets redesigned repeatedly while the real problem is that users don’t understand why they need the product in the first place.
• Teams keep adding warnings to prevent mistakes instead of fixing the confusing interaction that keeps producing those mistakes.
• A checkout flow receives endless UI tweaks while an underlying business rule requires customers to provide information they don’t have.

CONCLUSION

The Iceberg Model reminds us that what’s easiest to see isn’t necessarily what’s most important to fix. While everything else – the systems, the decisions, the beliefs – is sitting quietly below the surface, shaping your product like a mischievous sea monster.

Great designers don’t just fix what’s visible. They look below the waterline, dive deeper, ask uncomfortable questions, and occasionally ruin a perfectly good meeting with: “But why are we doing it this way?”