Selection of our books indexed in the Book Citation Index in Web of Science™ Core Collection (bkci)

t
say how or by what!)
.
Only if the user is forced to define a control for some important reason (is
limited by health-color blindness, for example), then should be used the word
demand
.
4.1.2 Scenario
The opposite side of UseCases is the scenario. This is always written from the point
of view of the system and how the system satisfies the user
’
s requirements. So in this
example, the system will display a print report icon, a text box to enter the number of
pages, a combo button to select the printer, and a print button.
The scenario is always precise and describes the controls of the system. It is usually
written after UseCase is finished, and there exist prototypes of the screens in the form
of wireframes.
15
Usability Testing Methods and Usability Laboratory Management
DOI: http://dx.doi.org/10.5772/intechopen.109140

---

4.1.3 UseCase and scenario in UCD
Therefore, the post of writing UseCase and Scenario is generally as follows:
•
First, write UseCase in terms of user expectations. Avoid defining controls.
Remember, it
’
s too early for that.
•
Design a wired screen model for one or more pooled user targets
—
UseCase.
•
According to expectations and wire models, implement the scenario. This will
match the look and feel of the application and describe how the system satisfies
the user
’
s expectations (
Figure 9
).
4.2 Usability testing
Usability testing is key to understanding and evaluating the quality of the designed
user interface:
•
The aim is to improve
or update an application.
◦
Should answer the question how and what to update.
•