It’s almost redundant to talk about aggressive project schedules. The constantly evolving demands of markets, strong competition for market leadership, and increasing expectations for engaging user experiences require rapid delivery of products and services. While delivery may have to meet these schedules one way or another, true innovation rarely follows a Gantt chart so docilely. Integrating idea exploration and innovative thinking into the typical project can be a challenge.
The right project culture can encourage innovative, even when facing tight deadlines. What defines the “right” culture for a development team will necessarily vary; however, certain tools can be used across all. One of these is the philosophy of problem space and solution space.
I’m indebted to my colleague Dusty Pressley, a software architect, who introduced this phrase to me years ago. He and I were discussing the challenges of trying to deliver innovative solutions while maintaining the aggressive delivery pace our clients needed. “I try to stay in the problem space as long as I can before moving into the solution space,” he said. This stuck with me as one of the most useful ways of approaching product development I’d heard then or since.
I use the term “philosophy” to describe problem space thinking and that is how I’ve applied the idea in my work. Staying in the problem space is not to be confused with analysis paralysis. Nor do problem space and solution space simply recast the development life cycle as a two-step process. They are states of mind that can be brought to bear in any stage of development.
Being in the problem space is about questioning and openness. It looks at broader, more philosophical questions, such as:
- Why is this feature needed?
- What benefit does this bring to users over a different approach?
- How will this improve how users do their work today?
- How does it fit into their current toolset?
Being in the problem space is not just asking a standard set of questions, though. It is about discovering questions your users and market have and also refining those questions for the unique characteristics of the current project so that you can be confident you are asking the most complete and most important questions. Asking the right questions is typically harder than answering some generic set.
Even worse than asking the wrong questions is not asking any at all. I decried the “pretty picture,” which is an example of moving a visual design into the solution space without having a chance to explore the problem adequately if at all. Moving too quickly into the solution space is not a problem unique to visual design or any aspect of user experience, but affects functional requirements, software architecture, and all other areas that contribute to product development. Without a clear and comprehensive understanding of a problem, teams cannot define and develop the most effective, innovative, or delightful solutions.
The problem space is not limited to discovery and analysis phases, although those will be the traditional places where this mindset is most encouraged. It should carry into design and often even into implementation. In addition to asking meaningful and valuable questions, staying in the problem space is establishing a mindset of regular self-critique. Practicing this philosophy challenges my assumptions at every stage and helps me avoid moving too quickly into comfortable patterns or assuming that the current users are similar enough to another set that I can generalize broadly.
The distinction between problem space and early development phases can be hard to explain. Let me share an experience I’ve had when presenting on usability requirements. In one variation of that presentation, I discuss using “sketchlets,” conceptual designs of limited and incomplete yet self-contained chunks of functionality that are useful to spur requirements discussions and evaluation of requirements. Since I talk about requirements being part of the analysis phase prior to design, someone asked why I did not consider sketchlets to be design deliverables. While I agree that these are first steps toward design, because they are intended to be questions not answers, I consider them part of the problem space, not the solution space that design starts to enter.
At some point, you will have collected the most meaningful questions and will have at least partial answers for each of them. This is when you transition into the solution space, which is characterized by answers and concrete definition. The solution space is about developing statements, such as:
- This feature will serve users’ specific need for X.
- Design A is more efficient than Design B because it reduces the steps to complete the task.
- Design A will result in less errors than the current system.
- Design A extends users’ current toolset to reduce rote work and provide greater analysis tools.
These statements are intended to answer the questions that emerged in the problem space. Moving into the solution space is rarely a clean transition from the problem space. Some questions and exploration continue, but the focus becomes less on the questions and more on working toward answers and continually refining the solution to the problem.
However, if you are still struggling with the problem state questions when you start designing and developing solutions, you may be at risk of heading toward a poor solution in the name of a hard deadline. Because this happens often enough in development, the philosophy of the problem space is an important one. Project plans usually focus on budget and deadlines, only two elements of the classic time-money-quality triangle. Cultivating a culture that encourages teams to stay the problem space – even while moving forward on the development schedule – can bring quality back into the balance.
You may find that such a culture readily emerges for some teams. The philosophy of problem space and solution space fits comfortably with many development methodologies. Encouraging questions and exploration in every phase of the development cycle is the same sort of thinking that underlies the Agile Manifesto principle of welcoming changing requirements at any stage of development. It is the foundation of any iterative development process, including the user-centered design process.
In the face of the dual challenges of moving steadily toward ever tighter deadlines and of meeting the increasingly sophisticated demands for better and more engaging products, the philosophy of problem space and solution space supports opportunities for innovation and creativity and, in my experience, always improves the end product.
