INTRODUCTION
What engineers do

ARTICLES ON ENGINEERING
Engineering Thinking
Understanding Problems
Design Methodology

ARTICLES ON SOFTWARE
Software visions
The software artisan

Understanding Problems

Designers make artifacts --- machines, buildings, circuits, or programs --- in response to needs in the environment. The current state of things has a deficiency, a lack or an encumbrance, and a better state can be envisaged. The designer is presented with the start state and the goal to be achieved, and given the job of getting from one to another. The gap between the start and the goal states is called the "problem", and the process of achieving the goal is called "solving the problem".

Problems come in many different sizes. Big problems are usually "solved" by a high-level design that turns them into sequences of small problems. But, large or small, a problem needs to be defined explicitly in a problem statement. Solving the wrong problem spells defeat for a project, so it is vital that the problem is understood and agreed by everyone concerned.

A problem statement is not just a passive or vague description of what might be, it is a specific and searching definition of lacks and deficiencies, reserving judgement on solutions, so as to map the farthest boundaries of the space of possibilities. It focuses the designer on what the real problem is, while allowing the greatest freedom in solving it.

During and after problem definition a designer spends time researching the problem domain. There may be good existing solutions. Almost certainly, there will be something to learn from previous work. The aim is to know the problem context well -- to become a (temporary) expert in the application area.

This article explains first how to formulate a problem statement, then discusses problem domain research. Research starts while the problem statement is being developed, but it continues throughout the project. The first part of the article is therefore about a step in the process - defining the problem, while the second part is about continual learning that only ends when the project does. A final section deals with understanding human users -- a common requirement of many engineering projects, and of most software systems. Users should be thought of as part of the problem domain; neglecting their role in the existing state or the goal state is like forgetting the system's most critical component.

The Problem Statement

A problem statement should capture the key issues concisely and systematically, making assumptions, limitations and goals explicit.

Here is a four step recipe for writing a problem statement:

The new state should be described only in terms of what it enables, not how it is done. The object is to avoid even implying a solution, until the problem is well defined.

The constraints are the economic, physical, time, accuracy, limitations on possible solutions, and on the design process itself. Constraints are things which must be satisfied in a design if the solution is to work at all. They are non-negotiable.

The criteria are ways of measuring the value and worth of the engineered product. They are the explicit answer to the question How will I know I have succeeded? The importance of asking this question at the Problem Statement stage cannot be overemphasized. Indeed, in some ways the whole engineering method is based on this simple premise: Success has to be explicitly defined in measurable terms at the outset. This is not to say that criteria will not change during the project. But even if they do, it is important to know at each stage, what the rules for success are.

Although the problem is stated independent of possible solutions, this does not mean that problem definition is done in a vacuum, devoid of scientific knowledge or insight. It is the designer's responsibility to judge whether the problem is of a scale that can be practically solved. This may mean ensuring that the criteria are reasonable given the current state of the art.

By carefully following these four steps, you can set out the framework for the design, and take the first (big) step towards solutions.

The purpose of this section is to show the value of explicitly stating the problem, whatever the scale of design. These examples stop at the problem statement, but where the example is taken from real life, a solution is given in the following Solutions section.

A. In his book, Programming Pearls, Jon Bentley gives an example of elegant problem solving. Lockheed engineers wanted to transmit engineering drawings between two plants, about 25 miles apart. About twelve drawings were to be sent each day. How was this to be done?

The full problem statement needs more data, but first the information given so far needs fixing. Already, in two sentences, there is a potential limitation on the solution space - one that is unnecessary. The word "transmit" usually carries connotations of electrical communications (radio or wire), so even though it does have a wider meaning, it is best to avoid it. Let's replace it with transfer in the full problem statement.

1. Drawings are generated at A; they are required at B. About 12 must be transferred each day. Currently there is a solution: a car courier service which takes over an hour and costs $100 per day. The drawings are originally generated on a CAD system. There is a microwave data link between the two sites. Both sites have photographic processing facilities.

2. A cheaper and faster reliable transfer method is desired.

3. There is no appropriate plotter or printer available at B. (The date of this example is 1981, so the cost of such a printer was high.) At least 99% of drawings should be transferred correctly.

4. A service providing transfer time less than one hour, at a cost of less than $100 per day will be judged a success, since it betters current performance. The faster and the cheaper the service, the better. The sooner the service starts the better, so as to curtail the $100 daily charges.

Note that by thinking explicitly about constraints, we have considered reliability, and made a judgement about how many errors are tolerable. If the current system is error-free (as presumably it is), we might otherwise not have considered how important errors are.

See if you can go from this problem statement to a solution.

B. Recently, I was asked for advice on the solution of the following problem.

A multinational manufacturer of household products wishes to improve the productivity of product marketing managers who are involved in preparing TV commercials. In particular, these managers are to be given much faster access to videos of earlier commercials of their products, as advertised around the world.

Let's formulate the problem statement:

1. There are libraries of videotapes scattered about the world, in the various national and regional offices of the corporation. To gain access to a particular commercial, the manager submits a requisition, which is processed by the local library, then sent on to remote libraries. The appropriate clips are copied at the remote libraries then sent back to the originator. The turnaround time is typically two weeks. Project managers have personal computers on their desks, with multimedia facilities. Broadband communication is being introduced throughout the corporation: this will allow MPEG-coded video to be distributed to people's desktops. Very often a manager does not know exactly what is required and can only formulate the requisition vaguely. A lot of knowledge resides in the librarians' heads -- they are a key resource in finding and suggesting clips.

2. A faster delivery of videos is required. (The assumption is that creation of new material is indeed helped by reviewing previous commercials, and those from other countries and markets.)

3. The amount of time the manager spends in requesting the information should not be increased. The specialized advice of librarians should not be sacrificed.

4. A system which delivers videos within the day will be a success. A system which enhances the value of librarians' expertise will be a success.

Note that when originally posed to me, the key role of librarians was not clear. This information came out by asking questions to get at the constraints and criteria. The statement of success in the criterion "within the day" was crucial. Had success been on the criterion of immediate access, then an interactive on-line database system would be essential. (People who work in multimedia systems often believe the interactive on-line databases are essential.) But providing this would possibly be outside the limits of what can be afforded. It would also be an open question whether a database access system could be made sufficiently powerful that the manager's time would not be increased.

See if you can go from this problem statement to a solution. It might be different from mine, but I hope that by having the statement explicated formally, you avoid some of the traps.

C. Teachers often answer questions by questioning the assumptions of the questioner. In a way this is equivalent to formulating a problem statement. Typically what the teacher is doing is asking:

1. What do you know already, and what do you think of it?

2. What piece of wisdom do you believe there to be and why do you think I have it?

3. What is the context?

4. What type of answer will satisfy you?

I have learned to apply this technique in concrete situations. For example, students often ask me a question like, "How do you do XYZ with a linked list?". It took a long time for me to learn not to try to answer the face-value question. Instead I now handle this with questions like:

1. Why are you using a linked list for that? Why not an array, for example?

2. What will be the benefit of doing XYZ? Why not ABC?

3. Is this a language issue, an algorithm issue, or what?

4. No seriously, why are you using a linked list?

(Incidentally, almost all problems like this are posed as procedural/algorithmic problems, and almost all turn out to be data structure problems really. There are different ways of expressing a problem, and teaching yourself to question your perspective is good policy.)

A. The solution adopted by the Lockheed engineers was to photograph the drawings at site A, send the film by carrier pigeon to B, where it was enlarged and printed. Only two pigeons were lost in hundreds of flights, the average time was 45 minutes and the cost was a few dollars per day.

B. I suggested replicating the entire video database at all sites and enhancing the librarian's communication facilities. Assuming that there are 50 operating regions, that two unique commercials per month per region are produced, that a 30 second commercial has 3 or 4 minutes of outtakes preserved with it, and that TV commercials have been produced at this rate for 40 years, the total database is less than 4000 hours in length, easily stored compactly on Super 8 cassettes. Librarians would still be expected to be most familiar with material produced in their region, and would be called to advise about what to extract from the local library. Librarians would be given opportunities to get to know each other, and would collectively develop protocols for exchanging information quickly by phone. Communication between librarians would always be fully available (no blocking).

The problem statement is the raw abstract material of engineering, in the same way that the hypothesis is the raw abstract material of science. Sometimes, though it is near impossible to express a software project in the form of a problem, or to do so would be trite. For example, what problem is a Word Processor aimed at? The gap between people's ability to compose text, and their handwriting skill? The gap between their creative goals in writing and the way the process is encumbered with details like spelling and grammar? The gap between unformatted typewriter output and typeset print? None of these is a good, concise problem statement. Can you do better?

Researching the Problem Domain

To design before understanding the problem is to invite disaster. Incomplete information is a fact of any project (especially in software), but the generalities of the problem domain can be researched. Familiarity with that background is vital for competent design.

Every problem domain has a literature that the problem solver can use for background research. In software, this literature is just as frequently accessed electronically as in a paper library.

The main resource that an academic library has for the problem solver is periodicals. Much that you need may be in books, but if you can find the right journal or magazine reference, it will probably be more helpful. First, the journal article will deal specifically with a problem like yours; second it will be relatively concise; third it will probably yield a good set of references to related and relevant work.

How do you find that correct article?

It usually takes at least three steps to get to the right article. First find some fairly recent article somewhere that talks about the problem of interest. The only criterion for this publication is that it should have a good length citation list (or list of references). Next, use that list to start looking for a "pivot" reference. This is usually a paper from the early days of a young field, or, if you are working in an old field, about ten years old. Such a publication is like a fulcrum on which rest two other sets of references. Those that the publication cites obviously predated it and give not just the development of the subject, but probably more detail on some things the pivot reference left out. More recent works which cite the pivot form the other set of references. Through the invaluable Science Citation Index (and other citation indices), you can follow the influence of a particular paper forward from its publication date. If you do not know how to work the Science Citation Index (either in its paper form or on CD-ROM), you should learn the skill immediately. Almost certainly, if an author developed a significant technique, or perhaps the first solution to a significant problem, the forward references that the Science Citation Index gives will lead you to important improvements or additional relevant evidence. The process is illustrated in the following diagram.

You will rarely be lucky enough to get from the start reference to the pivot to the one you want in just two jumps. But as you practice using the library you will gain skill in judging paper titles and journal titles so that the number of false trails you follow is minimized.

What about if you do not have any literature reference to start from? My advice is to find a periodical in the general area of the problem, and browse through the last five year's publications. If there is anything to be found, you have a good chance of hitting an article of direct relevance or a reference to work in the area which will send you towards a more appropriate source. In any event, this browsing will help you become familiar with the problem domain.

Editorial note: This article was written in 1993 just before I first encountered the web. I have left it unchanged, so this section seems very dated. However, the advice is not obsolete, just limited.

An increasing number of programmers have direct access to the resources of the Internet. These are by no means trivial; many problems can be addressed without leaving your computer, simply by careful and informed use of network facilities. In problem solving the main two resources are network news and anonymous FTP sites.

If network news is available on your system you will probably know about it. It will be accessed (if on a Unix system) through a program such as rn or vnews. Ask advice locally if you do not know how to get at news.

The huge number of newsgroups carried on the Internet includes many dealing directly with both the technology, and the typical problem domains of software designers. Examples like comp.graphics, sci.math.num-analysis, sci.engr.mech illustrate this. (There are of course many recreational newsgroups too which can be fun but perhaps more of a time sink than you realize). Because readers and posters to most newsgroups include some who are reasonably expert, there is a good chance of getting an answer to specific questions. Asking vague questions ("Can anyone tell me about fractals?") is not worthwhile; although asking for references often is ("Can anyone tell me where to find out about fractals?"). There are several rules of newsgroup etiquette, but the most important one in terms of researching an unknown problem domain, is read the FAQ. The FAQ is the Frequently Asked Questions List of the newsgroup. There is an FAQ for most of the technically-oriented groups on the net. They are usually maintained and posted by someone knowledgeable, and contain the best information distilled into the smallest space. FAQ lists are posted periodically (usually about one a month), and are not supposed to expire until their repost, but local news software often makes them disappear before that. It might be necessary to read a group for a few weeks before venturing forth with queries and requests for help. Usually, though, if something is urgent, there is an inoffensive way of asking about it. (There is a high likelihood that someone will take offence at anything said on the net - this is its disadvantage.)

A response to a newsgroup question often refers to documentation or program code available at an anonymous FTP site. FTP stands for File Transfer Protocol, as well as being the name of the command on most Unix (and other) systems that allows you to contact remote sites and exchange files with them. An anonymous FTP site is one you can connect to and log in as user "anonymous", thereby getting access to the information stored at that site. Some anonymous FTP sites are huge repositories of freeware and shareware for personal computers or Unix systems; others are much more focused. Some allow you to upload materials, though this usually has to be done by mailing to an archive site administrator, to avoid misuse. Use of the FTP program is simple.

Two more facilities that you can use if they are available are archie and gopher. Archie allows you to do filename search across anonymous FTP sites. That is, if you know what files you are looking for, or even can guess at likely filenames, you can ask archie which anonymous sites have copies of those files. Implementations of archie usually incorporate the service to recover those files from the appropriate remote site. Gopher is a program that allows sites to set up information services via a network of servers. As usually implemented it gives access to popular remote sites. Indeed, gopher invisibly gives access to some of the most interesting on-line documents, just by browsing through its directories. More advanced global information services include the "World-Wide Web", a multimedia, hypertext-linked system, growing very quickly and becoming popular. See the reference list at the end of the chapter for books on even more network goodies.

The network can be amazingly bountiful. People will give you free advice, free criticism (not all bad) and free code. You are well advised to be prudent, legally, and in program building, so far as free code is concerned. But take whatever help you get. The net is a fragile organism -- it might not always be so friendly or so free of regulation. By sharing what is offered and being generous (so far as you are allowed) with your own advice, you help it work.

Understanding Users

The user interface now comprises the majority of code in a majority of personal computer applications. Understanding users would therefore seem to be a prerequisite for software design.

Understanding users is such a large subject that it is impossible in a book of this size to give adequate coverage. The references at the end of the chapter point towards good treatments.

What we really seek in defining a problem is measurable criteria. Unfortunately criteria related to the interface are usually only measurable by subjective tests which can be long and expensive. When they can be afforded, the design process iterates as alternative techniques are tried and tested. (Part of the research effort in user interface design is in developing models that can give quantitative predictions of interface performance. Such models might avoid some of the subjective testing iterations -- but they are still tentative and difficult to apply.) Because quantitative analysis is so hard to do, it is still worth searching for and applying qualitative guidelines.

It is important in choosing guidelines to make sure that they are well defined. For example, the advice "Make the interface simple" is so ambiguous as to be useless. Which is the more simple: a controller with two buttons which are heavily overloaded with functions, or a controller tightly packed with single-purpose buttons? It depends on your definition of "simple". Unfortunately too many interfaces have been justified as being "simple" according to a private definition of the designer. A similar complaint can be made about "Make the interface logical". The logical structure of the interface may not be visible to the user, who wants structure but not abstraction. There are few excuses for the designer who says "It's simple and it's logical". After all, people are neither.

A much better guideline is "Make the interface consistent". Although still vague, it has the virtue that it follows directly from observations of human performance. The source for this and most other valuable guidelines is cognitive psychology, and the table below summarizes results from that discipline that can be directly applied to interface design.

Shneiderman (see refs at the end of the chapter) distills results such as those in the table into "Eight Golden Rules of Dialog Design" that can be applied to user interfaces in general. These are summarized:

1. Strive for consistency. Use consistent terminology in menus, prompts, error messages, etc., use consistent screen layouts; similar actions should do similar things in similar situations.

2. Enable frequent users to use shortcuts. For example provide command key equivalents to menu selections.

3. Offer informative feedback. Give feedback for every action, appropriate to its importance -- modest feedback for minor actions; substantial feedback for major actions.

4. Design dialogs to yield closure. Every sequence of actions should have a beginning middle and end; it should be clear when a particular group of actions is complete.

5. Offer simple error handling. Try to prevent serious errors; make error messages clear and concise and error correction easy.

6. Permit easy reversal of actions. If actions are easily reversed, the consequences of error are not bad and the user has confidence.

7. Support internal locus of control. (This is Shneiderman's term, you may prefer to think of User-centred control). Make users the initiators or actions rather than the responders.

8. Reduce short-term memory load. Provide cues to the user about what their options are. Menus and form-filling interfaces do this. Windows allow the user to maintain their own visual context.

To see how principles such as those from the table and Shneiderman's Golden Rules work in practice, we will briefly survey the four most common interaction styles. These are Command-line Dialogs, Menus, Forms, Iconic Direct Manipulation.

A command-line dialog is a sequence of textual commands and responses. It is a serial conversation between the user and the computer which uses a precise and concise artificial language. Interacting with the MSDOS prompt or the Unix csh are examples of command-line dialogs. With the increasing penetration of Direct Manipulation Iconic interfaces like Microsoft Windows, command-line dialogs are becoming less common. They still form a component of many important systems though. They are also the easiest kind of user interface to program.

Research has been done into the best way to name commands and the best command-line syntax. "Best" can mean ease of learning, accuracy of remembering, efficiency, etc.. In general, subjective tests yield the following guidelines:

1. Names that suggest concepts are better than mnemonics or arbitrary names. The more specific the name the better.

2. Use a consistent syntactic structure. For example, similar commands should interpret their arguments in the same way.

3. Provide an aliasing capability for experts. Users can then customize the system to use whatever names they prefer for commands.

Command-line interfaces have the advantage over menus that new commands can be added easily. They also consume minimal screen real estate, and, for experts, can be the fastest way of inputing commands. These advantages over menu systems are minimized in newer menu-based interaction schemes as discussed below.

A menu provides the user with a limited list of options. These can be either commands (verbs/actions) or arguments (nouns/objects). For example, the Macintosh finder has a menu across the top of the screen. Choice of an item from this "Menu bar" causes another menu to "pull down". A command can then be selected from the pull-down menu. The finder also shows windows that correspond to "opened folders" within which document and application icons are displayed. These windows are also menus, but they contain objects rather than commands.

There are many research questions in menu design: how to order items, how to put things in a menu hierarchy, how to select from menus, etc.. The main guidelines that come out of this research are:

1. Use descriptive names for menu items. Make them familiar but distinctive. The more specific the name the better.

2. Order items in groups according to meaning. Where there is no semantic or structural organisation, order items alphabetically.

3. Broad-shallow menu trees are usually better than deep narrow trees. That is, if there are many items to be organised into a hierarchical menu, minimize the number of layers in the hierarchy even if that means there are many choices at each level.

4. Allow shortcuts for experts.

Menus have several advantages over command-line interfaces: they eliminate or restrict the types of errors the user can make; they give cues about alternatives so can be used for exploring the system. A particularly interesting property that the Macintosh finder exemplifies is that menus project (and reflect) system structure; users do not think about opened folders as submenus though that is what they are. The structuring of the menus is used as a way of organizing information and projecting a particular model of the system.

Traditional complaints about menus are that they can be cumbersome for experts, they consume screen area and that it is difficult to add or change alternatives. The first can be overcome by shortcut command-key equivalents, the second by transient menus such as "pull-down" menus, and the third is possible (where appropriate) in many modern systems.

Form-filling interfaces fall between command-lines and menus in several ways. From menus they inherit good features: they can give feedback about available options, guidance in sequential actions, and can help form a structured user model. From command lines they inherit the ability to input fully variable parameters where necessary. If structured well, forms allow the presentation of a lot of information at once and give the user the flexibility to fill in fields in whatever order they wish.

Some guidelines from the literature on form-filling interfaces are:

1. Group fields logically and in an orderly structure. Ensure consistency between screens.

2. Use descriptive names for field labels, and make the difference between labels and entry fields clear.

3. Allow flexible and easy cursor movement so the user can complete the form in any order and can return to fields to edit them.

4. Make it clear to the user when all necessary fields are complete.

Well-designed forms can have a learn-by-example quality where sample entries are given to illustrate how the form may be completed. Databases and spreadsheets usually have form-filling interfaces.

In a direct manipulation interface the objects of interest are continuously represented, the user makes physical actions to manipulate those objects with immediate visible consequences, and operations are rapid, incremental and reversible. Examples of direct manipulation interfaces are the winder used to set the position of hands on a clockwork watch, most video arcade games, WYSIWYG (What you see is what you get) word processors and display editors and spreadsheets. Many direct manipulation interfaces involve heavy use of graphics (Graphical User Interfaces - GUIs) and icons. Examples are the Program Manager in Microsoft Windows and the Finder in the Macintosh.

The pioneering work on Iconic Direct-Manipulation interfaces was done at Xerox Palo Alto Research Center in the 1970s. In the development of the Xerox Star, extensive work by graphical designers and psychologists yielded guidelines for design of such interfaces. Here is a summary:

1. In icons, aim not for fidelity but for economy and distinctiveness.

2. Use similar visual cues for similar things, and avoid ambiguous cues.

3. Aim to create the illusion of manipulable objects that can be directly manipulated.

4. Help users focus on the key information (by sparing use of highlighting, modest colour

schemes, etc.)

5. Use subjective tests.

Indeed, subjective testing could be included as a guideline for any interface design. One of the key contributions of Xerox was to show how important it could be in designing an elegant and effective interface.

References

Guidance on harnessing the resources of a library is available in many Study Methods books. But the best strategy is to go to an information session hosted by the library, and use it. There are several books on the Internet. Like most users, I find experiment to be the most fruitful way of discovering resources. The following book, is, however, a very thorough summary of what is available:

E Krol, "The Whole Internet: Users Guide and Catalog", O'Reilly, 1993.

The following books give good coverage of some of the important topics in user interface design.

R W Bailey, "Human Performance Engineering", Prentice-Hall, 1989. This is also a good book on design methodology in general.

R M Baecker, W A S Buxton, "Human-Computer Interaction", Morgan Kaufmann, 1987.

K R Boff, J E Lincoln (eds.) "Engineering Data Compendium: Human Perception and Performance", Imprint of Wright-Patterson A.F.B., Ohio: Harry G Armstrong Medical Research Laboratory, 1988.

D A Norman, "The Design of Everyday Things", Doubleday, 1990. (Originally appeared as "The Psychology of Everyday Things", Basic Books, 1988.)

M S Sanders, E J McCormick, "Human Factors in Engineering and Design", McGraw-Hill, 1987.

B Shneiderman, "Designing the User Inferface", 2nd. ed., Addison-Wesley, 1992.

B Laurel (ed), "The Art of Human-Computer Interface Design", Addison-Wesley, 1990