Week 9 - by Lee Chen Yau

In week 9, lecturer teach us about Prototype. What is a prototype?
- paper-based outline of a screen/ sets of screen
- Electronic "picture"
- 3 dimensional paper/ cardboard mockup
- stacked of hyperlinked screen shots

Prototype allows stakeholders to:
- interact with an envisioned product
- gain experience in realistic setting
- explore imagined uses

Prototype aid when discussing ideas with stackholders, communication device among team members, effective way to test ideas. For example, clarify vague requirements; To do user testing and evaluation; Check a certain design direction is compatible with the rest of the system development.

There are two types of prototyping, which are low-fidelity prototyping and high-fidelity prototyping.


Low-fidelity prototyping:
- does not look like the final product (eg. uses materials very different from final product such as paper/cardboard)
- simple, cheap, easy to produce
- for exploration only; important for conceptual design but not intended to be kept and integrated into final product
- Storyboard
* series of sketches to show how a user can interact with the product
* for example, screens of a GUI-based software, scene sketches showing how a user can perform tasks using an interactive device.


High-fidelity prototyping:
- uses materials expected to be in the final product and looks very much like the real thing (eg. using Visual Basic)
- useful for selling ideas and testing out technical issues
- users may be faced with the following problems:
* a long time is needed to build a high-fidelity prototype
* reviewers and critics may focus too much on the superficial aspects of the prototype rather than the content
* developers would be less willing to do any alterations when they have spent a lot of time and energy on the prototype
* software prototypes are prone to setting high expectations
* a high-fidelity prototype of great scales can bring the entire testing and development stage to a halt


The Advantages
Low- fidelity prototype
- lower development cost
- evaluate multiple design concepts
- useful communication device
- address screen layout issues
- useful for identifying market requirements
- proof-of-concept

High- fidelity prototype
- complete functionality
- fully interactive
- user driven
-clearly defines navigational scheme
- use for exploration and test
- look and feel of final product
- serves as a living specification
- marketing and sales tool

The Disadvantages
Low- fidelity prototype
- limited error checking
- poor detailed specification to code to
- facilitator-driven
- limited utility after requirement established
- limited usefulness for usability tests
- navigational and flow limitation

High- fidelity prototype
- more expensive to develop
- time-consuming to create
- inefficient for proof-of-concept designs
- not effective for requirements gathering


Conceptual Design: moving from requirements to first design
- is concerned with transforming needs and requirements into a conceptual model
- concept model: an outline of what people can do with a product and what concepts are needed to understand how to interact with it.
- key guiding principles of conceptual design are:
   * keep an open mind but never forget the users and their context
   * discuss ideas with other stakeholders as much as possible
   * use low-fidelity prototyping to get rapid feedback
   * iterate, iterate and iterate


Developing an initial Conceptual Model
- some elements in a conceptual model will derive from the requirements for the product.
- some consideration to create initial conceptual model:
* which interface metaphors would be suitable to help users understand the product?
* which interaction type(s) would best support the user's activities.


Interface Metaphors:
- Combine familiar knowledge with new knowledge in a way that will help the user understand the system.
- Choosing suitable metaphors and combining new and familiar concepts requires a careful balance between utility and fun and based on a sound understanding of the users and their context.
- Ex: Teaching math to 6 year-old children.
- 3 steps in choosing a good interface metaphors:
   * understand what the system will do
   * understand which bits of the system are likely to cause users problems
   * generate metaphors


Interaction Types:
- 4 types of interaction: instructing, conversing, manipulating and exploring.
- Which is best suited to your current design depends on the application domain and the kind of product being developed.
- Ex: Computer game: manipulating, Drawing packages: instructing, conversing.
- Different interface types prompt and support different perspective on the product under development and suggest different possible behaviours.
- WIMP/ GUI interface
- Sharable interface
- Tangible interface
- Advanced graphical interface

Week 9- by Tang Yook Meng

WHAT IS A PROTOTYPE

• Paper based outline of a screen/sets of screens
• Electronic ‘picture’
• 3D paper/cardboard mockup
• Stack of hyperlinked screen shots
• Prototype allows stakeholders

To interact with an envisioned product, gain experience in realistic setting and also explore imagined uses. It also aid when discussing ideas with stakeholders, act as communication device among team members, and effective way to test ideas. For example, check a certain design direction is compatible when with the rest of the system development.

1. LOW-FIDELITY PROTOTYPING

• Is one that does not look very much like the final product.
• Ex: uses materials that are very different from the intended final version such as paper, cardboard rather than electronic screens and metal.
• Important during conceptual design and are never intended to be kept and integrated into the final product. They are for exploration only.

Advantages:

• Lower development cost
• Evaluate multiple design concepts
• Useful communication device
• Address screen layout issues
• Useful for identifying market requirement
• Proof-of-concept

Disadvantages:

• Limited error checking
• Poor detailed specification to code to
• Facilitator-driven
• Limited utility after requirement established
• Limited usefulness for usability tests
• Navigational and flow limitation

2. HIGH- FIDELITY PROTOTYPING

• Uses materials that you would expect to be in the final product and produced a prototype that looks much more like the final thing.
• Ex: prototype of a software system developed in Visual Basic vs paper based mockup.
• It is useful for selling ideas and testing out technical issues.

Advantages:

• Complete functionality
• Fully interactive
• User Driven
• Clearly defines navigational scheme
• Use for exploration and test
• Look and feel of final product
• Serves as a living specification
• Marketing and sales tool

Disadvantages:

• More expensive to develop
• Time-consuming to create
• Inefficient for proof-of-concept designs
• Not effective for requirements gathering

DEVELOPING AN INITIAL CONCEPTUAL MODEL

-INTERFACE METAPHORS-

• Combine familiar knowledge with new knowledge in a way that will help the user understand the system.
• Choosing suitable metaphors and combining new and familiar concepts requires a careful balance between utility and fun and based on a sound understanding of the users and their context.
• 3 step in choosing good interface metaphors:

Understand what the system will do

Understand which bits of the system are likely to cause users problem

Generate metaphors

-INTERFACE TYPES-

• Different interface types prompt and support different perspective on the product under development and suggest different possible behaviors.
• WIMP/GUI interface
• Sharable interface
• Tangible interface
• Advanced graphical interface

Week 9 - by Alice Low Soo Ying

What is a prototype? A prototype is:

• Paper- based outline of a screen / sets of screens

• Electronic 'picture'

• 3 dimensional paper / cardboard mockup

• Stack of hyperlinked screen shots

Allows stakeholders to:

• Interact with an envisiones product

• Gain experience in realistic setting

• Explore imagines uses

A prototype is a limited presentation that allows users to interacts and explore its usability.

• It is an helpful aid when discussing with stakeholders. 

• It also can be use as a communication device among team members.

• It is an effective way to test an idea

Example: clarify vague requirements, to do user testing and evaluation, check the design compability.

Low-fidelity Prototyping

• is one that does not look very much like the final product.

• Ex: uses materials that are very different from the intended final version such as paper, cardboard rather than electronic screen and metal.

• tend to be simple, cheap and quick to produce for support the exploration of alternative designs and ideas.

• important during conceptual design and are never intended to be kept and integrated into the final product. They are for exploration only.

Type of low-fidelity

• Storyboard
- consist of a series of sketches showing how a user might progress through a task using the product under development
• Sketches
- relies on sketching but often people find it difficult to engage in this activity
• Index cards
- use index cards (small pieces of the cardboard about 3x5 inches), each card represents 1 screen or one element of a task, in user evaluation, the user can step through the card
• Wizard of Oz

High-fidelity prototyping
• Uses materials expected to be in the final product and looks very much like the real thing
• Ex: prototype of a software system developed in Visual Basic vs paper based mock up
• It is useful for selling ideas and testing out technical issues

Problems with high-fidelity prototyping
• Take too long to build
• Reviewers and testers tend to comment on superficial aspects rather than content
• Developers are reluctant to change something they have crafted for hours
• A software prototype can set expectations to high
• Just one bug in a high-fidelity prototype can bring the testing to halt

Compromises in prototyping
• by their very nature, prototypes involve compromises: the intention is to produce something quickly to test an aspect of the product
• thus the prototype must be designed and built with the key issues in mind
• there are 2 common compromises:
- horizontal prototyping
- vertical prototyping

Conceptual Design
• it concerned with transforming needs and requirements into a conceptual model (an outline of what people can do with a product and what concepts are needed to understand how to interact it)
• key guiding principles :
- keep an open mind but never forget the users and their content
- discuss idea with stakeholders
- use low-fidelity prototyping to get rapid feedback

Developing an initial conceptual model
• some elements is a conceptual model with derived from the requirements for the product
• some consideration to create initial conceptual model
- which interface metaphor would be suitable to help users understand the product?
- which interaction type(s) would best support the user's activities?

Interface metaphors
• Combine familiar knowledge with new knowledge in a way that will help the user understand the system.
• Choosing suitable metaphors and combining new and familiar concepts requires a careful balance between utility and fun and based on a sound understanding of the users and their context.
• 3 step in choosing good interface metaphors:
- Understand what the system will do
- Understand which bits of the system are likely to cause users problem
- Generate metaphors

Interaction Types
• Different interface types prompt and support different perspectives on the product under development and suggest different possible behaviours.
• WIMP/GUI interface
• sharable interface
• tangible interface
• advance graphical interface

Week 8- by Tang Yook Meng

WHAT ARE REQUIREMENTS?

TO IDENTIFYING THE NEEDS & REQUIREMENT

• Is a statement about an intended product that specifies what it should do or how it should perform.
• Should be as specific, unambiguous and clear as possible
• Example: time to download any complete web page is less than 5 seconds VS teenage girls should find the site appealing
• Must know how to tell when they have been fulfilled

TYPE OF REQUIREMENTS

1. IN SOFTWARE ENGINEERING

• Functional requirements

WHAT the system should do? For examples, Word processor.

It should support a variety of formatting styles, and also formatting by paragraphs, character and etc.

• Non-functional requirements

WHAT are the constrains there are on the system and its development? For examples, Word processor.

It must be able to run on target platform such as PCs, Macs and Unix machines OR target platform must be have at least 1.0 GB RAM.

2. IN INTERACTION DESIGN

• Functional requirement

It capture what the product should do

• Data Requirements

Capture the type, volatility, size, amount, persistence, accuracy and value of the required data. Such as: Share-dealing application- data must be up to date, accurate and change many times a day.

• Environmental requirements/context of use

The circumstances in which the interactive product will be expected to operate. There are 4 characteristics: Physical environment is about how much light, noise and dust is expected in the operation environment. Social environment is a social aspect for interaction design to collaboration and coordination. Next, Organisational environment is how good is the user support likely to be, how easily it can be obtained, and are there facilities for training. Finally, technical environmental is about what technologies will the product run on or need to be compatible with and what technologies limitations might be relevant.

• User characteristics

Capture the key attributes of the intended user group. It means the user’s abilities and skills, user’s nationality, educational, background, preferences, personal circumstances, physical or mental disabilities. The collection of the attributes for a ‘typical user’ is called a user profile. Any one product may have a number of different user profiles, to bring user profile to file, they are turned into a number of Personas, which means rich descriptions of typical users of the product under development that the designers can focus on and design the product for. They don’t describe real people, but are synthesized from a number of real users who have involved in data gathering exercised.

• Usability goals and user experience goals

Usability goals are about effectiveness, efficiency, safety, utility, learnability and tracking. These all will form User’s Performance. While, user experience goals will form User’s Perception by having fun, enjoyable, pleasurable, aesthetically pleasing and motivating.

CONTEXTUAL INQUIRY

The designer works as an apprentice to the user in 4 principles:

• Context – Emphasize on going to workplace and seeing what happens.
• Partnership – Developer and user should collaborate in understanding the work.
• Interpretation – Observations must be interpreted in order to be user in design and the interpretation should be in cooperation between user and developer.
• Focus – Keeping the data gathering focused on your goals.

SCENARIOS

• It is an ' informal narrative description'.
• Describe human activities such as exploration and discussion of context, needs and requirement.
• Do not explicitly describe use of software or other technological support to achieve tack.
• Easy for stakeholders to relate.

USE CASES

• Emphasis on user-system interaction rather than the user's task itself and it’’s from the user’s perspective, not the system’s.
• User called an ‘actor’.
• Mainly use case describes normal course or sets of actions that is commonly performed.
• It can be described graphically by using case diagram.

ESSENTIAL USE CASES

• Developed to combat the limitations of scenarios and use cases
• It represents abstractions from scenarios and try to avoid the assumptions of a traditional use case.

TASK ANALYSIS

• Used mainly to investigate an existing situation, not to envision new products
• Analyse the underlying rationale and purpose of what people doing

week 8 - Yau Fen Nie

REQUIREMENTS

Types of Requirements

Functional requirements

Data requirements

Environmental requirements

User characteristics

User goals

user experience goals

Functional Requirements --> Capture what the product should do.

Data Requirements - Capture the type, volatility, size or amount, persistence, accuracy and value of the required data.

Environmental Requirements;

The circumstances in which the interactive product will be expected to operate. Besides, there are 4 characteristics of environmental requirements.

-Physical Environmental -Social Environmental -Organisational Environmental -Technical Environmental -

User characteristics;

Capture the key attributes of the intended user group -user's ability, skills, nationality, educational background, preferences, personal circumstances, physical or mental disabilities.

-The collection of attributes for a 'typical user' is called a user profile.

-Anyone product may have a number of difference user profiles.

-To bring user profiles to life, they are turned into a number of Personas.

-Personas are rich description of typical users of the product under development that the designers can focus on and design the product for.

They don't describe real people, but are synthesized from a number of real users who have been involved in data gathering exercised.

User Goals - effectiveness, efficiency, safety, utility, learnability, and tracking which is the user's performance.

User experience goals -fun, enjoyable, pleasurable, aesthetically pleasing and motivating which is the user's perception.

Data Gathering for Requirements

There are difference type of data requirements

-Interviews -Focus Groups -Questionnaires -Direct observation -Indirect observation -Studying documentation -Researching similar products -

Contextual Inquiry - Contextual inquiry is an approach that follows an apprenticeship model: the designer works as an apprentice to the user. There are 4 main principles of contextual inquiry.

-Context-

Emphasize on going to workplace and seeing what happens.

-Partnership-

Developer and user should collaborate in understanding the work.

-Interpretation-

Observations must be interpreted in order to be used in the design and the interpretation should be in

cooperation between user and developer.

-Focus-

Keeping the data gathering focused on your goals.

Data Gathering Guidelines for Requirements

- Focus on identifying the stakeholder's needs.

- Involve all the stakeholder groups.

- Have more than one representative from each stakeholder group involve.

- Support data gathering sessions with suitable props

- task descriptions, prototypes.

Data Analysis, Interpretation and Presentation

- Requirement activity is iterated a number of times before a set of stable requirements evolves, the description will expand and clarify.

- 4 techniques that have a user-centered focus and are used to understand user's goals and tasks:

- Scenarios - Uses cases - Essential use cases - Task analysis -

week 8- Leng Cheok Kuan

Requirement

This week lecturer talks about requirement. What is requirement? Requirement is a statement about an intended product that specifies what it should do or how it should perform. It should be as, unambiguous, specifies and clear as possible because everyone have different answer. For example, some of the people may think that teenager is around 17-20 and some of them may not.


Types of Requirement:
Interaction Design
- Functional Requirement
- Data Requirement
- Environmental Requirement
- User Characteristics Requirement
- Usability goals and user experience goal


Functional Requirement:
Capture what the product should do.

Data Requiremen:
-Capture the type
- volatility
-size or amount
-persistence
-accuracy
-value of the required data.

Environmental Requirement:
The circumstances in which the interactive product will be expected to operate.
There are 4 characteristics of environmental requirements.

- Physical Environmental
- Social Environmental
- Organisational Environmental
- Technical Environmental

Usability goals:
-effectiveness
-efficiency
- safety
-utility
- learn ability
-tracking which is the user's performance.

User experience goal:
-fun, enjoyable, pleasurable, aesthetically pleasing and motivating which is the user's perception.

Data Gathering for Requirements:
There are difference type of data requirements
-Interviews
-Focus Groups
-Questionnaires
-Direct observation
-Indirect observation
-Studying documentation
-Researching similar products

Contextual Inquiry
Contextual inquiry is an approach that follows an apprenticeship model: the designer works as an apprentice to the user. There are 4 main principles of contextual inquiry.

Context-Emphasize on going to workplace and seeing what happens.
Partnership-Developer and user should collaborate in understanding the work.
Interpretation-Observations must be interpreted in order to be used in the design and the interpretation should be in cooperation between user and developer.
Focus-Keeping the data gathering focused on your goals.


Data Gathering Guidelines for Requirements
-Focus on identifying the stakeholder's needs.
-Involve all the stakeholder groups.
-Have more than one representative from each stakeholder group involve.-Support data gathering sessions with suitable props
- task descriptions, prototypes.

Data Analysis, Interpretation and Presentation
-Requirement activity is iterated a number of times before a set of stable requirements evolves, the description will expand and clarify.
-4 techniques that have a user-centered focus and are used to understand user's goals and tasks:
a] Scenarios
b] Uses cases
c] Essential use cases
d] Task analysis

Week 8 - by Alice Low Soo Ying

Requirement
This week lecturer talks about requirement. What is requirement?
- statement about an intended product that specifies what it should do or how it should perform.
- should be specify,unambiguos and clear as possible
- time to download any complete web page is less than 5seconds vs teenage girl should find the site appealing.
- must know how to tell when they have been fulfilled.

Types of Requirement
- Functional (what the system should do)
- Non-functional (constraints and development)

Interaction Design
- Functional Requirement
- Data Requirement
- Environmental Requirement
- User Characteristics Requirement
- Usability goals and user experience goal

Functional Requirement
Capture what the product should do.

Data Requirement
- capture the type
- volatility
- size or amount
- persistence
- accuracy
- value of the required data.

Environmental Requirement
The circumstances in which the interactive product will be expected to operate.

There are 4 characteristics of environmental requirements.
- Physical Environmental
- Social Environmental
- Organisational Environmental
- Technical Environmental

Usability goals
- effectiveness
- efficiency
- safety
- utility
- learn ability
- tracking which is the user's performance.

User experience goal
- fun, enjoyable, pleasurable, aesthetically pleasing and motivating which is the user's perception.

Data Gathering for Requirements
There are difference type of data requirements
- Interviews
- Focus Groups
- Questionnaires
- Direct observation
- Indirect observation
- Studying documentation
- Researching similar products

Contextual Inquiry
Contextual inquiry is an approach that follows an apprenticeship model: the designer works as an apprentice to the user. There are 4 main principles of contextual inquiry.

Context-Emphasize on going to workplace and seeing what happens.
Partnership-Developer and user should collaborate in understanding the work.
Interpretation-Observations must be interpreted in order to be used in the design and the interpretation should be in cooperation between user and developer.
Focus-Keeping the data gathering focused on your goals.

Data Gathering Guidelines for Requirements
- Focus on identifying the stakeholder's needs.
- Involve all the stakeholder groups.
- Have more than one representative from each stakeholder group involve.-Support data gathering sessions with suitable props
- task descriptions, prototypes.

Data Analysis, Interpretation and Presentation
- Requirement activity is iterated a number of times before a set of stable requirements evolves, the description will expand and clarify.
- 4 techniques that have a user-centered focus and are used to understand user's goals and tasks:
a] Scenarios
b] Uses cases
c] Essential use cases
d] Task analysis