Interdisciplinary Design Teams Translating Ethnographic Field Data Into Design Models: Communicating Ambiguous Concepts Using Quality Goals

Interdisciplinary Design Teams Translating Ethnographic Field Data Into Design Models: Communicating Ambiguous Concepts Using Quality Goals

Jeni Paay, Leon Sterling, Sonja Pedell, Frank Vetere, Steve Howard
DOI: 10.4018/978-1-7998-3016-0.ch009
OnDemand:
(Individual Chapters)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

Translating ethnographic field data to engineering requirements and design models suitable for implementing socio-technical systems is problematic. Ethnographic field data is often “messy” and unstructured, while requirements models are organized and systematic. Cooperation and communication within an interdisciplinary design team makes the process even more complicated. A shared understanding between ethnographers, interaction designers, and software engineers is vital to ensure that complex and subtle social interactions present in the data are considered in the final system design. One solution for supporting team conversations uses the quality goal construct as a container for complex and ambiguous interaction attributes. Quality goals in system modelling promote shared understandings and collaborative design solutions by retaining a high level of abstraction for as long as possible during the design process. This chapter illustrates the effectiveness of abstract goals for conveying complex and ambiguous information in the design of a socio-technical system supporting social interaction between couples.
Chapter Preview
Top

Introduction

In designing socio-technical systems, it is necessary to discover what discriminates social requirements from other types of requirements. Designers need to focus on the identification of user goals, and in particular those non-work-related, non-goal-oriented interpersonal interactions that happen between individuals. An interdisciplinary team is important for the translation from ethnographic field data to requirements modelling to achieve a solution that takes account of both function and non-functional aspects of social interactions. Embracing ambiguity in requirements modelling for socio-technical systems helps withhold design commitment on social requirements for as long as possible. Recognizing and working with how models of ambiguous concepts, such as joking and play, facilitates rich conversations between ethnographers, interaction designers and software engineers with respect to the social needs and interactions of users of proposed systems. The need for the design team to create a shared understanding becomes particularly relevant when designing digital technologies for activities outside of the work domain, for example, mediating personal and intimate relationships between couples (Paay et al., 2009).

Cultural probes produce ethnographic field data that is particularly suitable for learning about intimate and personal aspects of people’s lives (Gaver et al., 1999). Data generated from cultural probes can include user-generated photographs, postcards, drawings, and scrapbook entries, and can be supplemented with contextual interviews to enrich understanding. However, it is a substantial challenge to take the “messy” user data and translate it into the formal models required for system implementation. A design team needs to identify non-work-focussed and non-goal-oriented interpersonal interactions that happen between individuals, to discover social requirements of a system. These interactions, for example, flirting or joking, constitute much of what occurs between intimate couples, families, friends and social groups engaged in leisure. Ambiguity plays a vital role in maintaining openness and flexibility in the interpretation of cultural probe data throughout the design process. Ambiguity, as described by Gaver et al. (2003) becomes “a resource for design” when designing technologies to support activities outside of work. Ambiguity should be regarded as an opportunity, rather than a problem, because it allows for multiple possible meanings and individual interpretations of concepts. According to Gaver et al., ambiguity in design allows people to interpret situations for themselves, and establish deeper and more personal relations with meanings offered by systems.

Software engineering is proficient at modelling individual purposeful needs but it does not yet convincingly address requirements elicitation of non-goal-oriented social interactions. Additionally, ethnographers and interaction designers come to the design process with their own interpretations of the data and hence different implications for system design. It therefore remains an ongoing challenge to merge the differing viewpoints, skill sets and understandings of members of an interdisciplinary team, to create an effective and relevant technology solution for end users (Paay, 2008). Using ambiguity in requirements modelling can provide a solution to the problem, through the use of quality goals from the Agent Oriented Software Engineering (AOSE) method (Sterling & Taveter, 2009). Quality goals are essentially non-functional goals encapsulating social aspects of the context into software requirements models. They represent quality attributes that both enrich and constrain the goals and roles of a multi-agent system. This is particularly relevant when data about people’s experiences are gathered using ethnographically inspired methods. The construct of quality goals, attached to functional goals in the requirements models, represent quality attributes of social interactions as abstract, ambiguous and unresolved concepts. The ability to articulate quality goals and carry them through to the design phase in an undischarged form, adds the necessary level of ambiguity for interpretation and translation of social requirements. Quality goals can carry subtle nuances of social interactions from field data through to final system design. They are able to stimulate conversations on design alternatives during collaborative conceptual design, because they remain flexible and open to interpretation. They do not need to be resolved early in the process. This is important when the team is interdisciplinary, allowing for translation of different concepts and ontologies, toward a shared understanding.

Complete Chapter List

Search this Book:
Reset