An introduction to “the Iceberg”.
Have you ever started working on a project, started asking questions, and suddenly realised that the problem or the brief is actually a lot bigger and more complex than anyone anticipated?
You’ve just discovered an iceberg.
What is a UX iceberg?
An iceberg is something that seems small, simple or at least manageable at first glance, until you realise the immense depth of complexity sitting beneath the waterline.
The iceberg is a metaphor that has been used in product development for the last 2 decades, and it applies to so many projects, problems, and design scenarios that it’s a concept I use almost every day.
Here are some three real-life examples I come across frequently:
Redesigning a website and discovering how many stakeholders, departments, systems and processes are actually involved
Trying to optimise/improve a website that’s built on an outdated codebase
Introducing a new functionality into an existing complex ecosystem
Any kind of voice interaction project
What’s the risk?
Well if you’ve seen the movie Titanic, you know you don’t want to hit an iceberg.
Other risks include the fact that left ignored, they seem to get bigger, as stakeholders add more “simple requests” to the top of the iceberg, only increasing the mass of complexity and implications below the surface.
The final outcome? Failed projects, massive waste of money, time and resources, impact on reputations and careers.
Why doesn’t everyone see these coming?
Here’s what I’ve learned in 14+ years working on UX, CX, and Service Design projects, of varying levels of complexity —
Most people don’t think things through..
Some people choose to ignore complexity, in the hope that it will go away or someone else will deal with it. Some are too busy or overwhelmed with other things to notice. Others are just not experienced enough to know or anticipate how complex something is or may become.
With this can sometimes come the arrogance of “how hard can it possibly be to <do thing>?!”
When you hear noise like this, you might be nearing an iceberg.
Here are some more scenarios where you might encounter iceberg-related drama:
The project hasn’t been scoped properly — In the agency world, this happens a lot when someone sells and scopes a project without UX practitioner supervision. Once a practitioner comes on board, they spend the first 2 weeks furiously trying to get everyone to realise that the client’s expectations are actually much greater than the time and resource assigned.
Over-promising without technical understanding — Again, a classic agency or consultancy trait. With the desperate desire to please a client comes the promising of All The Things, or even one “simple” thing that turns out will take years and cost billions.
Someone made a pretty — The obsessive desire of some stakeholder or even designers to rush to screen designs results in everyone believing something already has been thought-through, is based on evidence of user need or behaviour, has consensus behind it, is usable, accessible profitable, buildable, or even… finished and live.
Too many assumptions — Humans like to think they know things. See above. So they assume things based on a combination of past experience and how they want the world to be. Asking questions removes risk. Forging ahead with only assumptions will result in iceberg impact.
Organisation implications have been ignored — Not involving the right stakeholders from the outset means you can’t possibly know all the implications of what you’re about to attempt. Engaging stakeholders can reveal complexity, but it can also discovery simplicity — this will actually allow you to shrink your iceberg!
Lack of user research — There are times when you scale up or down research, but don’t ignore it completely. One way to trigger an iceberg of your very own is to discover a user-related problem that effects every part of your ecosystem, that should really should have known about early on.
But this is the luxury of UX — we are the people who are paid to ask questions, point out the dreadful (iceberg) and help teams and companies get back on track so that we can all focus on user needs.
Why the iceberg concept is useful to a project
When you’re staring at an iceberg, it is natural to feel a sense of panic. However the mental model of the iceberg is actually very useful in handling and communicating project complexity.
It helps us understand:
How we build a shared visual representation of the project or challenge itself
How we decide how much complexity we are able to handle, with which group or team or timings and why
How we communicate to a specific audience (which includes stakeholders but also day to day, how we handle reporting, training or onboarding people, general team management)
How to work with a live ‘project’ iceberg
Once you can harness the iceberg, it’s actually fairly easy to manage. There are some simple steps if you find yourself staring at an iceberg that you want to get under control:
Step 1
Recognise it — as above, simply realising that something is an iceberg is half the battle. Be brave, take the red pill and step forward.
Step 2
Understand, Define and Visualise it
Keep reading with a 7-day free trial
Subscribe to It Depends... to keep reading this post and get 7 days of free access to the full post archives.