What DSS interface design is 'best' for eliciting values?
by Daniel J. Power
Editor, DSSResources.COM
A person-machine interface is central to the effective use of a computerized system like a decision support system (DSS). The user interface (UI) shapes the user experience (UX). Decision support application developers must be kinowledgeable about user interface design concepts and principles. This article discusses what it means to elicit values in the context of building a model-driven DSS, reviews three approaches for eliciting values, and then proposes some hypotheses and design guidelines for a DSS interface design that is "best" for eliciting values.
When I teach a course about DSS, I often require students to work on a team to develop a model-driven DSS in Microsoft Excel. Students are able to use and improve their skills with Excel and experience the process of decision support design and development. Despite exhortations, many teams do not seem to devote sufficient attention to the design of the user interface. Some student teams have difficulty creating a user interface that supports "what if?" analysis for the decision task. Another problem that is especially notable is associated with eliciting the values for the parameters of the model(s) used in the DSS. Students seem to think that "asking for the value" is all that is required. In general, inadequate attention is given to how values should be entered by the anticipated users of the DSS. In some cases, the order of input fields seems random or disorganized, vague stimuli are often given to the user about what values are sought, an anchor may be used that biases the user, or an inappropriate elicitation approach may be used.
What is a value? Decision analysts sometimes use the term narrowly to mean a measure of worth or utility, but a broader definition seems warranted. In building a model-driven DSS, a designer needs to be concerned about eliciting certain and uncertain quantities and qualities, objective and subjective probabilities, utilities and weights. It may be necessary to elicit probability point estimates, probability distributions, utility functions, monetary values and monetary estimates, preferences, integer quantities, distances, scale values, and priorities. Values can describe objective and subjective measures of concrete objects and appraisals of feelings, beliefs and attitudes. Values may be estimated or based on actual measurement using a scale. The scales may involve physical or perceptual units.
Values are elicited from a decision maker, assessor, estimator or appraiser -- the user of a model-driven DSS. In general, a question or another type of stimulus indicates what value is being elicited. Values are elicited as part of a valuation or elicitation process. The elicitation approach in a specific DSS may reduce or increase errors in the values that are obtained.
A number of years ago, I made a presentation on computerized elicitation of values at a Subjective Probability, Utility and Decision Making (SPUDM) conference (Power, 1987). My presentation focused on three primary approaches for eliciting values: 1) numerical, 2) graphical, and 3) verbal elicitation. In a model-driven DSS, a question or stimulus can directly request a numerical parameter. A graphical object can be manipulated to enter or change a value. A text response from a pull down menu or a free form response can also be used to collect a "value" response. Let's briefly examine the different approaches.
Numerical Elicitation. Directly eliciting numerical values is the most traditional mode of gathering user information about values. Changes in the computing environment have expanded the capabilities for this type of user interface. Colors can highlight input fields and data validation rules can check the reasonableness of values that are entered in fields.
Graphical Elicitation. A slider or spinner type of graphical display is probably the most common elicitation in this category. Also, DSS users may move arrow keys or a mouse to control the height or position of vertical "value-bars" or of a "probability wheel". Also, a simple value line with a scale can be used effectively.
Verbal Elicitation. In one type of verbal elicitation, a DSS user chooses a verbal description from a menu to which the DSS designer has assigned a value. For example, a person may be asked to enter a description from the following choices: certain, very likely, likely, unlikely, very unlikely. A second type of verbal elicitation requests the user to enter a natural language phrase and then the program parses the response and assigns a value based on a rule.
Some people can process certain types of value information much more effectively using visual displays and graphical input modes than they can process them numerically or verbally. Each approach for eliciting values has strengths and weaknesses that a software designer must recognize. Current evidence suggests that unbiased values can be elicited using any of the approaches. Also, none of the approaches is inherently better than the other two for accurately assessing all types of values. The appropriate approach seems to depend on the task and the skill and training of the user. So what advice, hypotheses and design guidelines would I offer to create a DSS interface design that is "best" for eliciting values? Let me suggest 8 hypotheses:
Hypothesis 1: Graphic elicitation is best for providing "what if?" analysis for a decision task. Values used as parameters for "what if?" analysis should be changed using a manipulation object like a spinner or a scroll bar.
Hypothesis 2: Graphic elicitation is most useful when only a few values are elicited and the values are uncertain or may vary over a wide range.
Hypothesis 3: Static objective values are more accurately entered using a numeric input field. When it is possible input validation should be used to ensure that the requested value is in the anticipated range.
Hypothesis 4: Use numeric elicitation if and only if a value can be clearly defined and the elicitation stimulus is unambiguous.
Hypothesis 5: If a large number of values will be elicited, provide for multiple inputs on a single screen and insure that the elicitation is not excessively time consuming and tedious.
Hypothesis 6: Subjective values will be more reflective of a person's opinion, belief or preference if a graphical elicitation method is used rather than numerical or verbal elicitation.
Hypothesis 7: It is most appropriate to use abstract word inputs or anchors for eliciting feelings and sentiments.
Hypothesis 8: If a DSS is eliciting feelings or preferences, a color scale may help a decision maker/assessor input a value. For example, a color scale from dark green to light green, or from light red to dark red with a slider may help capture a person's feelings.
These hypotheses are a starting point for improving the elicitation of values in model-driven DSS. One hopes that empirical studies will provide additional guidance.
References
Power, D.J., "Computer-aided Elicitation of Values," paper presented at Subjective Probability, Utility and Decision Making conference (SPUDM-11), Cambridge, UK, August 1987.
The above response is from Power, D., What DSS interface design is "best" for eliciting values? DSS News, Vol. 4, No. 11,
Last update: 2014-08-17 07:20
Author: Daniel Power
Print this record
Show this as PDF file
You cannot comment on this entry
