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 15+ 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 — Yes this sounds like the UCD process. (useful, isn’t it.) You need to understand how big the iceberg actually is, work out everything that’s included (people, processes, products, systems). Then you need to map it out in some format that shows both scope and scale. I usually also include a graphic of an actual iceberg, just to drive the point home..

For an enterprise digital solution, you may need to map stakeholders, dependencies, systems integration, data sets and more.

For a voice application, you need to demonstrate the amount of logic that sits beneath a “simple” call-response, in order to show how the logic and therefore workload increases exponentially as each new “simple” request is added at the top.

Step 3

Communicate it — this can be a scary moment, but you need to get relevant stakeholders in the room and show them how big the iceberg actually is. This will usually be met with stunned silences followed by some kind of emotive noise as people realise the implications of what they are attempting.

This is ok. You are doing your job. You are not responsible for the iceberg. You are just pointing at it.

This usually has one of two outcomes — the downsizing/scoping of the ask or the increase of resource to handle it. Both are excellent outcomes, because they return everyone to reality of what can be done by when.

Step 4

Divide, Conquer and Empower — Once everyone on the team can see the iceberg for what it is, it’s time to start assigning roles, responsibilities and phasing.

As an example, if you are introducing a new service into an existing ecosystem, you could treat the top of the iceberg as basics or fundamentals of the new experience, the middle as implications for other channels and the bottom as the full technical specification.

In this way, you can keep higher level stakeholders focused on the big picture and agreeing principles that will effect the entire project, use the middle layer to make product and ecosystem-level decisions, and leave the detail to the tech experts.

This works as long as you support communication between slices of iceberg. Which brings us to step 5…

Step 5

Keep communicating it! — As with most projects, communication is key. Here are your communication priorities:

1. Remind everyone what the big picture is (full iceberg overview at a macro level)
2. Remind everyone who is doing what (recap step 4)
3. Let everyone know what is happening on other workstreams that impact theirs, without burdening them with too much detail. This means communicating critical decisions and need-to-knows.
4. Encourage two way communication so that any further changes to iceberg scope and size are clearly flagged.
5. Put someone in charge of being The Bridge — the link between the layers, the person who communicates status, dependencies, risks etc at all times.

Whatever you do, don’t just focus on the easy bit at the top, bury the other 90% and pretend its someone else’s problem

It’s not just ‘project’ icebergs…

I see icebergs all the time in UX world. Not just in projects but in the industry itself — from mentoring and training to my own development of a new skill set or methodology.

Here are some I see with newbies all the time:

• Taking on more than you can really handle — ah, the enthusiasm of youth. I’ve seen so many young’uns wade into projects they thought they could handle and quickly flounder. Humility and asking questions upfront will help you with this.
• Not flagging early enough when you need help — connected to the one above, some new UXers are so desperate to prove themselves that they’ll plough on into an iceberg rather than ask for help. Personally I try to train this out of people on day 1.
• Learning burnout — Let’s not forget that the UX industry itself has become an iceberg. I talk regularly with newbies who are overwhelmed by the amount of skill sets involved training. (Note: I’ve written an article about how to design your own training plan, should you need it.)

In all these cases, when you discover an iceberg, you don’t have to be immediately overwhelmed — you just need to start the process of handling the iceberg you’ve discovered.

The iceberg is coming…

UX work is getting more complex each year, with companies adding more and more digital and technical complexity to their existing ecosystems. Intelligent businesses are using UX consultants to ensure that changes have deliver improvement in the user experience, or at least have minimal impact in degrading what already exists.

Getting comfortable with complexity will make you a better and more useful UXer.

In this complex world, the iceberg is simply a concept for managing and modelling project complexity, your own cognitive load and that of the people around you.

• It enables you to move from a macro to a micro mindset and back again without your head exploding, or causing team members to have a meltdown.
• It turns a complex, potentially overwhelming problem into a single thing, with more easily manageable layers that everyone can get their head round, so makes it easier for people to visualise a project, the different component parts, their roles and responsibilities. It’s also a great entry point for bringing new team members into a project without overwhelming them from day one.
• It helps you support project managers by coming to them with a plan of attack, or as one of my clients once said “How do we eat this elephant?”
• As a team leader, it helps you highlight those team members who can deal with complexity and those who can’t — so that you can support them and help them to be more effective
• It helps you manage scope and scale — you can quickly identify the size of the overall iceberg and if needed, scale back scope at the top to make the overall thing smaller, reduce risk and make the project more likely to be delivered.
• It makes you a more useful UX consultant — more resilient and more able to take on yet more complexity if needed.

As with all icebergs, you just need to know what is coming at you.

Resources:

Other references to the iceberg model on the internet, in relation to UX:

Berry, 2000 — The user experience The iceberg analogy of usability (citation link but no article available)

Cappel & Huang, 2015 — The iceberg model of website usability