d0107 media design and integration lecturer: merja bauters [email protected]
TRANSCRIPT
Course Description Course: D0023/OJ/2000 Media Design and
Integration (obligatory course) 3 credit weeks (points).
Previous courses that should be completed: D0009 Visual Design
Aim of the course: To understand the product process of different digital products from the user side namely to be able to understand the intertwined nature of technical software design process the user experience design process.
Course Description Design theories, cognitive, user-centred design (e.g.,
participatory), End-user development... Design methodologies (ethnographic, scenario-based,
activity theory based) Some basic testing / evaluation methods of usability are
introduced in the lifecycle of the product and practises made with this issue.
The art and science of interface design will also be studied through examination of real case studies.
Hands on practices related to the above Participation as end-users to test actual
mock-ups/demos/products
Course Contents
36
Descriptio n of the course , a ctivities , produ ct process s tarts .
37
Para llel desig n met hod in parti cipa tory desi gn
38
Conte xt a nd Users
39
Pro totyp ing practice s (rapi d pro totyping)
40
Othe r desi gn m e thod ologie s (et hnograp hic, scenari o based, involvi ng users)
41
User experienc e Criteria
42
User experienc e Criteria
43
Star t of basi c usab ility testi ng m e thod ologies
44
Proje ct a nd s e lf stud y week
45
Exa m we ek
46
Usabil ity me thods continues
47
Usabil ity me thods continues
48
Exhib ition / event
49
Convergence
50
Star t of basi c usab ility testi ng m e thod ologies
51
Summary an d ex a m tips
52
Chris tmas holiday
1
Proje ct a nd s e lf stud y wee k
2
Proje ct a nd s e lf stud y week
3
Exa m we ek
Course Objectives After completing the course the student will
understand the background for different methodologies for design and be able to choose and mix the appropriate ones for a particular product design Understand the design challenges Be able to see the need of testing as integrated
to whole design process Integrate design of different elements into the
product taking into account the context and the user as active actors
Envision and judge the “hypes” in media design
How to pass the course Exam in the second period’s exam
week. Labs every week. Activity during the course! (includes
suggestion of visiting exhibitions etc, taking part in lecture discussions, providing idea for other topics....)
The Design Process - Objectives Software engineering provides a means of
understanding the structure of the design process, and that process can be accessed for its effectiveness in interactive system design.
Design rules in the form of standards and guidelines provide direction for design, in both general and more concrete terms, in order to enhance the interactive properties of the system.
Usability engineering promotes the use of explicit criteria to judge success of a product in terms of its usability.
The Design Process – Introduction Software engineering addresses the
management and technical issues of the development of software systems.
Software life cycle describes the activities that take place from the initial concept formation for a software system up until its eventual phasing out and replacement.
The issues from HCI affecting the usability of interactive systems are relevant within all the activities of the software life cycle.
The Software Life Cycle There are two parties in the development of a software
product: Customer who requires the use of the product Designer who must provide the product
Typically, the customer and the designer are groups of people and some people can be both customer and designer.
It is important to distinguish between the customer who is the client of the designing company and the customer who is the eventual user of the system. (These roles can be played by different people.)
Activities in the Life Cycle Requirements specification Architectural design Detailed design Coding and unit testing Integration and testing Maintenance
The analogy of the waterfall (in the next slide) is not completely faithful to the real relationship between these activities, but it provides a good starting point for discussing the logical flow of activity.
Waterfall ModelRequirementsSpecification
ArchitecturalDesign
DetailedDesign
Coding andUnit Testing
Integrationand Testing
Operation andMaintenance
The activities in the waterfall model of the software life cycle
Interactive Systems and the Software Life Cycle - Iteration
The traditional software life cycle does not promote the use of techniques which support the user’s perspective of the interactive system. (The purpose of validation and the formality gap.)
No structured development process will entirely eliminate the formality gap, the particular techniques used can go a long way towards making validation of non-functional requirements feasible with expert assistance.
Project process/waterfall:iteration need of interaction between parties Guidelines Prototyping Design rules Standards Cyclical and iterative Involving users
Projectprocess: cycle
Project Process- scenario based
Parties
All parties involved in the product development cycle, including the executives (who must make decisions about strategic directions), the product managers (who must keep in constant communication with the customer community), and of course the development team, have a clear understanding of the business context where the product line lives. Thus, everyone is on the same page when discussing requirements, features, and product positioning. Furthermore, the development team finally has the means to achieve the customer orientation that is always asked of them. Having defined which parts of a process are common among all customers -- and which are implemented optionally -- also helps guide the prioritization of the product's features.
Understanding the customer Understanding the users Conceptual design
Parties
The process needed to implement the workload scheduling, including:
what are the different activities how they are related who is responsible for each of them which artefacts are exchanged during the process
The goals, set by the organization/institute etc, that the process supports. This includes understanding:
what are the goals how each of them is measured who sets each goal
KP-Lab Design Approaches
Anders Mørch, Anne Moen, Sten Ludvigsen
InterMedia, University of OsloKP-Lab WP2: Challenges, methodology, example
Linz, April 20-21, 2006
Design techniques Scenario-based design Empirical-based design Participatory design Theory-based design Evolutionary design The techniques are partially overlapping
and are often used in combination
Scenario-based design Simulation of future (envisioned) use A textual description with (or without) screen
mock ups depicting an imagined sequence of interactions with a simulated system
The context of the setting should be included in the description, so that the scenario is meaningful to as many as possible (see PD)
Two types Generic (domain independent) Specific (domain specific)
Empirical-based design (also called iterative design, prototyping)
Suggest answers to empirical questions Involving real users in order to support
their needs, not primarily the needs of system developers
Iterations of system building and evaluation with end users
Evaluation is often done as testing in “usability labs”, but can also be done using other means (see PD)
Participatory design User participation in the early phases of system
development Users are considered equal partners with
developers at this stage Often referred to as “Scandinavian approach” to
system development (stressing democratic design) Understand what goes on at a workplace and in
interaction between workers and their tools Technology as “mediating artefact” alongside
other artefacts, including profession-oriented languages
Mutual learning and use of low-fidelity prototyping techniques (see SBD & EBD)
Theory-informed design
Using theories to inform and ground a design Psychological theories in HCI have been used to
create conceptual models and design principles, and this is often referred to as theory-based design
The models or design principles can be used again and again to create designs
When the theory (or theoretical idea) is taken all the way, we call it theory-informed design, in which the goal is to express a theory or idea in visual form, examples include Coordinator (speech act theory) Janus (reflection-in-action) FLE (progressive inquiry)
Evolutionary design
Develop a new system based on existing system(s) This is often the default approach for many developers,
even without being aware of it, because many developers have a repertoire of tools to build from
Start from something that works, which is open to low level inspection and code reuse (API and/or source code)
Find out what can be improved with the existing system and add the improvements to it
Can be used in different ways within one system (e.g. extending a system into a new
release); from one generation of system to another (e.g. product
families); from one technology to another (mock up to computer display)
Example Integrating participatory design and
evolutionary design, using scenarios and empirical-based design (LAP/Statoil case)
E-learning introduced with PD and evolutionary design techniques How can participatory design be
useful for E-learning? Approach:
Participatory design from beginning to end
Users participated as designers in the beginning and as evaluators in the end
Mock-ups developed in Utopia project in the 1980s (early PD project)
User interface in cardboard and paper
Laser printer made from cardboard box
LAP project Learning and Knowledge Building at Work (LAP is
the acronym in Norwegian) 3 year project among researchers and service
industry companies in Norway (2001-2004) Goal: Introduce e-learning in two large
corporations in Scandinavia (Statoil Detaljhandel and Visma Services)
Empirical studies of the adoption process Analyze empirical and technical innovation
Statoil – The gas station division Goal: develop an e-learning system for gas
station attendants and identify new learning opportunities to supplement traditional training
The work at the gas stations is mostly manual labor; serving customers is the main task of the employees
Young staff with average 12 months on the job Knowledge demand is high, ranging from how to
prepare hot food to knowing the details about automobile products
Techniques employed Involving employees at multiple levels in
a design workshop Intermediate abstractions: creating a
smooth transition from user representations to software system
Evolutionary design: transfer knowledge and code from one system to another in incremental steps
Design workshop Focus groups Learning scenarios Role playing Mock-ups Breakdown (constructive
intervention)
Identifying work situations that can be improved (focus group)
Learning scenarios Create
Collaborative design in groups of 4 Including station attendants and regional managers Half day session recorded on video
Acting (demonstrated in 3 video clips)– Illustrate current work situation (and learn role playing
technique)– Simulate a future situation that improves upon current
work practice– Breakdowns and creative work-around (with drama
instructor) to invent new ways of working and learning
Role playing situation
Mock-up information display created by one of the employee groups
Intermediate abstractions
Evolutionary design
Transforming a mock-up to a computer prototype in multiple stages
Intermediate abstractions aided the process, bridging informal and formal representations
Computer prototype v.1
First prototype crated by IT dept. in Statoil based on one of the intermediate abstractions
Installed at pilot station for 3 months
Software prototype v.2 Using
ColdFusion a Flash-like environment
Vertical prototype of selected functionality
Third prototype: Laptop interface Third prototype has more functionality than its
predecessors, but turned out to be less user friendly Company profile alignment became as important as local
engagement Two-level grounding was accomplished: top-down
(management) and bottom-up (user participation) System integrates well with the company’s advanced
information and communication infrastructure Deployed at 25 gas stations as of 7/2004 Roll-out to more stations planned during 12/2004
Computer prototype v.3
Laptop located at the end of the counter, in-between two activities: Serving customers and back-office activities
Lesser functionality than v.2, but better integration with company information infrastructure
Computer prototype v.4 (current)
The system has been integrated as a separate screen in the cash register interface, early 2005
It has been deployed in 300 gas stations, some of them outside Norway
We have not yet made any follow-up study of use Based on my own inquires at local stations it seems
use is sporadic and for other purposes that was intended, no new practices has emerged
A reported problem is that it interferes with the operation of the cash register, i.e “risky” to use
Found that the co-existence of multiple generations of technologies for information finding works fine
Lessons learned Importance of interacting multiple
design techniques Transformation from informal (user
oriented) representations to software systems
To generalise: Multiplicity and cross-disciplinary transformation and integration
Horizontal/vertical integration
Technology
Activity
Social practice
Hardware – tech. infrastructure
Software -
Interaction through shared objectsabout authentic issues
Interaction and transformation
Middle wareInfrastructure
Tools and services
Applications
Design doc. OntologiesSpecification
Standards
Examples
Week 37 (10.9) Opening of the deliverables needed in the
process Background on scenario-based theory User-centres (EUD) Reading related today’s lecture:
Cognitive theories: Norman, D.A. (1988) The psychology of everyday things. Basic Books. http://www.jnd.org/
Preece, J., Rogers, Y., Sharp, H., Benyon, D., Holland, S. & Carey, T. (1994) Humancomputer interaction. Addison-Wesley.
Ben Shneiderman: http://www.cs.umd.edu/~ben/ Jef Raskin: http://jef.raskincenter.org/home/index.html Sinkkonen, Irmeli, Kuoppala, Hannu, Parkkinen, Jarmo, Vastamäki, Raino: Psuchology of
usability. IT Press (2006). Agile development http://www.versionone.net/Resources/AgileDevelopment.asp