A (very) short history of ambiguity

a (very) short history of ambiguity jeremy.yuille.info @overlobe this is a presentation I gave at UX Australia, in Melbourne, late August 2010. The aim of this short (10 minute) talk is to introduce the idea that there are multiple ways to look at ambiguity, and to demonstrate what some design implications of these different approaches might be. image note: this diagram of a cube is often used when referring to ambiguity. If you look at the image, you can see the cube ‘ﬂip’ backwards and forwards.. such that the top right corner is either on the front or the back of the cube.

http://scienceblogs.com/stoat/2008/09/ambiguous_dog_signs.php ambiguity is something we deal with every day, sometimes the ambiguity of a situation is represented in an artifact. Sometimes the artifact introduces ambiguity into the situation (like this sign). Often the ambiguous nature of a design situation is not represented explicitly, and we need to interact with it a little, to discover what is happening, and how we might approach that situation to achieve our goals. This is where an expanded repertoire of appraoches to ambiguity are useful.

http://chanian.com/2010/02/01/why-requirements-engineering-matters/ Designers often receive ambiguous design briefs. One way to deal with this is to attempt to remove any of the ambiguity in the description of the design project’s goals. I’m going to call this a “remove” approach, because its based on the idea that it’s possible to remove any possibility for doubt or misinterpretation by providing sufficient explication.

8.01 Chapter 1 - Management Summary This chapter provides a Summary of the entire System. It must include:- • A definition of the scope. • A definition of the objectives. • • TH Background to the development. A high-level context data flow diagram which depicts the System (as a single bubble) in relation to other automated Systems, Departmental areas or external • • • E organisations (eg Banks, Solicitors etc). SPE Hardware/system software to be utilised. An overview of the sub-systems (if appropriate). An overview of the major functions. • • Proposed stages of construction/implementation. CIF A summary of the benefits/advantages of the development. • • • Any critical areas likely to affect the success of the development. Any required legislative changes. Any required changes to work practices. ICA • • Any critical assumptions made during the Functional Specification Phase. Recommendations to Management. TIO 8.02 Chapter 2 - Functional Descriptions ND This chapter defines how the proposed System will function. If required, due to the size or complexity of the System, this chapter may be split into sub-systems, before individual functions are defined. It must include:- OCU ME • A narrative overview of the basic system concepts on which the specification depends determined during the preparation of the specification (eg online/real time, System interfaces, possible future extensions, management information, goals to reduce paperwork, or speed office output etc). • A context data flow diagram which depicts how the System interacts with other automated Systems, Departmental areas or external organisations. • • • • A narrative overview of the System/sub-system including its purpose, business rules and event timings. A data flow diagram of each function within the System/sub-system. A narrative description of each function. Where appropriate cross references to Chapter 4-Input/Output Descriptions should be included. For each function the number of inputs/outputs, processes, files and interfaces required to automate the function must be documented. A Function Point Count NT for the proposed System must then be produced. (If the Function Point Count differs significantly from that calculated for the Project Approval Report then the reasons for the variations must be explained.) 8.03 Chapter 3 - Data Structures This chapter describes the entities, entity relationships and attributes of the proposed System. It must include:- • A logical Data Model which depicts the entities and associations. • A brief narrative description of each entity and a supporting attribute list. The attributes are described in detail in Chapter 17 - Data Attribute Definitions. 8.04 Chapter 4 - Input/Output Descriptions This chapter defines all the inputs (eg screens, magnetic media etc) and outputs (eg reports, magnetic media, etc) of the System. It must include:- • http://www.egov.vic.gov.au/trends-and-issues/functional-specifications/ For each input the layout (eg screen design, tape format etc) and data attributes to be included. • • functional-specifications-samples/functional-specification-sample.html For each output the layout (eg report design, microfiche design etc) and data attributes to be included. The proposed menu structure for the System. All data attributes used in input/output layouts must be defined in Chapter 17 - Data Attribute Definitions. One way to attempt removing ambiguity, is to specify EVERYTHING. Products of this approach include specification of functional or technical requirements. Often these attempts at 8.05 Chapter 5 - Interfaces to Other Systems removing ambiguitytoare more difficultSystems. It must include:- This chapter describes the interfaces any existing or proposed automated to understand than the original situation! • A data flow diagram depicting the System and its interfaces to other automated Systems. • A narrative description of the timing and likely method of interfacing to each System. • Cross references to the appropriate description of the interface in Chapter 4. • A description of any alterations required to existing or proposed Systems to accommodate this interface. 8.06 Chapter 6 - Security This chapter describes the security requirements of the System. These requirements should take into account the facilities/constraints of the system software (eg DBMS) to be used. It must include:

ambiguity one way I like to think about ambiguity is by thinking about its compliment, or what we use to help us deal with ambiguity:

affinity

Affinity is used in different ways throughout the design process. We seek affinity when we engage with a situation, in order to do things like identify the ambiguous elements or aspects of that situation. We spot affinity between artifacts or ideas, and we make affinity when we begin to change a situation. I’m particularly interested in this last aspect of affinity, because it relates well to the practices of sketching and prototyping that we’ve explored a little in workshops yesterday.

“ Tell me and I'll forget; show me and I may remember; involve me and I'll understand. ” Chinese Proverb Here’s some old wisdom on the power of using participation in an activity to help people understand one another.

so - another approach to ambiguity might be to engage with it. Let’s say this object is something ambiguous. I call your attention to it, using something to represent it (in this case, I’ve used a sketch of a cube)

We can then discuss aspects of this object, participating in a process of disambiguation. This process of reiﬁcation (making something concrete, as opposed to abstract) and participation is one way that ambiguity can be resolved.

ambiguity is a requirement for the creation of Communities of practice: learning, meanings, and identity Etienne Wenger 1999 This resolution is often referred to as ‘meaning’ Wenger’s duality of reiﬁcation and participation is an interesting perspective to use when thinking about resolving ambiguity.

http://www.flickr.com/photos/gcbb/3234180323/ cultural probes, and other ways of engaging with people around design situations are interesting products of this approach.

When it comes to more mainstream examples of products that demonstrate this, I’m reminded of the ways I can engage with my social media feeds. Interfaces like ﬂipboard use the visual language of magazines to reify a stream of tweets into a single idea (in this case a double page spread, implying that all tweets on this page are somehow related)..

Art as Experience John Dewey 1934 Some artifacts engage differently than others. Some artifacts are very prescriptive, they describe the requirements for an experience (think of the specification document) Dewey called these kinds of artifacts ‘statements’, differentiating them from ‘expressions’, or artifacts that actually constitute an experience (in this case it might be a paper prototype of the product that the specification is describing) Both these types of artifacts help us to deal with ambiguity. I’ve already described how the specification works, but the paper prototype is quite different. It *is* an experience, that exploits ambiguity to help focus on different aspects of a design situation.

Energy Gallery, The Science Museum, London, 2004 Critical Design experiment exploring different energy futures. The gallery is aimed at children aged between 7 and 14. http://www.dunneandraby.co.uk/content/projects/68/0 Here’s another example. Dunne and Raby’s ‘critical design’ is all about exploiting the ambiguity of artifacts, to focus attention on an issue, topic or situation.

YouTube’s video comments are another example. We can see that there’s a generative aspect to this approach because it tends to expand the understandings of an ambiguous situation, rather than narrowing them down to one shared meaning or idea.

ambiguous lenses resolve it remove it exploit it So, there you have it: 3 takes, riffs, or moves on ambiguity. 3 lenses that you can use when attempting to deal with ambiguous design situations or issues. and remember, you can look at a situation through each of these lenses, but it’s important to remember that...

“ Everything seen through each kind of lens is actually there. ” Thinking in Systems: a primer Donnela H. Meadows 2008

thanks jeremy.yuille.info @overlobe

http://www.uxaustralia.com.au	46
http://isomorpho.us	20
http://www.tonychapelle.com	9
http://lanyrd.com	4
http://tonychapelle.posterous.com	1

A (very) short history of ambiguity

by Jeremy Yuille on Aug 29, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

5 Embeds 80

Statistics

A (very) short history of ambiguity — Presentation Transcript