A problem space is the part of a domain where a team explores and defines the business challenges, needs, concepts, and complexity a software solution must address. It is deliberately separate from the solution space: first build a deep, shared understanding of the problem; then design, implement, and test possible responses. section 2.3.1 section 9.1.3
The distinction prevents a familiar failure mode: proposing architectural or implementation alternatives before everyone agrees on the problem. Treating the problem space as a frame for discussion helps participants clarify the issue, examine it from different perspectives, assess the business situation, and create appropriate options afterward. section 9.1.3
Figure 2.6 The problem space is where we use collaborative modeling to make models of the user/business needs, which can be goals, tasks, purpose, intent, and much more. The solution space is where the output of our design activities is placed. We perform a variety of design activities to go from the problem space to the solution space. With collaborative modeling, we iterate on our design to improve our models to solve the needs of the problem space.
Use this diagram to orient a session: model user and business needs in the problem space, place design outputs in the solution space, and iterate between them as understanding changes. section 2.3.1
Work the problem space collaboratively rather than handing it to a single role:
- Bring together stakeholders to establish a shared view of the challenge and the domain knowledge behind it. section 2.3.1 section 2.6
- Create visual, interactive models of needs such as goals, tasks, purpose, and intent; use them to make uncertainties and competing interpretations discussable. section 2.3.1
- Use a modeling tool that fits the question being investigated: a Business Model Canvas for strategy and business model, EventStorming for processes and domain events, Example Mapping for actionable user-story details, or Domain Storytelling for interactions and cooperation. section 2.6
- Develop more than one possible model or solution, weigh their trade-offs, and test them in real conditions rather than treating an attractive design as proven. section 2.3.1
A route can become part of the problem
Finding a route to the Rijksmuseum begins with a map of the journey problem. Biking may look like the fastest solution, but bike theft or repeated traffic lights introduce new constraints. Update the model with the selected route and its obstacles, while keeping sight of the original travel need. A chosen solution can therefore create new problems or become part of the evolving problem space. section 2.3.1
A problem space is not a one-time discovery phase. Customer-adopted solutions, changed goals, and newly exposed obstacles can feed back into it. Revisit models when the problem changes, and use the resulting understanding to improve later design decisions instead of defending an earlier answer. section 2.3.1 section 9.1.3
Useful prompts for a collaborative session include:
- What problem are we actually trying to solve, and can every participant describe it clearly? section 9.1.3
- Which perspectives reveal a different aspect of the problem or business situation? section 9.1.3
- What does our current model leave uncertain, and which stakeholder knowledge could validate or revise it? section 2.3.1
- Have new effects of a proposed solution changed the problem we need to address? section 2.3.1
