Designers are increasingly dealing with more complex problems. The systems we work with often span both digital and physical domains. Requirements and constraints are more abundant and difficult to articulate. More stakeholders are affected. The workings of the system may be opaque to our clients and us.
One of the biggest challenges of working on such projects is that the problem we’re solving for isn’t apparent. This is not out of ill-will or incompetence; some problems are just difficult to pin down. In The Art of Systems Architecting, Mark W. Maier and Eberhardt Rechtin define what they call ill-structured problems:
An “ill-structured” problem is a problem where the statement of the problem depends on the statement of the solution. In other words, knowing what you can do changes your mind about what you want to do. A solution that appears correct based on an initial understanding of the problem may be revealed as wholly inadequate with more experience.
Facing an ill-structured problem is difficult and frustrating. It’s also not uncommon. Complex design projects often start with a vague understanding of what the problem is we’re designing for, or perhaps we’re solving for several problems that appear incompatible. Solutions are often implicit in the way these problems are articulated.
To do a good job, you must clearly understand and articulate the problem(s) you’re seeking to solve. Stating the problem is the starting point for all that follows; it frames the work to be done. Poorly structured problems lead to poorly structured solutions.
Structuring the problem isn’t something you can expect stakeholders to do. It’s up to you, the designer, to ensure the problem is structured correctly. How do you do it? First, you acknowledge that the initial problem statement will be vague and/or poorly structured. You assume your initial understanding of the problem will be flawed. You then move to develop a better understanding as quickly as possible.
This requires iterating through artifacts that allow both designers and stakeholders to grasp new dimensions of the problem so you can set off in the right direction. The forms these artifacts take vary depending on the type of project you’re dealing with. (Concept maps work well for the types of systems I work on.) You want to establish processes that allow these artifacts to evolve towards greater clarity and focus.
This takes courage. Stakeholders and clients want answers, not vague abstractions. The process of clarifying the problem may point away from initial project directions. Because of this, delving in the problem-definition stage of a project can produce tension. But the alternative — getting to a high degree of fidelity/tangibility prematurely — can lead folks to fall in love with solutions to the wrong problems.
Amazon links on this page are affiliate links. I get a small commission if you make a purchase after following these links.