Flashcards in Block 3 - Unit 1: Understanding and conceptualising interaction Deck (83)
Loading flashcards...
1
4 key concepts to the design process without concentrating on a detailed design level.
1. Conceptual models.
2. Interface metaphors.
3. Interaction types.
4. Interface types.
2
Problem space.
The range of possible conceptual models for a product, together with their rationales (ie. advantages, disadvantages, implications and justifications).
Don't need detailed conceptual models to understand problem space.
3
How should the design process start? (4)
Reflecting on what you intend to create.
Thinking through how it will support people in their everyday or working lives.
Considering whether it will support people in the way you intend.
Justifying why you want to create it.
4
Why not start by thinking about the physical interface, technology and interaction styles?
Usability and UX goals can be overlooked.
Better to decide on physical design aspects after describing the nature of the problem space.
Ie. understand and conceptualise current UX / product and how it will be improved or changed.
5
Assumptions and claims.
As well as user needs, usability and UX goals, a set of assumptions and claims relating to these is important.
Uncovering and challenging these assumptions will give you a better understanding of what you're trying to achieve, and will refine the existing goals and requirements.
Assumption - take for granted. Eg. 'people will want to watch movies on their mobiles'.
Claim - states true when still open to question. Eg. 'using speech interactive system in a car is safe'.
6
How is articulation of a problem space typically done?
As a team effort.
Different perspectives among a team - eg. PM - budget; engineer - technical concepts.
Important implications of pursuing each perspective are considered in relation to one another; time-consuming, but very beneficial.
Less chance of incorrect assumptions and unsupported claims entering the design solution.
Reflecting early on ideas enables more options to be considered.
7
Framework for a team to view multiple perspectives and reveal conflicting and problematic assumptions and claims. (4)
Are there problems with an existing product or UX? If so, what?
Why do you think there are problems?
How might proposed design ideas overcome these?
If you have not identified any problems and instead are designing for a new UX, how will the proposed design support, change or extend current ways of doing things?
8
Next step after exploring the problem space?
Begin to conceptualise a design solution and develop a conceptual model.
9
Conceptual model?
A high level description of how a system is organised and operates.
It is an abstraction that outlines what people can do with a product and what concepts are needed to understand how to interact with it.
10
What a conceptual model is NOT?
Not a description of the UI, but a structure outlining the concepts and relationships between them that will form the basis of the product or system.
"Straighten out thinking before starting laying out widgets."
11
4 components of a conceptual model.
Major metaphors and analogies.
Concepts users are exposed to through the product.
Relationships between those concepts.
Mappings between the concepts and UX the product is designed to support / invoke.
- How the various metaphors, concepts and their relationships are organised determines how the users will subsequently think of a product and the operations they can do with it.
12
Major metaphors and analogies (eg. upgrading web browers).
Used to convey to the user how to understand what a product is for and how to use it.
Metaphors:
- Browsing - following links through exploring what is there.
- Bookmarking.
Analogy - window shopping.
13
Concepts users are exposed to through product (eg. web browers).
Include task-domain objects they create and manipulate, their attributes, and the operations that can be performed on them.
Eg. Web pages (URLs), dynamic and static web pages, links, lists, folders of URLs, saving / revisiting a URL, etc.
14
Relationships between concepts (eg. web browers)
Eg.
- one object contains another,
- relative importance of actions to others,
- object part of another.
Eg.
- folder contains a collection of related URLs
- ability to add URL to a list is more important than the ability to move the position of a a saved URL around,
- dynamic page - special kind of page (object is a specialisation of another).
15
Mappings between concepts and the UX (eg. web browsers).
Saved URL corresponds to a web page on the internet. When the URL is clicked, the browser points to the page and displays it.
16
Advantage of exploring the relationships between components of a model.
Can debate the merits of providing different methods and how they support the main concepts.
17
Benefits of early conceptualisation. (3)
Orient the team towards asking specific kinds of questions about how the conceptual model will be understood by the target users.
Not to become narrowly focused early on.
Establish a set of common terms, reducing misunderstandings later.
- Model becomes a shared blueprint - textual or diagrammatic; basis to develop more detailed and concrete aspects.
18
Dilemma - over-specified apps.
Best models appear simple and clear to users and are task-oriented.
May be difficult in practice - models can become complex, with more functions and ways of doing things added to original conceptual model.
19
Simplest way to develop a conceptual model.
Say the product will be 'like' some other product or system. Then, detailing specifically how the new product will differ.
20
Sources on which to base your decisions, and the kinds of technique for capturing the conceptual model. (3)
Output of requirements activity (eg. in Volere shells).
Existing products or systems in same / similar market.
Usability goals and UX goals.
21
Conceptual model (UB).
'...an idealised view of how the system works - the model designers hope users will internalise'.
Model should be as simple as possible while still supporting the required functionality, and there should be a clear mapping between the system and the task domain being supported.
This helps users understand the system so their model of it is as accurate as possible.
22
What a conceptual model is NOT (UB). (4)
The User Interface.
Users mental model of the system.
Set of use cases.
An implementation architecture.
23
Why is a conceptual model not the UI?
Should describe only what people can do with the system and what concepts they need to understand to operate it.
The UI is only one possible implementation.
Model ignores details of layout, colour, etc. - forces the designer to think abstractly.
24
Why is a conceptual model not a user's mental model?
Mental model - construct in a user's head consisting of knowledge of how to use something and of how it works.
A conceptual model is generated through the design process, a mental model evolves with use of a system.
Aim to help users develop a mental model of the system that matches designer's own model.
25
Why is a conceptual model not a set of use cases?
Use cases capture task description. They are too detailed for the conceptual model and represent only one possible interaction style.
Also, use case focus at task level - conceptual model is concerned with the system as a whole.
26
Why is a conceptual model not an implementation architecture?
The focus is on technology and instantiation issues rather than users' interaction with the system.
Also, unlikely to be understandable by most users.
27
Interface metaphor.
An entity which will be familiar to the intended users, and will form the basis of the design of an interaction.
Considered a central component of a conceptual model. Provides a structure that is similar in some way to aspects of a familiar entity (or entities) but has its own behaviours and properties.
28
Why are metaphors / analogies popular?
They can communicate a lot of info, based on experience, relatively quickly.
Using a familiar entity from users' domain can help explain by comparison something unfamiliar / hard to grasp.
29
Ways metaphors are used in ID. (3)
To explore and communicate ideas to other designers (may be otherwise abstract and hard to imagine / articulate concepts and interactions).
May become part of the final system and help users to understand the system.
May surface as names for operations within the interface.
- Even if metaphors don't appear in the final system (recognisably), they can help with the thinking process that results in the final conceptual model.
30
