Unit 3: The process of interaction design Flashcards Preview

M364 Revision > Unit 3: The process of interaction design > Flashcards

Flashcards in Unit 3: The process of interaction design Deck (44)
Loading flashcards...

Fundamental activities of all design and additional one for ID.

Understand requirements.

Produce design to satisfy requirements.

Evaluate design.

ID has focus on users and goals. Additional activity:
Produce version of design user can interact with.


Why is it important to involve users? (2)

Someone who performs task everyday (or will use product regularly) will have a unique perspective that can't be replicated.

Developers can better understand users' goals if they're involved throughout - product will be more appropriate and usable.


2 aspects nothing to do with functionality that are just as important if the product is to be usable and used?

Expectation management.



Expectation management (def and purpose).

The process of ensuring user's views and expectations of the new product are realistic.

The purpose is to ensure there are no surprises when the product arrives - otherwise may cause resistance or rejection.



Users who are involved and feel they've contributed are more likely to feel 'ownership' towards it and be receptive when it emerges.


Degrees of user involvement with brief comment.

Full time, whole project:
Consistent input and very familiar with system.
May lose touch with the rest of the group - input less valuable.

Part time, whole project:
Consistent input, while remaining in touch with the group.
Deal with new jargon/material while fulfilling original job.

Several users form each user group part time for a limited time:
Input may not be consistent, but coordination between users can alleviate this.


Disadvantages of involving users. (4)

Users may develop sophisticated ideas they want late in the project.

Fear of job losses - may be less constructive.

Unpredictable, not sympathetic to software development matters.

May lead to higher aspirations, therefore higher stress.


Aspects of a well-designed system. (3)

Makes the most of human skills and judgement.

Is directly related to the work in hand or other activity.

Supports rather than constrains users.


Gould and Lewis - 3 principles to a "useful and easy to use computer system."

1. Early focus on users and tasks.
Find who users will be by studying users and users doing tasks.

2. Empirical measurement.
Early in development - user reactions to printed scenarios, manuals, etc.

3. Iterative design.
'Design, test, measure, re-design' repeated.


'Early focus on users and tasks' (Gould and Lewis) - further 5 principles.

1. User tasks/goals should be the driving force behind development.

2. Users' behaviour and context of use should be studied, and the system designed to support them.
('How' people perform tasks).

3. Users' characteristics (general and specific to group) should be captured and designed for.
(Should account for cognitive and physical limitations).

4. Users should be consulted throughout development, and their input taken seriously.

5. All design decisions are taken within the context of users, their work and environment.


'Empirical measurement' (Gould and Lewis). (2 points)

Identify, document and agree specific usability and user experience goals at the beginning of the project.

The product can be empirically evaluated at regular stages, to ensure the final product is as intended.


'Iterative design' (Gould and Lewis).

Revision needed in light of feedback, several times.


Intro to 'Identify needs and requirements for user experience'.

Must know target users so you can support them.
Needs form basis of requirements and underpin design and development.


Intro to 'Developing alternative designs that meet those requirements'. (I.e. reqs for user experience).

Core design activity - suggesting ideas to meet requirements.

2 sub activities:
- Conceptual design - produce conceptual model which describes what product should do, look like and behave.
- Physical design - details, eg. colours, sounds, images, menu/icon design.

Alternatives considered at every point.


Intro to 'Building interactive versions of designs'.

Most sensible way for users to evaluate is to interact.

Doesn't have to be software - eg. paper-based prototypes very effective to identify problems early.


Intro to 'Evaluating what is being built throughout the process and the user experience it offers'.

Determine usability and acceptability of the product/design.

Evaluation complements and enhances QA and testing.


Questions if we're going to be able to 'do' ID in practice. (4)

Who are the users?

What do we mean by needs?

How do you generate alternative designs?

How do you choose among alternatives?


Who are the users?

Obvious - people that interact directly with the product to achieve a task.

Others - occasional users, users via a 3rd party, receivers of products via system, testers, etc.


Stakeholders. (def and examples)

People or organisations who will be affected by the system, and who have a direct or indirect influence on requirements.

Eg. development team and its managers, direct users and their managers, recipients of product's output, people that may lose their job, etc.


What do we mean by needs?

Need to understand the characteristics and capabilities of users, what they're trying to achieve, how they're currently achieving it and if they could achieve their goals more effectively/enjoyably if supported differently.


How do you generate alternative designs? (3)

Cross fertilisation of ideas from different applications.

Evolution of existing product through use and observation.

Copying from similar products.


How do you choose among alternative designs? (2 categories)

1. Externally visible and measurable features.

2. Characteristics internal to the system that can't be observed or measured without dissecting it. (Underly features in 1.)


4 general stakeholder groups (with examples).

Beneficaries - benefit from project, or life made easier.
Eg. shareholders, senior management, internal users, customers.

Decision makers - decide what to do in project.
Eg. manager, or someone controlling resources like personnel available to work on development team.

Gatekeepers - control access to other groups needed for project.
Eg. secretary controls access to senior manager who make decisions.

Workers - workload affected, often increased - learning new process. Job may be at risk.


Choosing the best design. (2)

Identify a number of aspects of product performance that can be compared between the designs. (Part of 'identify needs and requirements for the user experience').

One way to assess how well designs meet these is to prototype each of them.


Lifecycle models. (2 points)

Considers a set of activities and how they're related - when and how to move from one activity to the next, and deliverables for each.

Allow developers, and particularly managers, to get an overall view of development effort so progress can be tracked, deliverables specified, resources allocated, targets set, etc.


Disadvantages of Waterfall lifecycle model. (2)

Requirements change over time (as business and environment change). Doesn't make sense to freeze requirements while design and implementation are completed. (Iteration now usually incorporated).

Opportunity to review / evaluate with users was not built into this model.


Spiral lifecycle model.

Incorporates risk analysis and prototyping into an iterative framework that allow ideas and progress to be repeatedly checked and evaluated.

Each iteration may be based on a different lifecycle model and may have different activities.


Further points on Spiral model. (3)

Inspiration for iteration - the need to identify and control risks.

Plans and specifications that are risk-focused drive development rather than functionality (in contrast to Waterfall).

Explicitly encourages alternatives to be considered (unlike Waterfall), and has steps in which (potential) problems are encountered to be addressed.


WinWin spiral.

Explicitly encorporates the identification of key stakeholders and their 'win' conditions - a satisfactory outcome for each stakeholder.


Rapid Application Development (RAD).

Characterised by time-limited development cycles and workshops in which users and developers come together to determine requirements.