Fil Salustri's Design Site

Site Tools


Table of Contents

Problem Analysis

Problem analysis ends when you understand a problem well enough to start trying to solve it.

Since designers generally solve the problems of other people, it is vital that the designer understand the problem from the other's point of view.

A product requirements specification (aka requirements set, or design brief) is a record of the agreement between designers and users/clients on the nature of the problem to be solved.

The question is: How can one extract the real problem from the users/clients?

The users/clients may not really know what they want.

  • They may say they want X.
    • But they may really want Y, and believe having X will get them Y.
    • The designers must figure this out, and at least ensure X is right, or propose alternatives, because Y is the real problem.
    • And the designer also needs to understand why they want Y.
  • They may say they want X, because they already have Y, and Y is wrong.
    • Again, all they know is what's /wrong/ with Y, and /not/ that X is the best solution.
  • In the end, the only thing the users/clients really know is what is wrong with the way things are.
    • This is ideal for the designer.
    • Knowing only what's wrong is:
      1. the clearest possible description of the problem, and
      2. the most flexible way to start a design.

Knowing what's wrong implies that you would know when it was right - or at least better.

  • This denotes an im[balance] between how things are and how they “should be.”

See Also


<refnotes> notes-separator: none </refnotes>

research/problem_analysis.txt · Last modified: 2020.03.12 13:30 (external edit)