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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
\nThe Iceberg Model<\/strong> comes from systems thinking, a field concerned with understanding how interconnected parts of a system produce the outcomes we observe.<\/p>\n\n\n\n
The metaphor is simple: only a small portion of an iceberg is visible above the water. Most of it remains hidden below the surface.<\/p>\n\n\n\n
At the surface are events<\/strong>: the immediate things we notice. Below them are recurring patterns<\/strong>. Deeper still are the structures<\/strong> that produce those patterns. At the bottom are mental models<\/strong>: the assumptions, beliefs, and values that helped create the system in the first place.<\/p>\n\n\n\n
The deeper you go, the harder the problem becomes to see – and usually the harder it becomes to change.<\/p>\n<\/blockquote>\n\n\n\n
WHEN<\/h2>\n\n\n\n
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:<\/p>\n\n\n\n
\n
- You’ve fixed the same issue three times<\/strong>
It keeps returning, occasionally wearing a different hat.<\/li>\n<\/ul>\n\n\n\n\n
- Small UX problems appear everywhere<\/strong>
One confusing screen might be a screen problem. Twenty confusing screens suggest something deeper.<\/li>\n<\/ul>\n\n\n\n\n
- Local improvements don’t improve the overall experience<\/strong>
Every team is successfully optimizing its piece. The complete journey remains terrible.<\/li>\n<\/ul>\n\n\n\n\n
- Stakeholders keep proposing surface fixes<\/strong>
\u201cCan we just make the button bigger?\u201d<\/li>\n<\/ul>\n\n\n\n\n
- Nobody wants to ask why the system works this way<\/strong>
Changing the interface is easy. Questioning the organizational assumptions behind it is Tuesday afternoon gone forever.<\/li>\n<\/ul>\n\n\n\nWHY<\/h2>\n\n\n\n
The Iceberg Model helps us examine problems at four increasingly deeper levels:<\/p>\n\n\n\n
Events (the tip): What happened?<\/strong>
Users aren’t clicking the button. Something happened, we can see it, and we’d quite like to fix it before Friday.<\/p>\n\n\n\nPatterns (below the surface): What keeps happening?<\/strong>
Users aren’t just missing this button. They’re struggling with primary actions throughout the product.<\/p>\n\n\n\nStructures (the system): What keeps producing the pattern?<\/strong>
Perhaps every team adds its own buttons, there is no shared hierarchy, and nobody owns the complete experience.<\/p>\n\n\n\nMental Models (the deep end): Why did we build the system this way?<\/strong>
Perhaps the organization believes more options = more value<\/em>, so removing anything feels like taking value away.<\/p>\n\n\n\nMost 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.<\/p>\n\n\n\n
HOW<\/h2>\n\n\n\n
The recipe for fixing superficial problems sounds easy: Start at the surface. Then resist the urge to stop there.<\/p>\n\n\n\n
Here are some tips to get to the bottom of the iceberg:<\/p>\n\n\n\n
\n
- Describe the event without solving it<\/strong>
Start with what actually happened: \u201cUsers abandon checkout at this step,\u201d not \u201cThe checkout button needs to be bigger.\u201d<\/li>\n<\/ul>\n\n\n\n\n
- Look for patterns<\/strong>
Ask where else the problem appears, how often it occurs, and whether it has happened before.<\/li>\n<\/ul>\n\n\n\n\n
- Trace the structures<\/strong>
Examine workflows, ownership, incentives, technology, policies, information architecture, and processes that could be producing the pattern.<\/li>\n<\/ul>\n\n\n\n\n
- Surface the mental models<\/strong>
Ask what assumptions make the current system seem reasonable. Users want more choice.<\/em> Every feature deserves visibility.<\/em> More engagement is always better.<\/em><\/li>\n<\/ul>\n\n\n\n\n
- Choose the right depth for the intervention<\/strong>
Not every UI problem requires organizational therapy. Sometimes the button really does need fixing. But recurring problems deserve deeper investigation.<\/li>\n<\/ul>\n\n\n\n\n
- Fix causes as well as symptoms<\/strong>
You may still need the immediate patch. Just don’t confuse stopping today’s leak with repairing the plumbing.<\/li>\n<\/ul>\n\n\n\n\n
- Watch what happens afterward<\/strong>
If the problem returns, that’s evidence that you haven’t reached the layer producing it yet.<\/li>\n<\/ul>\n\n\n\n<\/ol>\n\n\n\n
PRO TIP<\/h2>\n\n\n\n
\nAs 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.<\/p>\n<\/blockquote>\n\n\n\n
EXAMPLES<\/h2>\n\n\n\n
\n
- Users repeatedly miss important actions because every team adds its own controls, driven by the belief that more options mean more value. <\/li>\n\n\n\n
- A map remains overwhelming despite repeated visual cleanups because every available dataset is expected to be visible by default. <\/li>\n\n\n\n
- New features consistently have poor adoption because teams measure success by shipping features rather than whether users discover or need them. <\/li>\n\n\n\n
- Onboarding gets redesigned repeatedly while the real problem is that users don’t understand why they need the product in the first place. <\/li>\n\n\n\n
- Teams keep adding warnings to prevent mistakes instead of fixing the confusing interaction that keeps producing those mistakes. <\/li>\n\n\n\n
- A checkout flow receives endless UI tweaks while an underlying business rule requires customers to provide information they don’t have.<\/li>\n<\/ul>\n\n\n\n
CONCLUSION<\/h2>\n\n\n\n
The Iceberg Model reminds us that what’s easiest to see isn’t necessarily what’s most important to fix<\/strong>. While everything else – the systems, the decisions, the beliefs – is sitting quietly below the surface, shaping your product like a mischievous sea monster.<\/p>\n\n\n\n
Great designers don\u2019t just fix what\u2019s 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?”<\/p>\n","protected":false},"excerpt":{"rendered":"
The Iceberg Model is\u00a0a 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.<\/p>\n","protected":false},"author":1,"featured_media":936,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[23],"tags":[19,110,104,109,105,106,53,107],"class_list":["post-645","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-the-productivity-mirage","tag-design","tag-events","tag-iceberg","tag-mental-model","tag-model","tag-patterns","tag-productivity","tag-structure","entry","has-media","owp-thumbs-layout-horizontal","owp-btn-big","owp-tabs-layout-horizontal","has-no-thumbnails","has-product-nav"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-content\/uploads\/2026\/09\/40.jpg","_links":{"self":[{"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/posts\/645","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/comments?post=645"}],"version-history":[{"count":7,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/posts\/645\/revisions"}],"predecessor-version":[{"id":973,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/posts\/645\/revisions\/973"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/media\/936"}],"wp:attachment":[{"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/media?parent=645"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/categories?post=645"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/tags?post=645"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}