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