After today’s Apple Event I went on a run. I couldn’t stop thinking about Apple’s new Dynamic Island feature:

The thought that kept emerging is not new but Apple’s new feature had brought it once again to the surface:

Embracing constraints can turn bugs into features

I returned to find my Twitter feed filled with the same exact sentiment (also proving the point that there is truly nothing new under the sun):

Some history

In 2018 Apple introduced iPhone X and with it the controversial “notch” area reserved for the front-facing camera system. Snap, Instagram, and BeReal have ensured that front-facing imaging is not going anywhere. It’s only growing. Essentially it was a dead area of the screen that had to be tolerated and accepted. If the usable phone screen was a continent, the notch was an annoying gulf that interrupted content on the phone.

After sitting with the “bug” for 5 years, Apple has decided to what good designers often do: embrace constraints instead of tolerating them.

The anatomy of an embrace

What do designers mean when we talk about “embracing constraints”? To put it simply, we have two essential choices when presented with inputs or factors that constrain our ability to choose freely from the field of available options:

1. We can choose to fight constraints and use our energy and time to remove the environmental, technological, or situational factors that we feel are limiting us; or
2. We can choose to use the constraint as a creative tool that will ultimately inform and shape our final solution.

Both options have trade-offs and design in the real world requires that we navigate these not as black-and-white options but more as points on a continuum that we must constantly evaluate and rebalance to.

Sometimes it is good to fight technological constraints. This is necessary when the right solution requires infrastructure development in order to be successful. An example of this might be Steve Jobs pushing back against engineers who told him that something could not be achieved. In this case breaking through constraints enabled whole new categories of product to exist today that otherwise wouldn’t exist.

At other times it is important to embrace constraints. A recent example of this from my work at Mercury is the new feature Payment Requests that we recently launched:

In order to build public-facing Payment Request URLs we knew that sufficient security would need to be developed under the hood in order to make account and routing numbers publicly visible. By using per-contact holding accounts we enabled a way for this to happen. However, it came with underlying costs. Per-contact accounts are cumbersome and could be tricky for customers to manage and maintain. Reporting is more difficult. There are also factors that made it impossible to do auto-reconciliation.

These clear constraints were things we had to understand and lean into when delivering the final solution: something that our customers love and that has enabled flexibility and security they otherwise wouldn’t have if we had designed the feature differently.

Good design is slow

What is not obvious from Apple’s delightful new Dynamic Island feature is the timescale of how long it took to concept, iterate on, and launch a feature like this. This was at least 5 years in the making.

Good design isn’t always obvious at first. It takes time to arrive at the right solution. Sometimes the only way forward is to live with our constraints for a while. Solving real world problems means we are always rebalancing toward an ideal state that we never full achieve.

But the process of rebalancing brings into frequent contact with constraints that, if embraced as inputs, can make us more resilient, better at our craft, and push us toward solutions that are better over the long horizon.