Buzz Usborne
Menu

🫨
When systems collide: Designing for emergence

February, 2026

Every mature product eventually surprises its creators.

Features that once felt simple begin behaving differently. Not because they changed, but because the system around them did.

I first noticed this with my own product, Prevue. After ten years, millions of uploaded images, and countless small iterations, once-innocent features began interacting in ways I hadn’t anticipated. What started as clean functionality evolved into something qualitatively different from what I had originally built. And as the only designer and developer, there were no external teams to blame, no shifting requirements — just the natural consequences of a system maturing.

With the rise of vibe-coding and dramatically faster development cycles, that evolution is no longer measured in years. In a modern product, it can happen in months — with AI, sometimes weeks. Through my coaching practice, I’ve watched teams struggle to explain why their product suddenly feels more complex than they intended. I’m also increasingly finding myself helping designers advocate for revisiting features leadership assumed were settled.

I’ve come to think of this as emergent behavior — which is when individually understandable features collide to produce something new. Sometimes the shift comes from the system itself… sometimes it comes from the people using it.

Emergence isn’t a software invention, it’s a well-established property of living systems in nature. But the concept remains consistent: when parts interact, new patterns form. In software, those patterns can reshape expectations, expand scope, and sometimes redefine what an entire product is actually for.

Over time, I’ve seen this show up in two distinct ways: feature emergence and conceptual emergence.

🎻 Feature emergenceDirect link

Feature emergence happens when meaning shifts not because the feature changes — but because the surrounding system does. Imagine a violin — beautiful and complete on its own. Now place it inside an orchestra, and its role transforms dramatically. The violin didn’t change, the system around it did.

In 2018 at Help Scout, we introduced avatars to the product — tiny, expressive, mostly internal. They helped teammates recognize each other, and not a lot else. Years later, we launched — Beacon — our embeddable chat tool. When customers started chatting, those same avatars appeared externally. Nothing about the avatar feature had changed, but overnight its meaning had.

Any message delivered by Peppa is psychological warfare.

Playful internal images suddenly carried professional weight. A harmless cartoon could now undermine trust. Two independent systems — internal collaboration and external communication — collided in a way that no team had designed for.

Users adapted, but not in ways we would have liked. Some replaced their face with their company logo, preserving professionalism but sacrificing individuality. Others appeared offline to avoid exposure — which quietly hurt adoption. Some removed avatars entirely. Naturally we adapted and found a solution that solved for both uses, but it required re-visiting an old feature nobody had planned on.

Ultimately two independent systems collided, producing an outcome neither was designed for.

A well-known example is the 👍 Like button on Facebook. Originally designed as lightweight affirmation — a way to say “Nice!” without typing it — later became entangled with advertising systems, engagement algorithms, and cross-platform data flows (like Instagram etc). The button stayed visually identical, but its consequences multiplied. Now, liking something is also an invitation to tweak the algo, direct money to advertisers, and signal your intention to purchase. No longer just “Nice!”.

Feature emergence is when meaning is shaped by adjacency — where every new addition builds on, but also challenges, what came before it. Add an AI summary feature, and your product doesn’t just gain a tool… suddenly all other features compete with a new center of attention.


🛹 Conceptual emergenceDirect link

If feature emergence happens when surrounding context shifts a feature’s meaning, conceptual emergence happens when the people who use your product reshape that meaning entirely. You build a sidewalk. People start skating — and before long, you’re building ramps.

Sometimes the signal isn’t in what you planned, but in how people respond to what they’re given.

I saw this firsthand at Skype. A research team traveled to Japan to understand why video adoption lagged. The assumption was technical, but the reality was social. They discovered that people hesitated to turn on their camera if their environment was messy or private — which in turn led to the creation of background blur.

A similar research team over at Google observed that when frustrated, users would physically shake their phones. The rage shake. That involuntary gesture became a formalized interaction — shake-to-report. Both products adapted to behavior, not adoption curves or feature requests.

Hashtags offer the clearest example of how conceptual emergence can offer a source of the most powerful ideas. They weren’t part of Twitter’s original design until a subset of users started manually adding the # to group conversations to make them searchable. What began as a user hack for discoverability became foundational to how the platform works.

Twitter did’t invent hashtags. Users did.

In all these cases, meaning shifted not because the system changed — but because people did. It’s why product roadmaps never last; no strategy survives contact with real behavior.


Awareness > AvoidanceDirect link

There’s no clean way to prevent emergence — only the acceptance that it’s a natural response. Emergence isn’t a failure of design, it’s proof that the system is alive. So the challenge isn’t control, it’s perception.

When customers stretch features beyond their intended scope, or when a simple concept begins expressing itself in new contexts, those moments aren’t inconveniences — they’re signals. They reveal how people are actually using your product — not how you imagined they would. It’s one of the reasons I love working in legacy products — you’re given front-row seats to watch your own ideas take on entirely new forms, or re-solve problems you thought you’d already solved!

Emergence is the moment our product starts teaching us.

Each of these moments presents a design fork in the road — either formalize the new behavior, or contain it before it becomes structural. That’s the real discipline of working in a mature system: not avoiding mutation, but deciding which ones shape what the product becomes.

In an AI-accelerated era, where features ship faster than teams can document them, our ability as designers to recognize emergence isn’t optional — it determines whether your product evolves intentionally or accidentally.

All articles