Exam 4

The process of product design

1. Understand what the users need and/or want (whats in demand)

2. Create a product

3. Evaluate the product relative to users’ needs/wants

This a closed loop system that always feed into each other > there can be external factors; people can create need, external events (COVID > masks).

Good design is an iterative & evolutionary process

The evaluation of bikes

Build, evaluate, improve, evaluate, improve, evaluate

With each generation, features are improved, added, delated

Engineers are not typical users

Where designers go astray

They know the product in detail, they have mental image of the product thats deeper then the population

Engineers are not the consumers they don’t understand the users

Creeping featurism

Where designers go astray

The primary symptom of featuritis

Engineers add features that few users are wanting/asking for but everyone has to deal with & pay for

Image concerns may outweigh function

Where designers go astray

Engineers are concerned with the product looking cool or imposing aesthetics instead of allowing form to follow function

Form, follow, function > the form is designed/created by its function,

Image concerns: form should follow function

Engineers take a “reductionist” approach

Focus is on product function

Products are divided into components

Components designed to meet specifications

Components are assembled into products

They don’t look at the big picture but at the pieces and how it would work in the real world

Human factor specialists take a “systems” approach

Focus is on product use

Component systems interact with each other

Product interactions with user in a environment

They see how the pieces connect to each other the bigger picture of the product

Engineers may no see Human Factors as equal partners

Engineers underestimate the importance of human issues

Human factors specialists often don’t present information in a way that is familiar or useful to engineers > They might not speak the language

Human factors specialists may need to market their skills

Product sales > increase if the quality/productivity is improved

Training costs > reduced

Reduced errors > of user error/resulting court costs

Personnel savings > because of reduced error, turnover, accidents

Manufacturers priorities (1)

Want production to be inexpensive

Ability to use existing production systems and processes

Inexpensive materials and components

Distributors priorities (2)

Want products that retailers will stock

Established, popular and high volume products

Shipping costs matter too

Retailers priorities (3)

Want profitable sales

Desirable and prestigious brands

Attractive product and packaging

Purchaser priorities (4)

Not this be the user

Builder grade materials in new construction > someone else buys the supplies

Stock options in cars

Software system in organizations

What do users value in product

Price > What costs less

Features

Dependability

Usually in this order

Sometimes prestige > wild card some people really care for it and others don’t, may be higher or lower priority depending upon the users & the visibility of the product → Rolex

The poor consumer cycle

They are constantly having to buy the cheap product because they have no choice they need the product they are spending more money on poor products → in the long run they are spending more money

Versus those that are higher income are able to buy the more expensive product up front and saving money in the long run

Understanding users’ needs: Tasks analysis

Observe people and their tasks, from their view

Access the non-behavioral goals and processes

“people who buy a ¼ drill bit actually want a ¼ hole”

Front end analysis

Done at the very start of the design process before the design begins

Front end analysis: user issues

Who are the user, what are their ability and preferences

What are their tasks, what do they wish to accomplish with the product

What is their environment > the physical or social situations factors

What tasks must the product fulfill, what is everything it must do

Front end analysis: Design constraints

Balancing what the user wants with the physical limitations that the product has

Not all features are equally attractive or equally expensive > Cost benefit analysis

Would putting in that feature pay off for the company

Front end analysis: Design heuristics

List the design goals & requirements (used guid books to help/HF handbooks)

Products has to have a certain look & feel to be the product > Apple Mac

Think about who is the intended population & what would they value

Collecting Task & process data: Direct observation

Seeing how the user is using the product in real time

See the environment where the product is used in & see what needs to be added to be helpful

Collecting Task & process data: Verbal protocol

Have the user speak out loud when they are using the product to understand better whats happening and how the product is being used & whats the goal

People vary in the ability to recognize and verbalize their own actions

Collecting Task & process data: Interviewing

Faster way to get the needed information but aren’t given a deeper understanding of the product

Can be individual or groups

Understanding user’s needs

One way is through surveys and questionnaires

Surveys strengths

They are cheap and easy to reach a large number of people

They are flexible and can ask questions about literally anything

Survey weakness

Representative sample of users is important and difficult to get

Can lead to asking bad questions > leading, confusing, ambiguous question and making sure the sentences are appropriate for readers

You only get answers to questions you ask > you don’t always know what to ask, wished you offered other options, wised you asked other follow up questions

Doing a pilot survey is essential but its easy to over look

Existing records

Understanding users’ needs

Using past information > production data, complaints, and repair orders to guide the design of a product, because companies are already collecting & keeping that data

Objective data is not free from bias or contamination

Consider the task (not just the product)

Creating the product

Consider possible scenarios where the product will be used in > place yourself in the user’s role - where am I using it

Functional allocation > task might be part of a larger goal, which of the tasks should the product take over & which ones should be left to the user

Create user personas > invent a hypothetical user/ image one user for each groups that use the product

Prototypes and mock-ups

Creating low-fidelity mock-ups can give user feedback

As the product development continues, high-fidelity prototypes are made

> Hand-drawn examples of software layout/cardboard cut-out with sticker for displays

Evaluate the product

Creating the product

Put the product in the users hands

Focus groups/pilot tests/ verbal protocols

Use the information gained to the next iteration

Support materials (user centered)

Creating the product

User guides, instructions/References, manuals/Training programs

Usually written from the engineer’s point of view > arranged by components

They should be written for the user’s point of view > arranged by tasks/goals

As the product is tested, note what user’s ask and misunderstand

Norman’s Seven stages of action model

1. Establish a goal

2. Intention to act

3. Action specification

4. Interface mechanisms

5. Interface display

6. Interpretation

7. Evaluation

Establish a goal

What do I want to accomplished

Bridge gulf of execution

Over the gulf between goals and system actions

Intention to act > User forms a specific goal to pursue

Action specification > User identifies an action or sequence to carry out goals

Interface mechanisms > User executes system controls

Bridge of evaluation

User to evaluation system state relative to goals

Interface display > user must perceive the system state

Interpretation > user must interpret the underlying system state

Evaluation > user must evaluate the system state relative to goals

Mental models

Perception is the formation of an internal representation of the external world

Software doesn’t have a physical external world to represent

Software stems from the designer’s mental model

Users’ mental model

The users’ mental representation of the software’s conceptual model >

Users’ mental models are usually incomplete, fragmented, unstable

Users may have different mental models for different facts of the software

Are based on users’ inferences from inputs & outputs