Spotting UI icebergs: the complexity beneath the clicks

The Figma designs are crisp. The interactions flow beautifully. Sign-off is painless. But when development begins, stickier questions can arise. What does this button actually do? What happens when that form fails? Who’s designing the empty state?

We call these hidden pieces of complexity UI icebergs. The bit above the surface is evident, but you have to look deeper to see the true scale of the work.

The trick is to make sure icebergs land on the radar before they cost unexpected time and money. Fortunately, there is a way.

What lies beneath

During design, teams often zero in on primary flows, but can overlook the complexity behind the clicks. 

The problem compounds as Figma designs look increasingly real. People forget that designs aren’t the thing, even if they look like it. They’re lossy. They don’t capture every implication.

As an example, say a public sector client has a website of services for homeowners, including checking eligibility for grants and calculating energy savings. The designs look straightforward: a few buttons on a landing page plus some simple navigation. Dev teams estimate a few weeks work.

But it turns out grant eligibility needs rule engines for property type, location and income. Energy calculations need building data, usage patterns, and local climate factors.

Each tool turns out to be a complete application in its own right. That would have been good to know in advance.

Iceberg-spotting is a team sport

In the waterfall days, designers assumed developers would figure out the details. Developers assumed designers would spec everything thoroughly. User experience fell into the gap in between.

The difference today? Ownership of different parts of the experience is still siloed, but there are more roles and disciplines in the mix, and usually more product complexity. So there are many more gaps for things to get lost in.

Take an online shopfront. One team handles product pages, another owns checkout. The product page team doesn’t think about what happens after you hit the buy button. The checkout team doesn’t think about how items arrived in the basket. Iceberg ahead!

There’s rarely any one person who understands, or is responsible for, the end-to-end journey who also has the bandwidth to find and address icebergs.¹ The team must get together and think through each journey.

When to spot icebergs

Ideally, you’ll catch icebergs during early design work. The surest way to find them is to gather everyone together and go through every element systematically. 

Ask what’s behind each interaction — every link and every button. The response is often that it hasn’t been looked at yet, or it was presumed to be someone else’s responsibility. Iceberg discovered!

Behind that innocent-looking button could be a complete other web app, potentially more complicated than the one at the surface. It might be a system that doesn’t exist. Or it might need wholesale changes to support your proposal. It could be a third-party service that hasn’t been chosen yet.

You need to constantly review designs and consciously look for these hidden implications. A critical checkpoint is when the scope starts to become definitive. There’s no better time to ask whether it’s possible the team has overlooked massive piles of stuff.

Be sure to record every iceberg you discover, and remember that it shouldn’t automatically become the responsibility of the people that found it.

Risks of looking the other way

Fortunately, there isn’t a Titanic in this analogy to sink your project. The hidden work always appears eventually. 

The risk is that you discover more work to do after you’ve committed to timelines and resources. Worst case, you complete a program and discover significant extra work at the end. 

This is unlikely in practice as there are usually enough people who care to catch problems earlier. But unexpected icebergs can cause real budgetary headaches if they’re discovered too late.

Ultimately, the responsibility is collective and continuous throughout design. That way, delivery can remain a matter of execution rather than a series of unexpected discoveries.

Footnotes

1. It’s an evolving discipline, but service design is starting to fill this gap. But in our experience service designers are often spread thinly across an organisation. And they’re not always empowered to referee when problems arise. ↩