ABSTRACT

Introduction Design projects can go awry at the beginning in at least two different ways. The first way is by rushing to design, that is, by jumping into designing a solution for a problem that is, in reality, poorly understood. Someone has expressed a problem (“Our customers complain that our software is confusing”). Someone with expertise has diagnosed the problem (“The customers haven’t read the manual”). And someone generates a solution that logically solves the problem (“We should add a help button to every user screen of the application that will take them to the manual”). Solutions generated in such a manner may or may not solve the underlying problem. A lot depends on the hidden, internal thought processes of the participants and their success at communicating needs and ideas. More than likely, however, the rush to design will result in critical steps, such as gathering information about the problem, to be omitted. The opportunity to discover user-pleasing solutions will be lost. It is easy in large organizations for everyone to assume that these critical, up-front steps are someone else’s responsibility. It is better if everyone takes at least part of the responsibility.