Uncovering the XY problem

User Experience Knowledge Share
1

In the world of software development, we’ve all been there: deep into technical details, trying to implement a solution that quickly feels too complex and frustrating. This common scenario is often a symptom of a deeper issue known as the XY problem.

The XY problem occurs when we ask for help with our attempted solution (Y) instead of the actual problem we’re trying to solve (X). This misdirected focus can lead to a cascade of issues, including:

  • Wasted Time and Effort: Developers and teams can spend hours, or even days, struggling with a complex solution for a problem that could be solved more simply.
  • Suboptimal Solutions: By fixating on a specific implementation, we might miss a more elegant, efficient, and maintainable solution that addresses the root cause.
  • Technical Debt: Custom, convoluted solutions are often difficult to maintain and upgrade, leading to long-term technical debt.

From “How” to “Why”

The key to avoiding the XY problem is to shift our focus from “how” to “why.” Instead of immediately jumping into implementation details, we should first ask:

  • What is the underlying business need?
  • What is the user trying to achieve?
  • Why is the current approach not working?

By asking these “why” questions, we can uncover the true problem (X) and open the door to a wider range of potential solutions.

Pega Constellation: A Prescriptive Approach

This is where Pega’s Constellation design system comes in. Constellation is a modern, UI architecture that emphasizes configuration over customization. Its “prescriptive design” provides a set of pre-built components, patterns, and templates that guide developers toward best-practice solutions. This prescriptive nature is a powerful tool for uncovering and preventing XY problems.

Constellation’s design system acts as a set of “guardrails” that keep development on the right track. Here’s how it helps:



Feature

How it Uncovers XY Problems


Configuration over Customization

Constellation encourages developers to use out-of-the-box components and patterns. If a proposed solution requires extensive customization, it’s a strong indicator that it might be a “Y” solution.


View-Based Architecture

The UI is primarily driven by the data model. This forces developers to think about the underlying business data and logic (the “X”) before getting bogged down in UI details.


Prescriptive Patterns

Constellation provides proven solutions for common UI and workflow patterns. If a developer’s proposed design deviates significantly from these patterns, it prompts a conversation about the underlying requirements.

A Practical Example

Let’s assume a developer is tasked with creating a new screen for a customer service application. Their proposed solution (Y) is a complex, custom-built screen with a many fields and buttons. They spend days trying to build this screen, running into technical hurdles and creating a maintenance nightmare.With Pega Constellation, the conversation would be different. The developer would be encouraged to use pre-built views and patterns and explore what is offered out of the box. This would naturally lead to questions like:

  • “Why does the user need to see all of this information at once?”
  • “What is the most critical information for the user to complete their task?”
  • “Can we use a standard list-detail pattern to simplify the UI?”

Through this process, the team might discover that the real problem (X) is that users need a quick, at-a-glance summary of a customer’s recent cases rather than another messy dashboard.

Embrace the “Why”

The XY problem is a common pitfall in software development, but it’s one that can be avoided. By embracing a “why”-first approach and leveraging the power of a prescriptive design system like Pega Constellation, we can build better, more efficient, and more maintainable applications. The next time you find yourself struggling with a complex technical problem, take a step back and ask yourself: “What is the real problem I’m trying to solve?” “Can I achieve business requirements with a simpler solution?”. You might be surprised at the simplicity of the answer.

Curious to read your opinion on the subject, and how you handle it.

Constellation 101 Series

Enjoyed this article? See more similar articles in Constellation 101 series.

2

@Kamil Janeczek

I fully support your take on the XY problem form a UI perspective.

Generally if I encounter problems, it is not only UI related. We want do something because of a certain reason. In many of these discussions, I encounter a data-model which is not 100% thought through and than we want to solve it in the UI (which was unfortunately a common practice in UI-kit). So designing the Data model correctly will lead to less of these discussions as you focus on the data objects ‘what data does the user need to see’ and how/what does he want to enrich/manipulate it (in assignments).

3

@RonaldDeLigniethis is common pattern. When data model is not flexible to cover business needs implementation team tries to fix it with UI. Most of the time this leads to complicated solution that is only covering the root problem.

4

@Kamil JaneczekGreat that you highlight this phenomenon!

Very often, this is an organizational problem. It comes from an organization being in a “buying/ordering” mode, where stakeholders are tasked with imaginig exactly what they want and need, and then handing said requirements off to IT for building it. Very often, these stakeholders are influenced by existing solutions, or if no existing app exists, they try their best to solutionize an answer to the question they were given. Which is not their fault, but as you say, then lots of time gets spent trying to match the requirements 100%.

Constellation is one part of the puzzle, because we simply can’t match requirements like these on a pixel-level. But I would also like to highlight the need to work closely with IT squads and business stakeholders together to collaborate on a shared understanding of business outcomes instead of passing requirements documents back and forth. Then you will have much less need to try and imagine what was meant in the requirement, or try to imagine yourself what the business outcome is.

After gathering the business outcomes and processes, preferably with Blueprint in the mix, it’s important to then also perform regular iteration and feedback loops. Performing “design-UAT’s” along the way to validate your design and the realization of the business outcomes in your application, is something we have seen is crucial. Too often, the development lifecycle goes on until app is almost ready, then the final UAT is where the users get to see the app and if they have feedback, it’s very hard to pivot such late in the project.

Really like these kind of articles, because a successful project is about so much more than just the technical how-to! :grin:

5

@LantzAndreasthank you for your insightful comment. I do agree with what you wrote. We never operate in the void. We are surrounded and affected by many factors.