User Interface Design

1
User Interface Design
2
Introduction

• Overview of guidelines for user interface design
• Principles of user interface design
• User interface design process.

3
Principles of User Interface Design

• Layout
• Content Awareness
• Aesthetics
• User Experience
• Consistency
• Minimize Effort

4
Layout

• The screen should be divided into areas that are
  used consistently for the same purpose, e.g. top
  for commands and navigation, middle of the screen
  for input/output.
• The screen should be divided so as to provide
  natural intuitive flow and minimize the users
  movement.

5
Content Awareness

• User must always be aware of where they are in
  the system with minimum effort.
• All interfaces should have titles.
• Menus should show you where you are, where you
  came from and where you can get to.
• Field labels should be short and specific.
• Field labels should be clear and unambiguous.

6
Aesthetics

• The interface must be pleasing to the eye.
• All forms and reports must have a minimum amount
  of white space.
• The font size should not be less that 8 point and
  10 point is usually preferred.
• Different font size should used to distinguish
  between different types of information,
• Underlining and italic makes text harder to read
  and should thus be avoided.
• San-serif fonts, e.g. Arial, Helvetica, are most
  readable for computer screens.

7
Aesthetics

• Capital letters should only be used for titles.
• Too many different colours and patterns make for
  difficult reading and should thus be minimized.
• Colours can be used to differentiate between
  different types of information, e.g. to
  differentiate headings from regular text.
• Different colours tend to provoke emotions in
  different ways.
• Colour blindness

8
User Experience

• Novice users vs. experienced users.
• The priority of novice users is ease of learning.
• The priority of experienced users is ease of use.
• Novice users and experienced users have different
  behaviour patterns.
• The user interface must provide a balance between
  quick access to commonly used functions and
  guidance through less well-known functions.
• Guidance can be possible switched on and off

9
Consistency

• Consistency forms the basis of ease of use, ease
  of learning and aesthetics.
• The needs to be consistency in the navigation
  controls.
• There must also be consistency in the terminology
  used.
• Consistency will enable the user to predict the
  effect of his/her action.

10
Minimize Effort

• The minimum amount of effect should be needed by
  the user to perform tasks.
• A minimum amount of mouse clicks or keystrokes
  should be used to execute actions.
• The three clicks rule can be used for this
  purpose.
• This rule states that each action should be
  performed with a minimum of three keystrokes or
  mouse clicks

11
User Interface Design Process

• Use scenario development
• Interface design structure
• Interface standards design
• Interface design prototyping
• Interface evaluation
• During design one moves back and forth between
  these steps instead of performing them
  sequentially.

12
Use Scenario Development

• A use scenario lists the steps that must be
  performed by a user to achieve a particular task.
  
• A use scenario is determined by specifying a path
  through the use case, i.e. a use scenario is a
  narrative description of a use case.

13
Use Cases

• Use cases are used to depict how a computer
  system interacts with its environment and thus
  illustrates the actions performed by the users of
  the system.
• Each use case describes one interaction between
  the user and the system, however each use case
  may have many paths.
• For example, when searching for a CD in on online
  CD system the user can search for it via the
  title or artist. Each path is called scenario.

14
Use Case Descriptions vs. Diagrams

• A use case description describes this narratively
  while a use case diagram depicts this
  pictorially.
• A use case description is usually firstly created
  and this description is then converted into a use
  case diagram.

15
Example

• The customer browses the catalogue and
• adds desired items to the shopping basket.
• When the customer wishes to pay, the
• customer describes the shipping and credit card
• information and confirms the sale. The system
• checks the authorization on the credit and
• confirms the sale both immediately and with a
• follow-up E-mail.

16
Use Cases for the Example Buy Product

• Customer browses through catalogue and selects
  items to buy.
• Customer goes to check out
• Customer fills in shipping information (address,
  next day or 3-day delivery)
• System presents full pricing information,
  including shipping
• Customer fills in credit card information
• System authorizes purchase
• System confirms sale immediately
• System sends confirming E-mail to customer

17
Buy Product Alternatives
.

• Alternative Authorization fails - At step 6
  system fails to authorize credit purchase. Allow
  customer to re-enter credit card information and
  re-try
• Alternative Regular customer
• 3a. System displays current shipping information,
  pricing information, and last four digits of
  credit card information
• 3b. Customer may accept or override these
  defaults
• Return to primary scenario at step 6.

18
Interface Design Structure

• This phase involves describing the different
  components of the interface and how the interact.
  
• A window navigation diagram (WND) depicting
  different screens, forms an reports and the
  relationship between them is used for this
  purpose.
• A WND is used to illustrate the state of changes
  in the interface.

19
A WND is Composed of
.

• Each box represents a user interface component,
  e.g. a menu or a form.
• Transitions between the components are
  illustrated by a double or single arrow.
• A single arrow indicates that a return to the
  calling state is not needed.
• A double arrow indicates that a return to the
  calling state is needed.
• Each component is described as a stereotype, e.g.
  ltltformgtgt, ltltmenugtgt.
• Each component is also given a label, e.g. Menu
  A, Form J.

20
Interface Design Standards
.

• This refers to the standards that are applied to
  components of the interface.
• There generally standards for the following
  components
• interface metaphors,
• interface objects,
• interface actions,
• interface icons and
• interface templates.

21
Interface Metaphors
.

• These are basically concepts from the real world
  that used to model a computer system.
• For example, an online CD sales system may use a
  music store as a metaphor, with a shopping cart,
  etc.
• The metaphor is meant to help the user to
  conceptualise the system and to predict certain
  actions.
• A system can have an overall metaphor or
  different parts of a system can use different
  metaphors.

22
Interface Objects
.

• This refers to specifying the names of the
  objects that will make up the interface.
• The usually correspond to class names. For
  examples an online CD sales system the shopping
  cart will be called the shopping cart, CDs
  maybe called CDs or albums.
• Both the software developer and user must agree
  on the names used.

23
Interface Actions
.

• This involves defining the navigation and command
  language.
• There must be consensus between users and
  developers uses of terminology, e.g. buy vs.
  purchase.

24
Interface Icons
.

• Icons are defined for specific actions, e.g. a
  disk can represent the action of saving.
• Use icons that are used in commonly-used software
  packages and will be known by the users of the
  system.
• Sometimes icons can cause some confusion so use
  icons that are not ambiguous.

25
Interface Templates
.

• These templates defines the appearance of each
  screen.
• The layout is described in terms of the position
  of the navigation area, status bar, form, reports
  and the colour schemes that will be applied.
• It will also describe the view types, e.g.
  cascading windows and where standard interface
  operations such as File, View and Edit.

26
Interface Design Prototyping
.

• One of the following techniques is used for
  prototyping storyboarding, HTML prototyping or
  language prototyping.
• All three techniques maybe used at different
  stages of the project.
• Storyboarding is the fastest, with language
  prototyping being the slowest and HTML
  prototyping falling in between.
• Similarly, storyboarding is the least expensive,
  HTML of medium cost, and language prototyping the
  most expensive.

27
Storyboarding
.

• This is usually done on a paper and consists of
  hand-drawn pictures as to what the
  user-interfaces will look like and the flow from
  one screen to the next.
• This is the simplest of all three techniques.
• Storyboarding is generally used for well
  understood parts of the system

28
HTML Prototyping
.

• The designer uses HTML to create the prototype.
• This technique has the advantage of the users
  being able to use the prototype and hence provide
  feedback on the ease of use, etc.
• The disadvantage of this approach is that screens
  will not appear in exactly the same format as
  they will in the final product.

29
Language Prototype
.

• This involves creating a prototype of the
  interfaces in the same language that the system
  will be coded in.
• The advantage of this approach is that the users
  will be able to see exactly what the screens look
  like.
• The disadvantage is that it takes longer to build
  prototypes using this approach than the other to
  techniques.
• Is used for parts of the system that are not
  well-defined.

30
Interface Evaluation
.

• Interface evaluation is performed to identify
  areas of improvement for of the interfaces and
  hence is performed more than once during the
  software design process.
• This is often left to the end and is the last
  step in the overall process.
• Four techniques that are commonly user for
  interface evaluation are
• heuristic evaluation,
• walk-through evaluation,
• interactive evaluation, and
• formal usability testing.

31
Heuristic Evaluation
.

• A checklist of the different design principles
  that the and interface navigation, input, and
  output principles (will be discussed later) is
  constructed.
• A minimum of three project team members test the
  interface using the checklist individually and
  meet and discuss their findings.

32
Walk-Through Evaluation
.

• The project team walks the users through the
  interface.
• The users are required to suggest changes to the
  interfaces.

33
Interactive Evaluation
.

• Instead of the team members walking the users
  through the interface, the users interact with
  the interface on a one-on-one basis.
• The users then inform the project team of what
  they like and do not like about the interfaces.
• The project team also makes note of any confusion
  and misinterpretations of the interface by the a
  number of users.

34
Formal Usability Testing
.

• This form of testing can only be applied to
  language prototypes.
• As with interactive evaluation a single users
  tests the software on a one-on-one basis.
• The evaluation is conducted in a lab equipped
  with video cameras to capture the users response
  to the interface.
• Each user is given a specific set of tasks.
• There is no interaction between the users and the
  project team and the user is not given any
  assistance.
• The drawback of this method is that it is
  expensive.