Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
76 Cards in this Set
- Front
- Back
|
identifying needs |
understanding as much as possible about users, their work, and the context of that work, so the system can support their goals |
|
|
requirements activity |
producing, from the needs identified, a set of requirements that is a sound basis to move forward into thinking about the design |
|
|
main activities |
- data gathering - analysis - interpretation - presentation |
|
|
establish requirements |
requirement arise from data gathering, analysis and interpretation activities and have been established from a sound understanding of the user's needs |
|
|
type of requirements |
- functional requirements - non- functional requirements |
|
|
types of non-functional requirements |
- data requirements - environmental requirements |
|
|
types of environmental requirements |
- physical environment - social environment - organisational environment - technical environment |
|
|
data requirements |
type, volatility, size/amount, persistence, accuracy and value of the required data |
|
|
physical environment |
lighting, noise, dust, crowded environment etc |
|
|
social environment |
collaboration or coordination, sharing is synchronous or asynchronous, physical location of team members |
|
|
organisational environment |
is there user support facilities or resources for training? communications infrastrucure is stable? hierarchy? |
|
|
technical environment |
existing technologies compatible tchnologies limitation of technologies |
|
|
user characteristics |
capture the key attributes of the intended user group |
|
|
user profile |
collection of attributes for a typical user |
|
|
personas |
rich descriptions of typical users that the designers can focus on and design for - don't describe real people - defined by the goal of the persona - includes pretend user skills, attitudes, tasks and environment |
|
|
other requirements |
usability goals user experience goals |
|
|
data gathering |
1. setting goals 2. relationships with participants 3. triangulation 4. pilot studies 5. data recording |
|
|
setting goals |
identify specific goals |
|
|
relationship with participants |
clear and professional |
|
|
informed consent form |
- confirm the purpose of data gathering and how the data will be used - participant may withdraw any time |
|
|
triangulation |
- strategy using more than one evaluation technique - provides different perspectives |
|
|
pilot studies |
small trial run ensures that the proposed method is viable be fore the real study |
|
|
data recording |
notes, audio or video recordings |
|
|
interviews |
- unstructured (open-ended ) interviews - structured interviews - semi-structured interviews - focus groups |
|
|
unstructured (open-ended) interviews |
-more like conversations - open questions used - generates rich data that is often interrelated |
|
|
structured inteviews |
- predetermined questions like a questionnaire - useful when goals are clearly understood |
|
|
semi-structured interviews |
combines of structured and unstructured interiews |
|
|
focus groups |
group interview- normally 3-10 people |
|
|
developing interview questions guidelines |
- compound sentences - no jargon or complex language - keep questions neutral |
|
|
running the interview |
- introduction - warm-up - main session - cool-off - closing |
|
|
other forms of interviews |
- telephone interviews - online interviews: email or IM - video conferencing system - feedback from : customer helpines,consumer groups, online communities |
|
|
questionnaires |
collecting demographic data can use open or closed questions questions must be specific |
|
|
response formats |
-check boxes and ranges - rating scales: likert scale and semantic differential scales |
|
|
passive observer |
does not participate |
|
|
participate observer |
partly or totally participate in the activities |
|
|
ethnography |
the way of uncovering people's real desires, of getting inside into their lives and following their own stories and interests |
|
|
direct observation in controlled environment |
occurs within a usability laboratory during the evaluation stage of the lifecycle |
|
|
the think-aloud technique |
useful way to understanding what is going on in a person's head |
|
|
diaries |
participants write a diary of their activities on a regular basis |
|
|
interaction logs |
instrumenting the software to record user's activity in a log cat |
|
|
interviews |
important that development eam members will meet stakeholders and for users to feel involved |
|
|
focus groups |
they are good at gaining a consensus view and highlighting areas of conflict and disagreement during the requirements activity |
|
|
workshops |
a very useful, practical approach to requirements workshops that emphasises planning and deliverables but also collaboration and facilitation |
|
|
questionnaires |
may be used for getting initial responses that can be analysed to choose people to interview or get a wider perspective on a particular issues that have arisen elswhere |
|
|
indirect observation |
diaries and logging are used less often within the requirements activiy. Logging may be used to provide some data about how a task is performed currently, but the information is too tightly coupled with details of the existing computer support |
|
|
studying documentation |
manuals and other documentation are a good source of data about the steps involved in an activity and any regulations governing a task. |
|
|
reserching similar products |
good for developing alternative designs helps to prompt requirements |
|
|
contextual inquiry (Holtzblatt and Jones 1993) |
an approach that emerged from the ethnographic approach to data gathering Contextual inquiry reveals what people actually do, why they do it that way, latent needs, and core values. One-on-one field interviews Conducted in the user's work or life space Focused on observing and talking with people about their on-going activities |
|
|
contextual design (Beyer and Holtzblatt 1998) |
a customer-centered design process which uses extensive field data as the foundation for understanding users’ needs, tasks, intents, and processes in order to design products and systems that meet both users’ and business’ needs. |
|
|
apprenticeship model |
the designer works as an apprentice to the user |
|
|
contextual interview |
a combination of observation, discussion, and reconstruction of past events |
|
|
main principles of contextual inquiry |
1. context 2. partnership 3. interpretation 4. focus |
|
|
context |
emphasises the imporance of going to the workplace and seeing what happens |
|
|
partnership |
the developer and the user should collaborate in understanding the work The understanding is developed through cooperation |
|
|
interpretation |
the observations must be interpreted in order to be used in design, and this interpretation should also be developed in cooperation between the user and developer |
|
|
focus |
keeping the data focused on your goals |
|
|
data gathering guides for requirements |
- focus on identifying stakeholders' needs - involve all the stakeholder groups - support the data gathering session with suitable props (descriptions, prototypes etc.) |
|
|
tools of Haumer at al. (2002) |
records concrete scenarios using video, speech and graphic media and relates these recorded observations to elements of a corresponding design. It helps to keep track of context and usage information while analysing and designing. |
|
|
tools for functinal requirements |
data-flow diagrams state charts |
|
|
tools for data requirements |
entity-relationship diagrams |
|
|
tools for functional and data requirements in object-oriented approach |
class diagrams state charts sequence diagrams |
|
|
techniques used in user-centred focus to understand users' goals and tasks |
scenarios use-cases essential use cases task analysis |
|
|
brainstorming |
widely use for generating alternative designs |
|
|
principles of brainstorming |
- should know the users' goals - no ideas should be criticised or debated - include participants from a wide range of disciplines - don't ban silly stuff - use catalysts for further inspiration - keep records - sharpen the focus - use warm-up exercises |
|
|
task descriptions |
descriptions of business tasks |
|
|
types of task description |
- scenarios - use cases - essential use cases |
|
|
scenarios |
describes human activities or tasks in a story that allows exploration and discussion of contexts, needs and requirements. |
|
|
scenario-based usability engineering |
illustrates the use of scenarios within a usability engineering framework |
|
|
use cases |
also focus on user goals, but the emphasis is on a user-system interaction, but from the user's perspective |
|
|
essential use cases |
represent abstractions from scenarions; they represent a more general case than a scenario embodies, and try to avoid the assumptions of a traditional use case. Instead of actors, it uses user roles. |
|
|
3 part of essential use case |
- a name that expresses the overall user intention - a stepped description of user actions - a stepped descriptions of system responsibility |
|
|
task analysis |
used mainly to investigate an existing situation, analyses the underlying rationale and purpose of what people are doing An umbrella term for investigating cognitive process and physical actions, at a high level of abstraction and in minute detail |
|
|
techniques of task analysis |
Hierarchical Task Analysis GOMS (Goals, Operations,Methods, Selection rules) |
|
|
Hierarchical Task Analysis |
involves braking a task down into subtasks and then into sub-subtasks and so on. focuses on the physical and observable actions that are performed , and includes looking at actions that are not related to software or an interactive productat all |
|
|
GOMS (Goals, Operations, Methods,Selection rules) |
GOMS is a family of predictive models of human performance that can be used to improve the efficiency of human-machine interaction by identifying and eliminating unnecessary user actions. GOMS stands for (Goals, Operators, Methods, and Selection). |
|
|
KLM-GOMS |
The simplest and most frequently used GOMS variant is KLM-GOMS (Keystroke-Level Model), where empirically derived values for basic operators like keystrokes, button presses, double clicks, and pointer movement time, are used to estimate task times. |
