User Interface Design

1
 What is User Interface
• Basically a page or screen in a software application
• A part of software that receives input
ꟷFrom the users
• Must have the facility to get input
ꟷThrough keyboard
ꟷMouse click
ꟷVoice
• What kind of Interface?
ꟷInterface for processing part of the software system
ꟷSends data to the to the data processing module

2
 Why is UI important
• The users of the of the system operates through this
interface
• The performance of the system depends on the user
interface
• Satisfaction of the user interface is important
• It is important to design UI first
• This is a sketch of what user wants
• Easy to convey the users what they will get

3
 Usability in UI
• The effectiveness with which users can accomplish tasks in a
(software) system, as measured by
ꟷLearnability: is it easy to learn?
ꟷEfficiency: once learned, is it fast to use?
ꟷSafety: are errors few and recoverable?

4
 Relative importance of usability
dimensions
• Depends on the user
ꟷNovices need learnability.
ꟷExperts need efficiency.
ꟷBut no user is uniformly a novice or an expert.

• Depends on the task

ꟷMissile launchers need safety.
ꟷSubway turnstiles need efficiency.

5
Usability matters: the cost of getting
it wrong

50% of all “malfunctioning”

electronic devices returned to
stores are in full working
order, but users can't figure
out how to operate them.

[Elke den Ouden, 2006]

Three Mile Island: nuclear

reactor meltdown caused by
an ambiguous user interface

6
 Designing UI: A good user interface
is hard to design …
• You are not the user
ꟷMost software engineering is about
communicating with other programmers.
ꟷUI is about communicating with users.
• Users are always right …
ꟷConsistent problems are the system’s
fault.
• Except when they aren’t
ꟷUsers don’t always know what they want.

7
Achieving usability: best practices

• User testing and field studies

• Evaluations and reviews by UI experts
• Prototyping
ꟷCheap, throw-away implementations
ꟷLow-fidelity: paper prototypes
ꟷMedium-fidelity: code prototypes

Key to success: good UI focuses on

the user, not the developer or the
system.

8
What is prototyping? Why do it?
• Prototyping: creating a scaled-down or incomplete version
of a system to demonstrate or test its aspects.
• Benefits of prototyping:
ꟷaids UI design
ꟷhelp discover requirements
ꟷhelp discover test cases and provide a basis for testing
ꟷallows interaction with user to ensure satisfaction
ꟷteam-building

9
 Some prototyping methods
• Code prototyping
ꟷimplement a "quick" / incomplete version of a UI
• Prototyping with UI builders (e.g., Visual Studio)
ꟷdraw a GUI by dragging/dropping UI controls on screen
• Paper prototyping
ꟷa paper version of a UI

10
 Why paper prototyping?

• Much faster to create and change than code

• More visual bandwidth (can see more at once)
• More conducive to working in teams
• Can be done by non-technical people
• Feels less permanent or final

11
 When to do prototyping?
• During or after requirements but before
design
ꟷhelps uncover requirements and upcoming design
issues
ꟷshows us what is in the UI, but also shows us
details of how the user can achieve goals in the UI

12
UI Design Considerations

13
Schneiderman's 8 Golden Rules

14
 Rule 1: Strive for consistency.

Consistent sequences of actions should be required in similar

situations; identical terminology should be used in prompts,
menus, and help screens; and consistent commands should be
employed throughout.

15
 Rule2: Enable frequent users to use
shortcuts
As the frequency of use increases, so do the user's desires to
reduce the number of interactions and to increase the pace of
interaction. Abbreviations, function keys, hidden commands,
and macro facilities are very helpful to an expert user.

16
 Rule 3: Offer informative
feedback
For every operator action, there should be some system
feedback. For frequent and minor actions, the response can be
modest, while for infrequent and major actions, the response
should be more substantial.

17
 Rule 4: Design dialog to yield
closure
Sequences of actions should be organized into groups with a
beginning, middle, and end. The informative feedback at the
completion of a group of actions gives the operators the satisfaction
of accomplishment, a sense of relief, the signal to drop contingency
plans and options from their minds, and an indication that the way
is clear to prepare for the next group of actions.

18
Rule 4: Design dialog to yield
closure

19
 Rule 5: Offer simple error
handling
As much as possible, design the system so the user cannot
make a serious error. If an error is made, the system should be
able to detect the error and offer simple, comprehensible
mechanisms for handling the error.

20
 Rule 6: Permit easy reversal of
actions
This feature relieves anxiety, since the user knows that errors
can be undone; it thus encourages exploration of unfamiliar
options. The units of reversibility may be a single action, a
data entry, or a complete group of actions.

21
 Rule 7: Let the user be in control.

Experienced operators strongly desire the sense that they are

in charge of the system and that the system responds to their
actions. Design the system to make users the initiators of
actions rather than the responders.

22
 Rule 8: Reduce short-term memory load
on the user.
The limitation of human information processing in short-term
memory requires that displays be kept simple, multiple page
displays be consolidated, window-motion frequency be
reduced, and sufficient training time be allotted for codes,
mnemonics, and sequences of actions.

23
UI Design components

24
 When to use?
• a button?
• a check box?
• a radio button?
• a text field?
• a list?
• a combo box?
• a menu?
• a dialog box?

25
 UI design: buttons, toolbars,
menus
• Use buttons for single independent actions
that are relevant to the current screen.
ꟷUse button text with verb phrases such as
"Save“ or "Cancel", not generic: "OK", "Yes",
"No"
ꟷUse Mnemonics or Accelerators (Ctrl-S)

• Use toolbars for common actions.

• Use menus for infrequent actions that may

be applicable to many or all screens.
ꟷUsers hate menus! Try not to rely too much on
menus. Provide another way to access the
same functionality (toolbar, hotkey, etc.)

26
 UI design: check boxes and radio
buttons
• Use check boxes for independent on/off switches.
• Use radio buttons for related choices, when only one choice
can be activated at a time.

27
 UI design: text fields, lists, combo
boxes, sliders
• Use text fields (usually with a label) when
the user may type in anything they want.

• Use lists when there are many fixed

choices (too many for radio buttons); all
choices visible on screen at once.

• Use combo boxes when there are many

fixed choices; don't take up screen real
estate by showing them all at once.

• Use a slider or spinner for a numeric

value.
28
 UI design: dialogs and panes
• Use a tabbed pane when there are
many screens that the user may
want to switch between at any
moment
• Use dialog boxes or option panes to
present temporary screens or
options
ꟷ“modal” dialog box prevents any other
action

29