Post on 19-Jan-2018
description
Supporting the design of interactive systems
a perspective on supporting people’s work
Hans de Graaff27 april 2000
Designing interactive systems is hard
We all know problems with interactive systems…
Show of hands
The real problems often go unnoticed
Interactive systems for... Computing support for problem solving
and decision making Ill-structured work
The interaction dilemma Positive side
interactive systems help us to get our job done Allow us to do more and different things than before
Negative side Interactive systems get in the way of getting the job
done They often have many inherent assumptions about
the way we work
Circumstancial evidence for the dilemma
Productivity doesn’t rise as quickly as we would expect
Usability studies find many problems in systems
How did this happen? User-centered design is a way out
… but which way to go? Evolution of HCI
Realization Analysis Design
Research objective To explore how explicit attention to
work context early in the design process can be used to improve the usability of interactive systems facilitating ill-structured work
Underlying paradigm An interactive system should be
designed as a whole and from the perspective of the its users first
Research questions How can we formulate the design
activity for interactive systems which facilitate ill-structured work?
How can ill-structured work be described explicitly during design without reverting to interface components?
Research approach Action research Participant comprehension Understanding the topic from the
inside out
Current support for analysis
Task analysis/modeling With added contextual knowledge With decision structures
Contextual inquiry Ethnography Activity theory
Current support for design
Support is far from complete Expose and UIDE: very rigid
information requirements Task-oriented approach: too flexible,
mostly prototyping Representation of interaction not high-
level enough
Requirements on a theory Include artifacts and activities Include contextual information Include support for ill-structured work Balance structure and freedom Build on analysis results Support multi-disciplinary design team Usable design representation
WONDER A Workspace-oriented Design
Representation
The workspace Workspace is a place where a specific
job can be done Example from the real world: the
watchmaker
Watchmaker’s workplace
Watchmaker’s workspaces
Way of thinking: background
Mental models Hierarchies of objectives Artifacts Ill-structured tasks Ambiguity and inconsistency
Way of thinking: elements Workspace is a place where getting a
particular job or set of jobs done is supported Materials are the information that needs to
be changed or used to accomplish the goals Actions are generic operations that apply to
more than one material, or that need to be present in more than one workspace
Tools provide a means to inspect or change a material in the context of a particular workspace
Way of modeling Model containing both structured and
unstructured information Media for the model: text Representations for workspace,
material, and actions Tools are contained in workspace
descriptions
Way of working Finding workspaces Assessing workspaces
Too simple Too complex Add new workspaces Completeness checks
Refining workspaces
Way of controlling General project management issues Multi-disciplinary design team
Interaction designer Domain expert Project manager Visual designer Software engineer Participating users
Team leader Domain expert
Way of supporting Computer assistance is needed Automated checks to help structure the
models
Also Version control Generation of different overviews
Automatically created overview
Getting back to the requirements
Include artifacts and activities: yes Include contextual information: yes Include support for ill-structured work: yes Balance structure and freedom: yes, needs
testing Build on analysis results: yes Support multi-disciplinary design team: yes,
needs testing Usable design representation: unclear, needs
testing
Use of WONDER in a design process
Testing WONDER on a real-world problem
See how WONDER really works Get the experience of designing with
WONDER
ShipShape Shipyard planning Mostly management of capacity Also needed: management of cost and
progress Ill-structured work: problem solving
and decision making
Example capacity view
Reflecting on finding workspaces
Analysis results were used Initial workspace discovery done using
a diagram Easier to change and move around things Easier to discuss and annotate
Example early design diagram
Annotated diagram
Reflecting on assessing workspaces
Not many changes were made through assessment
Almost all possible assessment have been encountered
Much of the assessment had already been done in the diagrams
Reflecting on refinement (1)
Step 1: gradually adding information Basically correct, but information often added in
clusters instead Three types of workspaces have emerged
» Workspaces which tie things together related to high-level goals
» Workspaces which help to carry out a more detailed goal
» Workspaces containing common tools for the domain
Reflecting on refinement (2)
Step 2: Focus on just questions and warnings too narrow Also incorporate progressive insight Use of consistency checks and overviews could be
made explicit
Assumptions WONDER can be used to describe ill-
structured tasks: yes The description of ill-structured work
matches the perception of that work by both the domain expert and participating users: not always Sometimes users had trouble translating
workspaces into support in their workplace. Perhaps visualizations could have helped
Assumptions All relevant information for a correct
interpretation of the WONDER descriptions is contained within them: no Some visual additions were needed
Assumptions The different design team members can
all work with WONDER: yes, but... The WONDER descriptions could be worked with easily The support prototype only really supported browsing Editing was a bottleneck
The design activities are a correct representation of the actual use of WONDER: yes For the most part, although some small refinements can
be made
Assumptions All aspects of WONDER are utilized, none
are avoided: yes No crucial information related to the early
design process is kept outside of WONDER: partly true The diagrams were used at the start Visual additions became important in the end
The time taken to use WONDER is worth the results it yields: yes The design team did have the perception that using
WONDER was worth it
Assumptions Each workspace confirms how users think
about that part of their work: yes Each workspace allows the users to
accomplish the goals associated with the workspace: yes, but… Improvements are possible in most workspaces
Compared to tools currently in use a WONDER workspace description provides at least the same level of support: yes
Overall conclusion WONDER is a practical alternative for
supporting the design, while maintaining the flexibility needed in this phase
The descriptions will need to be revisited: some graphical information is needed
Better support tool would make working with WONDER much easier for a design team