In a recent User Experience Expert Circle webinar, Partner Success Technical Lead, @BraamSmithCLSA, shared a powerful, yet simple, technique to move beyond surface-level requirements and uncover the real business outcomes that projects need to address. The key, he argues, is to shift the conversation from how a solution should look to why it’s needed in the first place.
Watch the video (4 minutes) →
What you will learn
Stop Starting with the UI
A common pitfall in software development is receiving a requirement that is already a proposed solution. Stakeholders might insist, “I need it to look like this Excel spreadsheet,” or “We need a custom section here to display instructions.” While it’s tempting to build exactly what’s asked, this approach often treats the symptoms rather than the root cause of a problem.
Braam’s advice is to avoid starting with the UI. Instead, the first and most crucial step is to agree with stakeholders on the specific business outcome that each step in a workflow must fulfill. This means identifying what data needs to be shown, while deliberately stepping back from how it should be presented.
The “5 Whys” Method in Action
To get to the heart of a requirement, Braam champions the “XY” or “5 Whys” method. This technique involves repeatedly asking “why” to peel back layers of a request and move past symptoms to identify the core challenge.
He provided a clear example:
-
The Request: “We need a custom section to display instructions on the case screen.”
-
Why #1: Why do you need a custom section?
- “Because we need to show instructions to the user.”
-
Why #2: Why do you need to show instructions?
- “Because our users are unsure how to complete this step.”
-
Why #3: Why are they unsure?
- “Because the process is new and not intuitive for them.”
-
Why #4: Why isn’t the process intuitive?
- “Because the default view isn’t highlighting the key actions.”
-
Why #5: Why aren’t the key actions highlighted?
- “Because we haven’t configured contextual help or used the latest UI patterns yet.”
In just five questions, the conversation evolved from a demand for a “custom section” (a solution) to the real problem: a lack of intuitive design and a need for better contextual help. By focusing on the initial request, the team would have addressed a symptom. By asking “why,” they uncovered the actual business need, enabling them to implement a more effective and elegant solution that genuinely helps the user.
By adopting this simple method, you can ensure you are always building solutions that deliver real value and address the fundamental needs of the business, rather than just replicating old designs in a new system.
Who should watch this?
This session is designed for anyone involved in designing, delivering, or governing Pega applications, including:
- Solution Designers and Solution Builders responsible for producing high-fidelity Blueprints or building Pega solutions.
- Pega Consultants and Partners looking to stay current with the latest capabilities
