Designing around Technical Limitations

Kene Eyisi
0 Comments

Design conversations usually start with the ideal solution.

A smooth workflow.

A simple interface.

Everything connected and reacting instantly.

Real product work is rarely that clean.

While working on an enterprise tool, I ran into a situation where a missing API forced me to rethink a small but important part of the interface.

When the original interaction depended on something that didn’t exist

Part of the interface relied on a simple visual signal.
A checkmark or a progress indicator.

The idea was straightforward. The system would check a condition through an API and then show the appropriate state.

If condition A was satisfied, the interface would show a confirmation checkmark.
If the condition was not satisfied, the interface would show a progress indicator to communicate that the operation was still in progress.

From a design perspective, this made sense. The interface simply reflected the system state.

During discussions with the developers, we realised something important.

The API that would provide that condition did not exist.

Without that API, the interface had no way to determine which state to display.

The design problem this created

Without the API, the interface could not rely on real system feedback.

But the interface still needed to display something.

Leaving the area blank or showing an indefinite loading state would create confusion. Users would assume the system was stuck or broken.

So the design problem became very practical.

What should the default state be when the system cannot yet determine the real condition?

Choosing the least disruptive default

There were two possible directions.

Start with a progress indicator by default and switch to confirmation later, or start with confirmation and only show progress if new information suggested the task required tracking.

After thinking through how users would interpret each option, I chose the confirmation checkmark as the default state.

There were a few reasons behind that decision.

First, most operations in this flow completed successfully without extended processing. Showing a progress state by default would suggest that something time-consuming was happening when, in most cases, it wasn’t.

Second, constant progress indicators create unnecessary cognitive noise. If users repeatedly see loading or processing states, they start to question whether the system is slow or unstable.

Third, the confirmation state aligned better with the user’s expectation. When users need to complete an action, they generally expect to be able to confirm that it worked.

Allowing the interface to adapt when needed

Even though confirmation became the default, the interface still needed to react when new information became available.

So the design allowed the state to change.

If incoming data later indicated that the operation required tracking or was still processing, the interface would switch from the confirmation checkmark to a progress indicator.

This meant the system could still reflect real activity when necessary, but it avoided unnecessary uncertainty when no data was available yet.

The interface started with the most likely outcome and adjusted only when new information suggested otherwise.

What this small constraint revealed

This was not a large feature or a dramatic redesign. It was a small interaction detail.

But it highlighted something that happens constantly when designing real products.

Interfaces often assume system capabilities that are still evolving.

When those capabilities are not available, the role of design shifts from expressing system logic to shaping user expectations.

The goal becomes finding the behaviour that creates the least confusion while still allowing the system to respond accurately when the data eventually arrives.

Designing within reality

Working through situations like this has changed how I think about design decisions.

The first design is often built around what the system should be able to do. The final design is shaped by what the system can actually do today.

That gap is where collaboration with developers becomes most valuable.

Technical limitations are not unusual in product work. They are part of the environment design operates within.

Sometimes the best solution is not the one that perfectly represents system logic.

Sometimes it is the one that creates the clearest experience, even when the system cannot yet provide all the answers.