HUMAN COMPUTER INTERACTION

Lesson 2.6. HCI in Software Process Usability Engineering

Introduction
HCI is used in software process to interact product with user and give them a
simple and comfortable interface.
Software developers check the environment that it is simple and interactive for
selected environment and it is only possible human interaction.
In addition, cultural and national differences play a part.
Another consideration in studying or designing HCI is that user interface
technology changes rapidly, offering new interaction possibilities.

• Software Engineering the subdiscipline that addresses the management and

technical issues of the development of software systems.
• Software Life Cycle the activities that take place form the initial concept for a
software system up until its eventual phasing out and replacement.
As the main underlying theory for HCI, human factors can largely be divided into:
a) Cognitive science that explains the human’s capability and model of conscious
processing of high-level information
b) Ergonomics that elucidates how raw external stimulation signals are accepted
by our five senses, are processed up to the pre-attentive level, and are later acted
upon in the outer world through the motor organs.

Human-factors knowledge will particularly help us design HCI in the following ways.
1. Task/Interaction Modeling
Formulate the steps for how humans might interact to solve and carry out a given
task/problem and derive the interaction model.

2. Prediction, Assessment, and Evaluation of Interactive Behavior

Understand and predict how humans might react mentally to various information
presentation and input-solicitation methods as a basis for interface selection.

The HCI Principle of task/interaction modeling was helpful understanding the tasks
required to accomplish the ultimate goal of the interactive system.
For a smaller problem of “fixing the font,” the action could be a “menu item
selection” applied to a “highlighted text.” There are several “human problem
solving” models that are put forth by number of researchers, but most of them can
 be collectively summarized as depicted in Figure 2.1.
This
problem-
solving
process epitomizes the overall
information-processing model.

Human Factors as HCI Theories

 (a) (b)
Figure 2.1 (a) The overall human problem-solving model and process and (b) a
more detailed view of the “decision maker/executor”.
In general, human problem-solving or information-processing efforts consist of
these important parts:
• Sensation senses external information (e.g. visual, aural, haptic)
• Perception interprets and extracts basic meanings of the external information.
• Decision maker/executor formulates and revises a “plan,” then decides what to
do based on the various knowledge in the memory, acts it out by commanding
the motor system (e.g. to click the mouse left button).

The Software Life Cycle Activities

1. Requirement Specification capture a description of what the eventual system

will be expected to provide. Requirements, formulated in natural language are
translated to a more formal and unambiguous language.
2. Architectural Design the system is decomposed into components that can be
brought in from existing products or that can be developed from scratch. How does
the system provide the services expected from it?

3. Detailed Design a refinement of the component description provided by the

architectural design, made for each component separately.

4. Coding and Unit Testing implementing the detailed design in an executable

programming language and testing the different components.

5. Integration and Testing integrating the different components into a complete

system and testing it as a whole. Sometimes also certify the system according to
ISO-standards.

6. Maintenance all the work on the system after the system is released.
Validation and Verification

Verification (designing the thing right) will most often occur within a single life
cycle activity or between two adjacent activities. Validation of a design (designing
the right thing) demonstrates that within the various activities the customers'
requirements are satisfied. Because verification proofs are between rather formal
languages, the proofs are rather formal too. The validation proof, however, is not.
There is a gap between the real world and structured design known as the
formality gap. The consequence is that there is always a certain subjectivity
involved with validation.
Management and Contractual Issues

The software life cycle is sometime insufficient. A much wider perspective must be
adopted which takes into account the marketability of a system. IT training needs,
the availability of skilled personnel or possible subcontractors, and other topics
outside the activities for the development if the isolated system.

In managing the development process, the temporal relationship between the

various activities is more important, as are the intermediate deliverables which
represent the technical content, as the designer must demonstrate to the
customer that progress is being made. The technical perspective of the life cycle is
described in stages of activity, whereas the managerial perspective is described in
temporarily bound phrases: input and output of documentation.
Interactive Systems and the Software Life Cycle

The life cycle for development described above presents the process of design in a
somewhat pipeline order. In reality, the actual process is iterative: work in one
design activity affects work in any other activity both before or after it in the life
cycle. All of the requirements for an interactive system cannot be determined from
the start. During the design process, the system is made more usable by having the
potential user test the prototypes and observe his behavior. In order to do this,
clear understanding of human task performance and cognitive processes is very
important.
Usability Engineering

In relation to the software life cycle, one of the important features of usability
engineering is the inclusion of a usability specification, forming part of the
requirement specification, that concentrates on features of the user-system
interaction which contribute to the usability of the product.

For each attribute, six items are defined to form the usability specification of that
attibute:

▪ Measuring concept makes the abstract attibute more concrete by describing it in

terms of the actual product.

▪ Measuring method states how the attibute will be measure.

Iterative Design and Prototyping

1. Now level indicates the value for the measurement with the existing
system. 2. Worse case the lowest acceptable measurement for the task.
3. Planned level the target for the design.
4. Best case the level which is agreed to be the best possible measurement given
the current state of development tools and technology.
Iterative design: a purposeful design process which tries to overcome the inherent
problems of incomplete requirement specification by cycling through several
designs, incrementally improving upon the final product with each pass. On the
technical side, this is described by the use of prototypes.

Main Approaches of Prototyping

1. Throw-away
The knowledge gained from the prototype is used in the final design but the
prototype is discarded.
2. Incremental
The final product is released as a series of components that have been prototyped
separately.
3. Evolutionary
The prototype is not discarded but serves as a basis for the next iteration of the
design.

Prototypes differ according to the amount of functionality and performance they

provide relative to the final product. The importance lies in its projected realism
since they are tested on real users. Since providing realism in prototypes is costly,
there are several problems on the management side.
1. Time. Prototyping costs time which is taken away from the real design.
Therefore, there are rapid-prototyping techniques.
2. Planning
3. Non-functional features. Some of the most important features, as safety and
reliability cannot be tested using a prototype.
4. Contracts. Prototyping cannot form the basis for a legal contract and must be
supported with documentation.
Importance of Software Process/Usability Engineering

For an information system (for software or a website) issues such as platform

compatibility, consistency, content wording, error prevention and help features,
navigation, feedback, security, text readability, and the use of color all fall under
the usability and for a Usability Expert to evaluate.

The quick list of example questions asked above should be a good indicator of why
good usability is so important.
It can make the difference between a successful software install or an unwanted
hard drive “cleaning”.
A safe plane ride or a disaster.
A perfect piece of plain white toast or a char-broiled square of something that used
to be wonder bread.

It’s the difference between effectively helping users to accurately complete their
tasks and frustrating them because they can’t do what they need to do.
It affects users, developers, and managers – if you don’t take care of usability,
people won’t buy your software, fly your plane, use your product, or surf your
website.
Software engineers are well versed in the software development process.
They need input from IT leader regarding software requirements and what the end
result needs to be.
Regardless of formal education, all software engineers should work within a
specific set of best practices for software engineering so that others can do some
of this work at the same time.

Software engineering always includes vast amount of teamwork.

Designers, writers, coders, testers, various team members and the entire IT team
need to understand the code.

Implication of Software Process/Usability Engineering

Several barriers block the adoption of HCI practices into today’s software
development processes:
Developers often perceive usability as applying only in UI interface design, whereas
it actually covers all interaction between the user and the system.

Different HCI practices address different aspects of user-system interaction.

The adoption of good HCI practices within the software engineering field involves
explicitly considering usability practices and studying their impact on the
development process and on the different software products generated.

This integration effort is important as the HCI and software development

communities use different terminology and take a different view of the software
construction process: they don’t understand the constraints under which the other
community must operate.
For this reason, the communication mechanisms between the two disciplines
require improvement.
HCI methods are systematically more readily accepted by software engineers and
integrated into the development process. Thus, bidirectional initiatives to train
software developers in UI design and usability experts in software implications
would be beneficial.
The adoption of HCI best practices is critical for producing better and highly usable
software.

Table 1. HCI practices, benefits, and implications in the software development process.
 HCI practice Description Examples Project phase Person in charge Benefits
HCI interface Patterns used Color-coded At any time, The UI Improve
patterns to capture divisions, but preferably designer or system
best titled during the interface
practices for sections, interface programmer, appearance
solving scrolling design. if no UI and
particular menu, icon designer navigation;
user-interface menu, participates improve
design shopping in the access to
scenarios carts, small development system
groups of team. functionalities
related (such as
things, chart menus).
or graph,
map
of navigable
spaces,
thumbnail,
collapsible
panels
HCI practice Description Examples Project phase Person in charge Benefits
Usability Usability Undo/cancel During The Enrich user
functionalities requirements commands, requirements requirements interaction
that ease the predict a task elicitation to analyst capabilities
use of any duration, capture the must be with new
software aggregate usability conscious usability
system and commands, functionalitie about the functionalitie
facilitate check for s as any need to s that the
daily user tasks. errors, other incorporate user is not
present system Requirement. usability aware of a
state, provide functionaliti priori.
good help, es in the
minimize system; the
user project
recovery manager
work must
due to estimate
systems the cost and
 errors. resources
Needed.

HCI practice Description Examples Project phase Person in charge Benefits

User- Approach for Focus groups, At project Whole Helps capture
centered building card sorting, startup organization user
design interactive scenarios of because it must be interaction
systems that use, thinking affects the involved to with the
explicitly aloud, entire adapt the system;
involves the heuristic software traditional reduces the
user through evaluation, development software level of user
all Wizard of Oz process development rejection of
development prototyping, process to the software
stages; expert take into product
particular HCI evaluation, account
techniques participatory user-
contribute to evaluation, centered
 this aim laboratory needs and
testing, surveys HCI
techniques

Source: Moreno, Ana M., et al. “HCI Practices for Building Usable Software.” Computer 46.4 (2013): 100-102.

Problems with Usability Engineering

• The major feature of usability engineering is the assertion of explicit usability

metrics early on in the design process which can be used to judge a system once
it is delivered.
• Usability engineering provides a means of satisfying usability specifications and
not necessarily usability: the usability metrices must be interpreted correctly.
Techniques for Prototyping

• Storyboards – a graphical depiction of the outward appearance of the intended

system, without any accompanying system functionality.
• Limited functionality simulations – programming support for simulations means a
designer can rapidly build graphical and textual interaction objects and attach
some behavior to those objects, which mimics the systems functionality.
• High-level programming support – high-level programming languages allow the
programmer to abstract away from the hardware specs and thinking terms
that are closer to the way the input and output devices are perceived as
interaction devices. This technique can also be provided by a user interface
management
system, in which features of the interface can be designed apart from the
underlying functionality.
Design Rationale

Design rationale is information that explains why a computer system is the way it
is.
Benefits of Design Rationale:
1. Communication throughout life cycle
2. Reuse of design knowledge across products
3. Enforces design discipline
4. Presents arguments for design trade-offs
5. Organizes potentially large design
space 6. Capturing contextual
information
7. Case study related to topic

Bornoe, Nis, and Jan Stage. “Usability engineering in the wild: How do practitioners
integrate usability engineering in software development?” International
Conference on Human-Centered Software Engineering. Springer, Berlin,
Heidelberg, 2014.
In this study the practitioners shows the usability of engineering in software
development. Reaching this goal has shown not to be straightforward because
usability engineering not is an exact discipline. Recently more qualities have been
added to user-centered design.

Usability is generally associated with learnability, efficiency, memorability, errors,

and satisfaction.
When it comes to conducting usability engineering in practice, it has been argued
that too much research on usability engineering is incoherent with the processes,
and settings being the realities for practitioners
Studies have reported that usability engineering is being neglected due to missing
perceived quality, and the mindset of developers.
All dynamic testing and development we’re follow using interaction design that
support developers developing functionality towards the requirements of the
system.