Fil Salustri's Design Site

Site Tools


Scoping design problems

Scoping is that activity which seeks/identifies/defines a “good design problem.” A poorly scoped design problem cannot possibly lead to a good design.

What is design problem scoping?

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.

Why do we scope design problems?

There are many reasons to scope design problems.

As mentioned above, engineers (and designers generally1)) are ethically bound to ensure to the best of their ability that they are balancing the needs of their clients, end users, governments, and society at large. This subsumes both environmental concerns as well as at least preserving if not improving the general well-being of society.
It may be that the designer lacks the resources (financial, time, etc.) to tackle a particular problem. Scoping is an essential component in estimating the resources needed to fulfil a commitment.
It may be that the available technology that would be required to fulfil a design commitment simply doesn't exist. It will not be clear what technologies may be needed, however, without proper scoping.

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.

When and Where do we scope problems?

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.

Fig. 1: People will interpret a simple, clear statement in weird ways.

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:

  • too much energy is being wasted in the building,
  • some tenants complain that it's too hot while others complain that it's too cold,
  • more than average crime rates (e.g., too many break-ins, robberies),
  • tenants near the elevators complain about noise from the machinery,
  • some tenants complain about noisy neighbours,
  • sellers and users of illicit drugs gather near the building,
  • not enough parking for tenants,
  • not enough bicycle parking for tenants,
  • rate of recycling garbage is below prediction,
  • etc.

Notice two key features of these examples:

  1. They all describe the current state of affairs, saying nothing about some eventual design intervention.
  2. They all imply a comparison to an expectation. It is this “conflict” between reality and expectation that marks the imbalance that the designers must resolve.

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:

  • access to information about all aspects of the situation,
  • access to all user groups, and
  • sufficient time and resources to develop and verify a model of the current situation for the sake of identifying imbalances.

Besides the apartment building, some other examples of situations where scoping is necessary are:

  • developing new traffic flow patterns for urban settings,
  • mitigating crime in neighbourhoods,
  • developing “next generation” easily used user interfaces,
  • new household appliances that promote sustainable lifestyle choices,
  • new automotive technology to promote responsible vehicle use,
  • design of charging stations for electric vehicles,
  • developing net-positive houses,
  • etc.

How do we scope a problem?

There are three steps to scoping a design problem.

Step 1: Model the as-is situation

This step will result in a systems model of “how things are.” You need to understand what such a model looks like before proceeding. One way to do this is via a situation scan.

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.

Step 2: Elicit and document expectations

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.

Step 3: Define imbalances

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,

  1. An adequately detailed systems model of the “as-is” situation.
  2. An adequately detailed account of the expectations of agents in and affecting the system.
  3. A detailed description – as quantified as possible – of the imbalances between the as-is and preferred states.

Of course, all data, interpretations, and conclusions must be carefully documented, justified, and explained.


Nothing is perfect

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 can be used for "evil"

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.

Stakeholders vary... a lot

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.

Imbalances are not targets

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.

See Also

While engineers in Canada are legally bound to act ethically, non-engineering designers have no such legal requirement placed on them. However, this does not absolve them from moral responsibility.
“You want to make things better? Better than what?
design/scoping.txt · Last modified: 2020.03.12 13:30 (external edit)