Scoping is that activity which seeks/identifies/defines a “good design problem.” A poorly scoped design problem cannot possibly lead to a good design.
Design ought not feed into unsustainable excesses or benefit some at the avoidable expense of others. Some may believe in “giving people what they want,” but this implies that user communities are constituted of rational agents. The fact is that no agent is always rational. It becomes an ethical obligation of designers, then, ensure that designs they conceive address appropriate needs, to the best of their abilities.
No matter what the origin of a design problem, the task of defining a “good” design problem is a scoping exercise.
There are many reasons to scope design problems.
The purpose of scoping a design problem is to develop a model of how things are now, from which one can determine aspects that all stakeholders can agree are wanting. From such a model, one can determine the scope of the impact of a successful design intervention as well as the key systemic factors that any successful intervention must address.
Some design problems are so specific that all scoping issues are clearly stated in the design brief. Designing simple parts and small components of machines fall into this type. However, this doesn't mean that one can patently ignore scoping. For instance, say we have two alternative designs for a small part (a structural flange in a stapler, for instance). One can still strive to make the part of an easily recycled material, the production of which has as light an environmental footprint as possible, and the manufacturing of which requires a minimum amount of energy.
But even this is not possible if we do not have a baseline - a description of the way things currently are - against which we can assess our designs for potential improvements.
As problems become larger and more complex, scoping becomes more and more important.
Consider the design of apartment building. Some information will be provided in the design brief, but that information is almost certainly incomplete, and likely incorrect at least in part. An obvious first step is for all stakeholders (especially the client and the designers) agree on the meaning of the design brief's content. But beyond verifying the brief, you need to understand how things are before you can hope to find a way to make them better2). After all, there's really no point in designing anything if you can't make things better.
You will need to consult widely with all the user groups, because each group will have different priorities and preferences, but they will all interact with that building you're going to design. You will have to reconcile those different priorities and preferences to ensure the maximum benefit to everyone. Even within a single company, you can end up with a simple design brief (“I need a swing!”) that is misinterpreted by different specialists in the company.
Scoping is motivated by a perceived shortcoming in how things are. In the case of the apartment building design, the perceived shortcomings might be any (combination) of:
Notice two key features of these examples:
It is not enough to simply list - as is done above for the apartment building - the known imbalances. The designers must fully understand all the system relationships between agents and objects in a situation to determine with acceptable precision and confidence what the real problem is. That's the point of problem scoping.
To carry out a good scoping exercise, designers need:
Besides the apartment building, some other examples of situations where scoping is necessary are:
There are three steps to scoping a design problem.
Setting aside all thoughts of what you might design, determine the extent of the system into which your design intervention will be introduced. This sets the boundaries of the overall system into which your design intervention must “fit.”
Next, identify all the agents, resources, and other entities, at a scale comparable to the level of the design intervention you are targeting. For instance, if you're designing a car, the overall system will include roads, garages, people, other vehicles, gas stations, road conditions and weather, etc.
Lay out a system diagram that includes all these entities.
Now carefully describe how the entities interact. This means describing the flows of mass, energy, and information that move from one entity to another.
Make sure you validate the system diagram as widely as possible - with all user groups and stakeholders, as well as analysing it to see what items you may have forgotten or gotten wrong.
Given the system diagram of the as-is situation, now you need to identify what's wrong with it. Identifying these shortcomings will be done with respect to the expectations of the various user groups. This means using the system diagram as a mechanism to engage the user groups, for the sake of identifying what they think is wrong with the as-is situation.
You'll be asking your user groups to describe what is wrong with the as-is situation; but what you really want is to identify the underlying expectations of the users. For instance, patients may say that wait times in health care clinics is too long. That's a statement of what's wrong with the as-is situation. What you really want, though, is to know what the patients' expectation is of an appropriate wait time. Also, you'll want to know which flow(s) in the system diagram are where the delays actually are.
Make sure these expectations are carefully documented.
Based on the system diagram and the expectations you've elicited from your user groups, you now quantify the imbalances between the “as-is” situation (i.e., Step 1, above) and the expectations of your users (from Step 2).
Ideally, these imbalances will be quantified. For instance, the patients may say that (a) wait times after registering for a visit and before being called to the examination room is too long, and that (b) their expectation is to spend no more than 10 minutes waiting. Let's say you know from your study of the “as-is” system, that wait times average 30 minutes, +/- 10 minutes. The imbalance here is a mismatch of a factor of 3 (or 300%, or however you decide to quantify it).
Exercise for the reader How do you think time of day might impact wait times? That is, do you think it would matter if the patient went to the clinic at 11:00 in the morning versus going at 5:00 in the afternoon? What influence do you think that might have on both the as-is wait times and on the patient's expectations? What might you do to incorporate this into your scoping?
Document each of the imbalances you find, linking them back to both the features of the as-is system and the user groups' expectations: you'll need, in the long run, to be able to justify everything you do with respect to improving the as-is situation, and this is how you will be able to do that.
The deliverables of a scoping exercise will typically consist of the results of each of the three steps described above; that is,
Of course, all data, interpretations, and conclusions must be carefully documented, justified, and explained.
The “as-is” system model will not necessarily capture every necessary feature of the actual situation and you have no way to know if you missed something (because to do know this, you would have to be able to predict the future). Remain flexible to changing your model as new information comes to light.
Scoping, like any other tool, can be used to improve overall well-being, or worsen it. Scoping, when well done, embodies an ethic of sustainability, well-being, progress, caring, and diligence. However, the ethic is only implied and cannot be checked and verified. It pays, therefore, to be careful when considering the scoping exercises of other groups, organizations, and institutions. If scoping is carried out without a proper ethic, then designs that result will very likely end up degrading the situation rather than improving it.
How do you know if your stakeholders have reasonable expectations? They are certainly not domain experts, so they cannot be expected to self-assess whether their expectations are reasonable. For instance, some people may legitimately expect to walk into a doctor's office and be seen by a doctor within one minute of presenting at the reception desk. They may have perfectly good personal reasons for this, but the expectation is nonetheless entirely unreasonable.
In the end, this task is best done from a demographic point of view: to petition input from stakeholders, and then build a statistical database of their responses. To do this, however, requires understanding all the stakeholders and possibly categorizing them into clusters to make sure trends are visible. For instance, in the case of wait-times at doctors' offices, there may be one trend among patients under 50 years of age, and a different trend among patients over 50 years, and the two trends might cancel each other out (at least partly) if you put all patients into one cluster.
Because of the concerns noted above, imbalances are not necessarily precise enough to be targets of your design intervention that you must achieve for success. These imbalances may, however, point the way towards better circumstances than the as-is state, and so provide a way to measure relative success over time.