Semiotic Design and Evaluation Framework - Cross-Cultural Human-Computer Interaction and User Experience Design - page 34

indeed, they cannot be complete. For any nontrivial system, there is an infinity of pos-
sible usage scenarios. The incompleteness of scenario descriptions is an important
property but not unique to scenarios. The only complete specification of a system
is the system itself, and the only complete specification of the use of a system is an
infinite log of its actual use, along with comprehensive cognitive and social analysis
of that log” (Carroll 1990b cited from Carroll 2000, p. 255). Scenarios can be either
simple or complex, can describe either a partial interaction, or a whole unit. As an
example, we can cite (we separated the interaction sentences in lines):
A person turned on a computer, the screen displayed a button labeled Start, the person
used the mouse to select the button.
(Carroll, 2000, p. 14)
An accountant wishes to open a folder on the system desktop in order to access
a memo on budgets. However, the folder is covered up by a budget spreadsheet that
the accountant wishes to refer to while reading the memo. The spreadsheet is so large
that it nearly fills the display. The accountant pauses for several seconds,
resizes the spreadsheet, moves it in partially out of the display, opens the folder, opens
the memo, resizes and repositions the memo, and continues working.
(Carroll, 2000, p. 46)
Scenarios can capture more data about user's postures, emotions, and thinking
processes. While scenarios can provide important elements for describing a task in
general, and accessibility through their informal character, they lack a clear structure,
and are not necessarily focused on tasks to be carried out using a UI.
Use cases (Jacobson, 1992), on the other hand, emphasize well-defined and goal-
oriented steps of user-computer interaction. These steps reflect the work done by all
of the actors, that is, also of the computer system. Therefore, use cases work best for
software development, but lack contextual data; that could prove useful for a semiotic
analysis. With their orientation to a goal of interaction they are close to the interaction
games discussed further. Use-case scenarios, which are employed in the context of
use cases, focus on “one path through the use case” (Sharp et al., 2007, p. 510). This
way, they are similar to the scenarios introduced by Carroll (2000). The advantage of
use cases is, they can be used for complex, and nonlinear interactions.
A simpler way of capturing tasks provide Hierarchical Task Analysis (HTA) or
GOMS (Goals, Operations, Methods, and Selection rules) for more detail (Sharp,
et al., 2007, pp. 515-516). The task analysis lists all of the steps the user has to
pass to achieve a goal, thus focusing on the user's context rather than the system
processes. On the negative side, HTA is not suitable for complex or concurrent
interactions.
Interaction sentences are constructed to honor the aforementioned principles of
structure, clarity, and continuity, while allowing for narration details, and user-focus.
Interaction games, on the other hand, are goal-oriented sets of interaction sentences.
The succession of sentences, and creation of interaction games, is subject to the user's
intention to achieve a goal. If the intended goal has been achieved, there is no need
to continue with other interaction sentences.