User Interface Software Engineering

Analysis CS-303

Lecture # 27
28 March

Rubab Jaffar
[email protected]
 Today’s Outline
• User interface analysis and Design Models
• Design Process
• Interface Design Models
• Interface Elements
• Interface Evaluation

Software Engineering 2
 Interface design Analysis
• Interface design focuses on the following
o The design of interfaces between software components (internal
Interface)
o The design of interfaces between the software and other non human
producers and consumers of information ((external Interface)
o The design of the interface between a human and the computer
(user Interface)
• Graphical user interfaces (GUIs) have helped to eliminate many
of the most horrific interface problems
• However, some are still difficult to learn, hard to use, confusing,
counterintuitive, unforgiving, and frustrating
• User interface analysis and design has to do with the study of
people and how they relate to technology

Software Engineering 3
 User Interface Design
Process

Software Engineering 4
 A Spiral Process
• User interface development follows a spiral process
o Interface analysis (user, task, and environment analysis)
• Focuses on the profile of the users who will interact with the system
• Concentrates on users, tasks, content and work environment
• Studies different models of system function (as perceived from the
outside)
• Delineates the human- and computer-oriented tasks that are required
to achieve system function
o Interface design
• Defines a set of interface objects and actions (and their screen
representations) that enable a user to perform all defined tasks in a
manner that meets every usability goal defined for the system
o Interface construction
• Begins with a prototype that enables usage scenarios to be evaluated
• Continues with development tools to complete the construction
o Interface validation, focuses on
• The ability of the interface to implement every user task correctly, to
accommodate all task variations, and to achieve all general user
requirements
• The degree to which the interface is easy to use and easy to learn
• The users' acceptance of the interface as a useful tool in their work

Software Engineering 5
 User Interface Analysis
and Design
• The overall process for analyzing and designing a
user interface begins with the creation of different
models of system function.
• Four different models come into play when a user interface is
analyzed and designed
o User profile model – Established by a software engineer
o Design model – Created by a software engineer
o Implementation model – Created by the software implementers
o User's mental model – Developed by the user when interacting
with the application
• The role of the interface designer is to reconcile these
differences and derive a consistent representation of the
interface

Software Engineering 6
 User Profile Model
• Analysis of the potential users of the system
• Establishes the profile of the end-users of the system
o Based on age, gender, physical abilities, education, cultural or ethnic
background, motivation, goals, and personality
• Considers syntactic knowledge of the user
o The mechanics of interaction that are required to use the interface
effectively
• Considers semantic knowledge of the user
o The underlying sense of the application; an understanding of the
functions that are performed, the meaning of input and output, and
the objectives of the system
• Categorizes users as
o Novices
• No syntactic knowledge of the system, little semantic knowledge of the
application, only general computer usage
o Knowledgeable, intermittent users
• Reasonable semantic knowledge of the system, low recall of syntactic
information to use the interface
o Knowledgeable, frequent users
• Good semantic and syntactic knowledge (i.e., power user), look for shortcuts
and abbreviated modes of operation
Software Engineering 7
 Design Model
• Derived from the analysis model of the requirements
• Incorporates data, architectural, interface, and procedural
representations of the software
• Constrained by information in the requirements
specification that helps define the user of the system
• Normally is incidental to other parts of the design model
o But in many cases it is as important as the other parts

Software Engineering 8
 User's Mental Model
• Often called the user's system perception
• Consists of the image of the system that users carry in their
heads
• mental model is a set of beliefs, not facts about how a system
works and how people interact with that system based on
their beliefs
• Accuracy of the description depends upon the user’s profile
and overall familiarity with the software in the application
domain
• Discussions with people who work with the users and/or users
themselves
• What would the user want the system to do?
• How would system fit in with the normal work?
• How tecnically savvy is the user?
• What interface look & feel is best for user?

Software Engineering 9
 Implementation Model
• Consists of the look and feel of the interface
combined with all supporting information that
describe system syntax and semantics
• Strives to agree with the user's mental model;
users then feel comfortable with the software
and use it effectively
• Serves as a translation of the design model by
providing a realization of the information
contained in the user profile model and the
user’s mental model
• The biggest usability's dilemmas is the
common gap between designers' and users'
mental models

Software Engineering 10
 Elements of the User
Interface
• To perform user interface analysis, the practitioner
needs to study and understand four elements
o The users who will interact with the system
through the interface
o The tasks that end users must perform to do their
work
o The content that is presented as part of the
interface
o The work environment in which these tasks will be
conducted

Software Engineering 11
 User Analysis
• The analyst strives to get the end user's mental model and the
design model to converge by understanding
o The users themselves
o How these people use the system
• Information can be obtained from
o User interviews with the end users
o Sales input from the sales people who interact with customers and
users on a regular basis
o Marketing input based on a market analysis to understand how
different population segments might use the software
o Support input from the support staff who are aware of what works and
what doesn't, what users like and dislike, what features generate
questions, and what features are easy to use
• A set of questions should be answered during user analysis

Software Engineering 12
 User Analysis Questions
1) Are the users trained professionals, technicians, clerical or manufacturing
workers?
2) What level of formal education does the average user have?
3) Are the users capable of learning on their own from written materials or
have they expressed a desire for classroom training?
4) Are the users expert typists or are they keyboard phobic?
5) What is the age range of the user community?
6) Will the users be represented predominately by one gender?
7) How are users compensated for the work they perform or are they
volunteers?
8) Do users work normal office hours, or do they work whenever the job is
required?
9) Is the software to be an integral part of the work users do, or will it be used
only occasionally?
10) What is the primary spoken language among users?
11) What are the consequences if a user makes a mistake using the system?
12) Are users experts in the subject matter that is addressed by the system?
13) Do users want to know about the technology that sits behind the interface?

Software Engineering 13
 Task Analysis and
Modeling
• Task analysis strives to know and understand
o The work the user performs in specific circumstances
o The tasks and subtasks that will be performed as the user does the
work
o The specific problem domain objects that the user manipulates as
work is performed
o The sequence of work tasks (i.e., the workflow)
o The hierarchy of tasks
• Use cases
o Show how an end user performs some specific work-related task
o Enable the software engineer to extract tasks, objects, and overall
workflow of the interaction
o Helps the software engineer to identify additional helpful features

Software Engineering 14
 Content Analysis
• The display content may range from character-based
reports, to graphical displays, to multimedia information
• Display content may be
o Generated by components in other parts of the application
o Acquired from data stored in a database that is accessible
from the application
o Transmitted from systems external to the application in
question
• The format and aesthetics of the content (as it is displayed
by the interface) needs to be considered
• A set of questions should be answered during content
analysis

Software Engineering 15
 Content Analysis Guidelines
1) Are various types of data assigned to consistent locations on
the screen (e.g., photos always in upper right corner)?
2) Are users able to customize the screen location for content?
3) Is proper on-screen identification assigned to all content?
4) Can large reports be partitioned for ease of understanding?
5) Are mechanisms available for moving directly to summary
information for large collections of data?
6) Is graphical output scaled to fit within the bounds of the
display device that is used?
7) How is color used to enhance understanding?
8) How are error messages and warnings presented in order to
make them quick and easy to see and understand?

Software Engineering 16
 Work Environment Analysis
• Software products need to be designed to fit into the work
environment, otherwise they may be difficult or frustrating to use
• Factors to consider include
o Type of lighting
o Display size and height
o Keyboard size, height and ease of use
o Mouse type and ease of use
o Surrounding noise
o Space limitations for computer and/or user
o Weather or other atmospheric conditions
o Temperature or pressure restrictions
o Time restrictions (when, how fast, and for how long)

Software Engineering 17
 User Interface
Design

Software Engineering
 Introduction
• User interface design is an iterative process, where each
iteration elaborate and refines the information developed in the
preceding step
• General steps for user interface design
1) Using information developed during user interface analysis, define
user interface objects and actions (operations)
2) Define events (user actions) that will cause the state of the user
interface to change; model this behavior
3) Depict each interface state as it will actually look to the end user
4) Indicate how the user interprets the state of the system from
information provided through the interface
• During all of these steps, the designer must
o Always follow the three golden rules of user interfaces
o Model how the interface will be implemented
o Consider the computing environment (e.g., display technology,
operating system, development tools) that will be used

Software Engineering 19
 Interface Objects and Actions
• Interface objects and actions are obtained from a grammatical
parse of the use cases and the software problem statement
• Interface objects are categorized into types: source, target, and
application
o A source object is dragged and dropped into a target object such as
to create a hardcopy of a report
o An application object represents application-specific data that are not
directly manipulated as part of screen interaction such as a list
• After identifying objects and their actions, an interface designer
performs screen layout which involves
o Graphical design and placement of icons
o Definition of descriptive screen text
o Specification and titling for windows
o Definition of major and minor menu items
o Specification of a real-world metaphor to follow

Software Engineering 20
 Design Issues to Consider
• Four common design issues usually surface in any user interface
o System response time (both length and variability)
o User help facilities
• When is it available, how is it accessed, how is it
represented to the user, how is it structured, what
happens when help is exited
o Error information handling
• How meaningful to the user, how descriptive of the
problem
o Menu and command labeling
• Consistent, easy to learn, accessibility, internationalization
• Many software engineers do not address these issues until late in
the design or construction process
o This results in unnecessary iteration, project delays, and
customer frustration

Software Engineering 21
 Guidelines for Error Messages
• The message should describe the problem in plain language
that a typical user can understand
• The message should provide constructive advice for recovering
from the error
• The message should indicate any negative consequences of
the error (e.g., potentially corrupted data files) so that the user
can check to ensure that they have not occurred (or correct
them if they have)
• The message should be accompanied by an audible or visual
cue such as a beep, momentary flashing, or a special error
color
• The message should be non-judgmental
o The message should never place blame on the user

An effective error message philosophy can do much to improve

the quality of an interactive system and will significantly reduce
user frustration when problems do occur
Software Engineering 22
 Questions for Menu Labeling
and Typed Commands
• Will every menu option have a corresponding command?
• What form will a command take? A control sequence? A
function key? A typed word?
• How difficult will it be to learn and remember the commands?
• What can be done if a command is forgotten?
• Can commands be customized or abbreviated by the user?
• Are menu labels self-explanatory within the context of the
interface?
• Are submenus consistent with the function implied by a master
menu item?

Software Engineering 23
 User Interface
Evaluation

Software Engineering
 Design and Prototype
Evaluation
• Before prototyping occurs, a number of evaluation criteria can
be applied during design reviews to the design model itself
o The amount of learning required by the users
• Derived from the length and complexity of the written
specification and its interfaces
o The interaction time and overall efficiency
• Derived from the number of user tasks specified and the
average number of actions per task
o The memory load on users
• Derived from the number of actions, tasks, and system
states
o The complexity of the interface and the degree to which it
will be accepted by the user
• Derived from the interface style, help facilities, and error
handling procedures

Software Engineering 25
 Design and Prototype
Evaluation (continued)
• Prototype evaluation can range from an informal test drive to
a formally designed study using statistical methods and
questionnaires
• The prototype evaluation cycle consists of prototype creation
followed by user evaluation and back to prototype
modification until all user issues are resolved
• The prototype is evaluated for
o Satisfaction of user requirements
o Conformance to the three golden rules of user interface design
o Reconciliation of the four models of a user interface

Software Engineering 26
 That is all

Software Engineering 27