The role of the Solution Designer
A business stakeholder often begins a meeting with valuable knowledge of the challenge, its effect on the organization, and a potential solution. The Solution Designer builds on that starting point by working with business stakeholders to evaluate the evidence, clarify the change the organization wants to achieve, and connect that change to a shared understanding of the problem.
This topic explains how the Solution Designer applies judgment, works across business and delivery responsibilities, and builds confidence through evidence from the beginning of the engagement.
A discipline, not a job title
Solution Design describes a discipline that can be practiced by people in different roles across an engagement. A Solutions Consultant leading discovery, a Business Architect facilitating design, or a technology leader within the business may each act as the Solution Designer when they take responsibility for shaping business intent into a coherent solution design.
The discipline is defined by the judgment the practitioner applies and the work they perform:
- Analyze the business challenge and identify the problem the solution should address.
- Challenge assumptions constructively and distinguish the intended business change from a proposed solution.
- Bring stakeholder perspectives together around an outcome that is clear enough to guide design.
- Recommend a design direction and make the supporting evidence and reasoning visible.
- Maintain the connection between the agreed outcome and the evolving design from framing through Go-Live.
Together, these responsibilities help maintain the Golden Thread of the Blueprint Delivered™ methodology, with Pega Blueprint™ providing the shared working environment across Blueprinting, Authoring, and Value Activation.
Where accountability sits, and where it is shared
As illustrated in the following figure, Solution Design brings together distinct responsibilities across the business, the Solution Designer, and the Solution Builder:
Note: The business owns the outcome. The Solution Designer provides the judgment and design discipline that connect it to the solution, while collaboration with the Solution Builder ensures that the design can progress confidently into implementation.
Working with the Solution Builder
The Solution Designer designs with Pega Blueprint. The Solution Builder builds within Pega Infinity Studio™.
Solution Builder is also a discipline rather than a job title. It may be performed by a Lead System Architect, a partner, or a technical leader inside the business. The relationship between the two is not a handoff but a shift in who leads across one continuous journey with the business. Your continued presence as the Solution Designer during Authoring is not supervision; it is stewardship of the intent captured during Blueprinting.
The following figure illustrates this concept:
Note: The Solution Designer helps maintain the Golden Thread by staying connected to the design through every phase, identifying drift, clarifying intent, and validating that the delivered solution reflects the agreed outcome.
Building confidence through evidence
Stakeholder confidence grows when the Solution Designer arrives prepared, makes starting assumptions visible, and works with the business to shape the direction. An informed hypothesis in Blueprint gives the conversation something concrete to evaluate, which accelerates discovery, surfaces assumptions, and identifies where further evidence is needed.
As the conversation widens, the Solution Designer brings together business, technology, and end-user perspectives to test and refine the emerging understanding.
This work builds confidence because stakeholders can see their evidence reflected in the design, understand the reasoning behind it, and influence the choices being made.
Stage 1 - Draft an informed hypothesis: Before the first conversation, use industry knowledge, research, and Blueprint to frame the challenge the business may be facing. The hypothesis demonstrates preparation and gives stakeholders a meaningful starting point to evaluate.
Stage 2 - Make assumptions visible: Present the hypothesis as shared material. Identify the assumptions it contains and work with stakeholders to confirm what evidence supports and where further investigation is needed.
Stage 3 - Test and refine the hypothesis: Bring together business owners, technology partners, and end users to evaluate the challenge from different perspectives. Distinguish symptoms from underlying causes, reconcile competing priorities, and refine the emerging problem and the intended outcome.
Stage 4 - Build agreement in Blueprint Preview: Allow stakeholders to evaluate the emerging design, understand the reasoning behind it, and shape the direction hands-on. Record the resulting decisions and areas that require further validation.
By the end of the fourth stage, the Solution Designer has developed a more complete body of evidence: a validated problem statement, a measurable outcome, and an agreed direction for the design.
Scenario: Meet Elena from U+ Travel
Elena is the operations manager for U+ Travel on Cala Verde Island. Her booking volume outgrew her operational capacity two seasons ago. When she describes what she needs, she uses the words she has been using with her team: a booking system, a way to see everything, something that stops the double-bookings. Elena has formed an initial view of the problem and is looking for a solution quickly.
The Solution Designer builds on Elena’s perspective by evaluating what she has shared, challenging initial assumptions constructively, and clarifying the broader change she wants to achieve. That conversation establishes a stronger basis for defining the problem, outcome, and direction of the engagement.
Decide for U+ Travel
Ten minutes into the first meeting, Elena says:
I have looked at three booking systems already. I just need one that shows all our excursions in one place, and I need it before the season starts in April.
Elena has shared a potential solution, an important requirement, and a deadline.
| How would you respond? |
Consider what evidence you would gather before recommending a direction and what questions would help you better understand the change Elena wants to achieve. |
|---|
In practice
Compare your approach to the practices below that shape a first conversation.
| Best practice | Why it matters | A question that puts it to work |
|---|---|---|
| Listen for the change, not the solution | The stakeholder’s opening description provides evidence of both the immediate need and the broader change the design must serve. | “What would be different for U+ Travel a year from now if this were solved?” |
| Stay curious before confirming | This approach helps build on the stakeholder’s initial perspective and develop a fuller understanding of the challenge. | “What have you already tried, and what happened?” |
| Bring a hypothesis, not an answer | A concrete hypothesis gives stakeholders evidence to evaluate and demonstrates informed preparation. | “What reflects your experience, and what should we examine further?” |
| Record the stakeholder's own language | The stakeholder’s language reveals what matters to the business and provides evidence for framing the outcome. | “How are you measuring the impact of this today?” |
| Separate operational pain from transformation intent | Relief from today's pain and a change in how the business operates lead to different designs. | “Who needs to agree we have solved this before you would call it solved?” |
Understanding the stakeholder’s perspective establishes the starting point; discovery tests that perspective to identify the problem the design should address.
Knowledge check
Check your knowledge with the following interaction.
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?