Civil Engineering Reference
In-Depth Information
TABLE 7.5 Summary of Three Popular Collections of Design Principles and Guidelines
Eight Golden Rules of Design
(Shneiderman, 1998)
Design Heuristics (Nielsen, 1994;
Nielsen and Molich, 1990)
Seven Principles of Design
(Norman, 2002)
Strive for consistency
Visibility of system status
Use of knowledge in the world and
knowledge in the head
Enable frequent users to use shortcuts Match between system and the real
world
Use mental aides and consistency in
information presentation
Offer informative feedback
User control and freedom
Make things visible, enabling the user to
figure out the use of an object by
seeing the buttons
/
devices required
for operations
Design dialog to yield closure
Consistency and standards
Get mappings right and easily
understood
Offer simple error handling
Error prevention
Use constraints to direct users' actions
Permit easy reversal of actions
Recognition rather than recall
Design for error, planning for the
recovery from any possible error
Support internal locus of control
Flexibility and efficiency of use
Standardize (when everything
else fails) in order to avoid
arbitrary mappings
Reduce short-term memory load
Aesthetic and minimalist design help
users to recognize, diagnose, and
recover from errors help and
documentation
user, work, organization, and context to generate a prioritization of usability goals, which then informs
the relative importance of guidelines and leads to the integration of the most appropriate guidelines for
the situation at hand.
7.3.2.7 Summary
As has been discussed, the process of translating the understanding of the work system and its needs into
tangible system designs can be best characterized as highly variable or nebulous. A considerable amount
of interpretation goes into this process of first creating the system requirements and specifications along
with considerable creativity and ingenuity to translate these specifications into actual designs. While
there are several documented methods for this procedure along with design standards and guidelines
and design principles to help guide this process, it is still an art in further need or standardization
through advances in research and science.
This section has provided a cursory overview of some of the popular methods and techniques for the
elicitation, representation, and development of system requirements. It is from this collected knowledge
represented in lists, diagrams, and models that UCD emerges. All of the methods and techniques dis-
cussed, whether they be ethnographic in nature (e.g., contextual inquiry) or modeling tools (e.g., hier-
archical task analysis), have one common link — an implicit focus on users, their needs, and their work.
All of these methods and techniques also have a common goal — the development of the system require-
ments, which will be used to guide the development of UCD alternatives.
As discussed, these methods and techniques used to understand the work system fall within the pre-
liminary phase of the UCD lifecycle (i.e., defining, examining, and representing the work system and its
needs). The knowledge gained from these initial efforts is the fuel used to elicit, understand, and develop
the functional and nonfunctional system requirements. These requirements are then translated into
system engineering specifications, which represent the blueprints for the design and development
process of work tools (i.e., systems, applications, interfaces, etc.). However, it is this understanding of
users and their work that ensures that the system requirements generated are appropriate and useful.
If these requirements are incorrect, then the specifications used to guide the system design and
Search WWH ::
Custom Search