The Interface as an Archaeological Site

Halfway through a strength workout, I needed to take a video call.

I looked at my Garmin watch and tried to pause the activity. The screen offered two options: “Stop Workout” and “Settings.”

Stopping sounded final. Settings sounded irrelevant. There was no pause.

After searching for an answer, I discovered that Garmin does not really have a general pause state for this kind of strength workout. The intended solution is to finish the current set, leave the watch running on the rest screen during the call, and then start the next set when the call ends.

The video call becomes an unusually long recovery period.

This is a tiny usability problem, almost too small to complain about. The workout still gets recorded. Nothing crashes. No data disappears. There is a workaround.

Yet the moment captures something important about the way complex products fail.

Garmin understands the internal structure of strength training. It understands sets, repetitions, rest periods, heart rate, elapsed time, exercise names, recovery, and training load. It understands enough to produce charts, scores, recommendations, and long-term performance trends.

What it does not understand is interruption.

A phone call is not part of the workout. It is not recovery. It is not a completed activity. It is simply life entering the system from outside.

The software has no category for that, so reality must be squeezed into the nearest available one. A video call becomes rest. An interruption becomes training data. The user has to translate an ordinary situation into Garmin’s internal language.

This is where a technically sophisticated product suddenly feels strangely dumb.

Garmin watches are often described as difficult to use because they have too many menus, too many buttons, and too many settings. All of that is true, but it is also slightly superficial. The deeper issue is that Garmin has built a very detailed model of sport without building an equally flexible model of the person doing the sport.

The watch knows what a workout is supposed to look like. It is less prepared for what workouts actually look like.

Real workouts are interrupted. Someone calls. The gym closes. A machine is occupied. A child starts crying. You forget your water bottle. You need the bathroom. A meeting begins earlier than expected. You stop to speak to someone. You decide to continue later.

These situations are ordinary, but software often treats them as edge cases because they do not fit neatly into the designed flow.

The product has a model. Life has other plans.

The weight of capability

Garmin’s interface makes this conflict especially visible because the device is so capable. A Fenix can track activities across running, cycling, swimming, skiing, hiking, strength training, navigation, sleep, recovery, heart rate, altitude, weather, and more. It is an impressive piece of hardware. It can operate for days, survive rough conditions, connect to external sensors, and collect data in places where a phone would be useless.

The interface carries the weight of all that capability.

Every sport introduces new concepts. Every sensor adds new settings. Every generation adds more metrics, profiles, screens, alerts, and modes. Features accumulate, while the overall interaction model remains largely recognizable from earlier watches.

The result is an interface that feels less like a designed system and more like an archaeological site.

Each layer reflects a decision made at a different moment. One button behavior exists because of runners. Another menu exists because of cyclists. A third setting was added for triathletes. A fourth option appears only during structured strength workouts. Some controls live on the watch. Others live in the phone app. Some are global. Others are attached to a specific activity profile. Some appear only while the activity is running.

The logic may make sense locally. The total system becomes difficult to reason about.

Products grow through addition

This kind of complexity is common in mature software. Products rarely become confusing because someone deliberately designed a confusing interface. They become confusing because every new request is reasonable.

Users want another metric. Athletes want more control. A professional audience needs deeper configuration. A competitor launches a new feature. A support ticket reveals another missing option. An old workflow cannot be removed because experienced users depend on it.

The product grows through addition.

Over time, the interface begins to preserve the history of the organization that built it. Old assumptions remain visible. Internal categories leak into menus. Technical boundaries become user-facing boundaries. The product reflects how teams, features, and databases are structured behind the scenes.

The interface becomes a map of the company rather than a map of the user’s intention.

This is why configurability is so often mistaken for usability. Garmin gives users enormous control. Nearly everything can be adjusted. Data screens can be customized. Activities can be configured. Sensors can be paired. Alerts can be created. Metrics can be rearranged.

Access to every option can feel like respect for the user. In practice, it often transfers the design problem to them.

The user must understand which system state they are in, which menu owns the setting, which button changes meaning in the current context, and which workaround best approximates what they wanted to do.

The device can do almost anything, but the user must learn how the device thinks.

Discoverability and trained efficiency

There is a legitimate reason for some of this. Garmin watches are physical tools used while moving, sweating, wearing gloves, swimming, standing in rain, or navigating unfamiliar terrain. Buttons can be more reliable than touchscreens. Experienced users can become extremely fast once they memorize the system. A deeply learned interface can outperform a visually obvious one in demanding conditions.

Garmin’s design is therefore not random incompetence. It reflects a real trade-off between discoverability and trained efficiency.

The problem appears when training becomes a prerequisite for basic actions.

Pausing an activity should not require understanding the ontology of structured strength training. The user should not need to know that the system distinguishes rest from pause, or that one activity profile exposes different controls from another. The interface should help bridge that gap.

A good complex product does more than offer features. It explains its own structure through use.

The coming usability debt

The Garmin example matters beyond watches because software is entering a period where capability is becoming dramatically cheaper.

AI makes it easier to add features, generate screens, create settings, connect services, and build workflows. A small team can now produce software that once required a large engineering organization. A single developer can add advanced functionality in days. Products can expand before anyone has fully decided how the pieces should fit together.

This sounds like a golden age of software creation. It may also become a golden age of usability debt.

When the cost of adding a feature falls, the discipline required to reject, combine, simplify, or redesign features becomes more important. Otherwise, products will accumulate capability faster than users can build a mental model of them.

The central design problem shifts.

The difficult question is no longer whether software can perform a task. Increasingly, it can. The difficult question is whether the product can make its growing capabilities legible.

Can the user understand what state the system is in? Can they predict what will happen next? Can they recover from interruption? Can they move between real-world intentions and software categories without studying the product first?

These questions sound basic, but they become harder as products become more powerful.

AI-generated software may repeat Garmin’s pattern at a much greater speed. New features will be easy to create and emotionally difficult to remove. Every customer request can become a button. Every edge case can become a setting. Every workflow can become a mode.

The product may appear impressive in a demo while becoming increasingly incoherent in daily life.

This is one reason product judgment may become more valuable as coding becomes easier. Someone still has to decide what the system believes about the world. Someone has to decide which states deserve to exist, which distinctions matter, and which categories should remain invisible to users.

Someone has to notice that a video call is not a rest period.

Software must survive contact with life

The best interfaces do not force life to fit the software. They create enough flexibility for the software to survive contact with life.

That may mean introducing a true pause state. It may mean preserving the workout while excluding the interruption from active and rest time. It may mean asking the user what happened when they return. It may simply mean making the current behavior clear instead of hiding it behind activity-specific logic.

The exact solution is less important than recognizing the mismatch.

Usability problems often appear small because each one affects a single moment. A missing pause button. A hidden setting. An unclear label. A workflow that technically works but feels wrong.

These moments reveal the underlying model of the product.

Garmin’s model is precise, powerful, and deeply informed by sport. It is also rigid in places where human life is messy.

That is why the watch can measure almost everything happening inside a workout while struggling with the simple fact that sometimes, halfway through, someone calls.

AI authorship note

This essay began with Kris Haamer trying to pause a structured strength workout on a Garmin fēnix 6 to take a video call. AI helped investigate the interaction, frame the anecdote, draft, edit, and implement the article. Kris identified the real-world usability failure and directed the argument toward feature accumulation, rigid product models, and AI-era usability debt.

Connected reading

• The Product Is Becoming an Organization
• The Product Is No Longer the Product
• Every Interface Contains a Business Model
• Software for One Afternoon