Supporting the design of interactive systems a perspective on supporting people’s work Hans de Graaff 27 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