Designing an adequate user experience or UX is easy. Designing a beautifully effective UX that not only meets all the business requirements, but is effortless to use, is incredibly hard.

I'm sure like many of you I've had the experience of staring at a UX of a project that I'm working on and thinking, "there's something wrong here", or "this doesn't feel right", yet not knowing what the right solution is no matter how long I stare at the problem.

Conversely I've had the experience of working with a colleague who has UX with problems. They would show me where users were having trouble with some of the interaction, or explain that they wanted to add a new feature, yet didn't see how it could fit cohesively. I was immediately able to see the solution; it was easy.

So why could I often see solutions to other people's problems more readily than I could see solutions to my own problems?

The Pattern Problem

Now it's worth mentioning here, I'm no neuroscientist or psychologist, but I do have a hunch what's happening. Human brains are really good at learning and repeating patterns, which is very useful for doing things like never forgetting how to ride a bike, even after years of not riding one. But give someone a bike which is set up with the steering in reverse, so that it will turn left when you steer right, and turn right when you steer left, then our brain fights it; it can take weeks to reprogram ourselves to the new pattern.

I think what's happening when I'm staring at my own UX and realizing that there is a problem, yet not having a clue what the solution is, is that I'm stuck in a pattern. I can only see what the problem is. Then the more I think about the problem, the more that the pattern of the problem gets reinforced, so any solution remains elusive.

Why Rubber Ducking Works for Code

You've probably heard the term "rubber ducking" in software programming. This is the practice of explaining a technical problem to an inanimate object, or explaining the problem to someone who isn't technical and knows nothing about the subject whatsoever.

Doing this can often have the effect that the solution somewhat magically pops into your head while you're explaining it; simply articulating the problem allows us to see an elusive solution.

When we are "rubber ducking" we are reformatting and externalizing a problem.

We're taking a problem that exists in code and in our mind, and reformatting it as spoken language, then communicating that to someone or something else, which is externalizing it. The code and how that code is held in a programmer's mind is in a completely different format to how spoken language is constructed. This is why "rubber ducking" works so well for code; it forces a new pattern into the programmers mind because the code needs to be translated into spoken language, and then externalized when talking to the duck. It breaks the old pattern and allows the programmer to see a new one.

Why UX Design is Different

The problem with UX design is that the problem is already externalized. A UX is something you see, or use or interact with. Unlike code or a technical problem, there's little narrative, and it's not often something that can have a long explanation in spoken language.

This is why I think the solution to solving UX design is to have two people.

The Two-Person Solution

• The first person explains the problem or the requirement.
• The second person designs the solution.

This is not because there should be a separation between business people and designers; it doesn't matter which person plays which role. It's because our brains are really bad at seeing new patterns once old patterns are learnt, and really good at seeing correct patterns when presented with incorrect ones.

The Neuroscience Behind It

When we're deeply embedded in a problem, we develop cognitive blind spots. The neural pathways associated with our understanding of the problem become so well-established that they actually prevent us from seeing alternative solutions. It's like wearing mental blinders.

But when someone else looks at the same problem with fresh eyes, they don't have those established neural pathways. They can see patterns and solutions that are invisible to us precisely because they haven't been conditioned by prolonged exposure to the problem.

Practical Application

This principle applies beyond just UX design:

• Code reviews work for the same reason - fresh eyes catch bugs the original programmer can't see
• Writing benefits from editors who can spot issues the author is blind to
• Strategic planning improves when outsiders challenge internal assumptions

The key insight is that perspective switching is often more valuable than expertise accumulation. Sometimes the best solution comes not from the person who knows the most about the problem, but from the person who knows the least about the constraints we've unconsciously accepted.

Implementing Dual-Perspective Design

This cognitive principle transforms how we approach creative problem-solving across disciplines. Here's how to systematically harness the power of fresh perspective:

The Four Pillars of Effective Collaboration

1. Dynamic Role Rotation - Establish a culture where team members alternate between problem-presenter and solution-architect roles. This prevents cognitive ownership bias and ensures everyone develops both analytical and creative muscles.
2. Structured Knowledge Transfer - Create clear handoff protocols that capture not just the problem statement, but the constraints, assumptions, and failed attempts. This context prevents the fresh perspective from repeating dead ends while maintaining their cognitive distance.
3. Strategic Naivety - Actively cultivate and protect "beginner's mind" by bringing in outsiders, junior team members, or cross-functional colleagues. Their "obvious" questions often expose the invisible assumptions that trap expert thinking.
4. Cognitive Firewall - Time-box the fresh perspective phase to prevent contamination by existing mental models. Once someone becomes too familiar with the problem, their outsider advantage diminishes rapidly.

Beyond UX: Universal Applications

This dual-perspective approach revolutionizes outcomes across domains:

• Engineering teams catch architectural blind spots through cross-team reviews
• Strategic planning benefits from external consultants who challenge internal orthodoxies
• Creative agencies use account-creative partnerships to balance business constraints with breakthrough thinking
• Academic research leverages interdisciplinary collaboration to overcome field-specific biases

The goal isn't process overhead, it's systematically weaponizing cognitive diversity to shatter the pattern-lock that keeps breakthrough solutions invisible to expert eyes.