Lecture 5: Design Strategies/Issues Prototyping

1
Lecture 5Design Strategies/IssuesPrototyping
MIS 210 Information Systems I
2
Design Strategies/Issues
3
Understanding Design Elements

• Design is the process of describing, organizing,
  and structuring the components of a system at
  both the architectural level and at a detailed
  level
• Three questions
• What is used for input to the design?
• How is the design done?
• What are the final design documents?

4
Principles of Well Designed Systems

• Cohesion
• How well activities within a single module are
  related to one another
• Functional cohesion
• containing all, and only, those tasks
  contributing to the generation of a single
  information function/ product

5
Principles of Well Designed Systems

• Decoupling
• Separate modules are relatively independent
• loose coupling
• allow one module to be repaired with minimum
  disruption to others
• overlapping/duplicate functions
• independence

6
Principles of Well Designed Systems

• Modularity
• design of a system in relatively small chunks
• allows assignment of developers to different
  tasks
• sections of system can be developed independently
• maintenance can occur without disturbing other
  modules
• User involvement
• throughout SDLC
• sense of ownership

7
Principles of Well Designed Systems

• Satisficing
• better not best solution
• best solution not feasible
• resource constraints
• Human Interface
• human factors
• ergonomics

8
Output Design
9
Output Design

• Why start with output?
• Output should be
• accessible
• timely
• relevant
• accurate
• usable
• complete
• correct
• secure
• economic
• efficient

• Issues
• output method
• output format
• purpose
• distribution
• frequency and timing

10
Report Characteristics

• Frequency
• How often?
• Periodic
• As required
• ad hoc
• on demand

• Distribution
• Who will be using the report?
• Internal
• External
• Turnaround
• Format

11
Report Types

• Detail
• day to day operations
• structured
• Resource status
• inventory, customer activity, etc.
• periodic (e.g.,once a month)
• structured or unstructured

• Summary (Management)
• statistics and ratios
• ad hoc or periodic
• structured

12
Output Design Tactics

• Aesthetics
• Strategic value
• Distribution testing
• who really needs it?
• Field selection
• Design for change
• e.g., field size

13
Principles of Output Design

• Always have a title (proper wording, page
  numbers, dates)
• Use sections
• Include legends
• Eliminate computer jargon
• Read left to right, top to bottom
• Column headings for multi-record layout
• Data labels for single record layout
• Right justify numbers, left justify text
• Use colors (screen output / color output)

14
Input Design
15
Input Forms

• Forms of input
• manual paper forms
• electronic input forms
• direct-entry devices
• document image processing

16
Remember...

• A well designed document is
• easy to use
• unique or specific
• concise
• informative
• expandable
• amenable to data entry
• economical

17
Human Computer Interaction/Interactive Design
18
User Types

• Novice
• Intermediate
• Experienced
• Casual (Rusty)

19
The Novice User

• Human Factors default
• experienced users get testy
• novice users quit
• Why cater to them when they learn so quickly?
• Typical turnover rate

20
Short-term Memory

• Capacity (chunks)
• relative to familiarity
• Millers 7 /- 2 phenomenon
• decreases with anxiety

21
STM Volatility

• Limited capacity
• Data lasts about 15 sec
• Events causing data loss
• interruption (phone calls)
• processing delays (response time)
• visual distraction (color)
• noisy work environment
• Importance of closure

22
Long-term Memory

• Learning is pushing chunks from STM to LTM
• Takes fair amount of time and iterations
• Once learned, not forgotten

23
Human Factors Goals

• Time to learn
• Speed of performance
• Rate of user errors
• Subjective satisfaction
• turnover rate
• Knowledge retention over time

24
Design Principles

• (Shneiderman, 1987)
• Keep it simple.
• Be consistent.
• Design tasks for closure.
• Support internal locus of control.
• Provide user shortcuts

25
Design Principles

• Handle errors civilly.
• Allow easy reversal of actions.
• Use surprise effectively.
• Dont lose the user.

26
Keep It Simple

• Simple screen designs
• Minimal use of windows
• Screen density

27
Error Checking

• Types Transaction Errors
• field type (e.g., numeric)
• field size
• unreasonable quantity
• field not filled in
• mandatory property / slot

28
Error Checking (continued)

• Types (continued)
• logical range (e.g., month)
• negative balance
• illogical combinations
• record access
• not found
• duplicate

29
Error Checking (continued)

• Catch errors early
• cost of rework increases exponentially with time
• Clean Transaction tactic
• dont update records with suspicious data

30
Error Messages

• Specific and precise
• Constructive
• Show what needs to be done
• Transpose Customer ?
• Positive tone
• Avoid illegal, invalid, bad

31
Error Messages (continued)

• User-centered phrasing
• Ready for data rather than
• Enter data
• Multiple levels of messages
• Help Specific screens
• Consistent grammatical form, terminology and
  abbreviations

32
Be Consistent

• Same terminology on all screens
• Similar screen layouts
• Standard escape routes
• Consistent processing times
• novice users prefer consistent, not faster,
  screen response times

33
Design for Closure

• Break tasks into smallest modules
• Provide user feedback
• hourglass
• still processing
• Phase III completed
• Keep from discouraging users

34
Support Internal Locus of Control

• Minimize warnings
• No patronizing messages
• Avoidance of we or I
• User choices
• color
• screen placement
• novice / experienced

35
Easy Reversal of Actions

• Erase / undo
• Word / Line / Screen
• Escape menus
• Paging back

36
Use Surprise Effectively

• Minimum highlighting
• Minimum input verification
• Few flashing or auditory signals

37
Screen Structure

• Greeting Screen
• Password Screen
• Main Menu
• Intermediate Menus
• Function Screens
• Form-filling
• Transaction update

38
Structure (Continued)

• Help screens (Pull Down)
• Escape options
• Quit
• Main Menu
• Last screen

39
Dialogue Modes

• Inquiry
• Are you sure
• augments other dialogue modes
• Command Language
• experienced user shortcuts
• Menus (for navigation)
• Form-filling Screens

40
Menus

• Option sequence
• logical (new, update, delete)
• frequency of choice
• alphabetic
• Number options

41
Interactive Structure
Greeting Screen
(1)
Dont Accept
(2)
Password Screen
Accept
(3)
Main Menu
Escape Options
Help Screens
(4)
(4)
(4)
Intermediate Menu
Intermediate Menu
Intermediate Menu
(5)
(5)
(5)
Function Screen
Function Screen
Function Screen
(6)
(7)
42
Form-filling Screens

• Looks like off-line form
• same sequence
• shade fields to be entered
• Cycle until user chooses to exit
• Maximize transaction throughput

43
Maximizing Transaction Throughput

• Cueing (entry format)
• Autoterminate
• Free-form entry
• Default values
• constant (e.g., System Date)
• from record (e.g., Item Price)
• last transaction (e.g., Cust )

44
Common Screen Considerations

• Highlighting (lt 10)
• color
• reverse image
• flashing
• auditory
• Colors (dont overdo)

45
Screen Considerations

• Symmetry
• unless theres a reason
• Input verification
• Screen density
• Relative screen clutter
• Tied to throughput
• Total and Local

46
Total Screen Density

• screen with non-blank characters
• ( char) / (screen capacity)
• should be lt 25
• can achieve on form-filling screen
• dimming unused screen portions
• highlighting screen portions
• blocking out with windows

47
Example

• Non-zero characters
• Filling up the screen
• From top to bottom
• From left margin to right margin
• Too much total screen density
• Novice users will have reduced throughput

48
Local Screen Density

• Mean clutter around each character
• How to reduce
• minimize capital letters
• limit punctuation
• blank lines between text lines
• minimize words used

49
Features That Affect User Interface Design

• Display area
• Character sets and graphics
• Paging and scrolling
• Color displays and display properties
• Split-screen and windowing capabilities
• Keyboards and function keys
• Pointer options

50
Remember

• Entertainment is NOT system effectiveness!

51
Prototyping
52
Definition

• A PROTOTYPE is a model of the system
• It can be as simple as mock-ups of reports or
  screens, or as complete as software that actually
  does some processing.
• Can be used as a communication tool between
  analyst and user.
• Prototyping is the process of developing
  prototypes.
• Prototyping strategy indicates the type of
  prototype used.

53
Why Prototyping

• When youre working with new system ideas with
  your users, you dont want to go through the
  cost of developing a gigantic system which might
  take years youll build a mock-up of it, which
  might take weeks.
• Brian Kilcourse,
  CIO
• Longs Drug Stores

54
Approaches

• Type I - Iterative
• becomes final system
• Type II - Throwaway
• used as model for final system

55
Type I (Iterative) Life Cycle
Requirements Definition
Prototype Training
Project Planning
Rapid Analysis
Database Design
Design Prototype
Generate Prototype
Test Prototype
No
Acceptable?
Yes
Implement System
Maintain System
56
Type II (Throwaway) Life Cycle
Requirements Definition
Analysis
Design Prototype
Code Prototype
Test Prototype
No
Acceptable?
Yes
Code Final System
No
Test Final System
Implement Final System
Maintain Final System
Yes
Acceptable?
57
Types of Prototypes

• Illustrative
• Mock-ups
• Simulated
• Looks like they work, but are simulations
• Functional
• Does some processing, but doesnt store data
• Evolutionary
• Used to produce an operational systems

58
Prototype Levels

• Level 1 (Input-Output)
• printed reports and on-line screens
• screen flow sequence
• screen options
• Level 2 (Heuristic-Learning)
• updating database
• basic transactions

59
Levels (Continued)

• Level 3 (Adaptive)
• working model of system
• system with training wheels
• no bells or whistles

60
Advantages

• Speed
• Easier for end-users to learn
• System changes discovered earlier
• End-user involvement (ownership)
• increased user satisfaction
• increased user acceptance
• User-analyst communication
• Early problem detection
• reduced development time
• reduced maintenance

61
Disadvantages

• Poor documentation
• Hard to control/manage
• (Unrealistic) User expectations
• time for final system
• final system differences
• reduced analysis