a brief history of ambiguity

8/8/2019 A Brief History of Ambiguity

http://slidepdf.com/reader/full/a-brief-history-of-ambiguity 1/19

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 tolook at ambiguity, and to demonstrate what some design implications of these dif erentapproaches might be.

image note: this diagram of a cube is often used when referring to ambiguity. If you look atthe image, you can see the cube ‘flip’ backwards and forwards.. such that the top right corneris 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 isrepresented in an artifact. Sometimes the artifact introduces ambiguity into the situation (likethis sign). Often the ambiguous nature of a design situation is not represented explicitly, andwe need to interact with it a little, to discover what is happening, and how we might approachthat situation to achieve our goals. This is where an expanded repertoire of appraoches toambiguity 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 toremove any of the ambiguity in the description of the design project’s goals. I’m going to callthis a “remove” approach, because its based on the idea that it’s possible to remove anypossibility for doubt or misinterpretation by providing sucient explication.





8.01 Chapter 1 - Management Summary

This chapter provides a Summary of the entire System. It must include:-

• A definit ion of the scope.

• A definition of the objectives.

• 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

organisations (eg Banks, Solicitors etc).

• 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.

• A summary of the benefits/advantages of the development.

• Any critical areas likely to affect the success of the development.

• Any r equired legislative changes.

• Any r equired changes to work practices.

• Any critical assumptions made during the Functional Specification Phase.

• Recommendations to Management.

8.02 Chapter 2 - Functional Descriptions

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:-

• 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

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:-

• For each input the layout (eg screen design, tape format etc) and data attributes to be included.

• For each output the layout (eg report design, microfiche design etc) and data attributes to be included.

• The proposed menu structure for the System.

http://www.egov.vic.gov.au/trends-and-issues/functional-specifications/functional-specifications-samples/functional-specification-sample.html

T H E S P E C I F I C A T I

O N D O C U M E N T

One way to attempt removing ambiguity, is to specify EVERYTHING. Products of this approachinclude specification of functional or technical requirements. Often these attempts atremoving ambiguity are more dicult to understand than the original situation!











ambiguity

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



affinity



Anity is used in dif erent ways throughout the design process.We seek anity when we engage with a situation, in order to do things like identify theambiguous elements or aspects of that situation.We spot anity between artifacts or ideas, and we make anity when we begin to change asituation.

I’m particularly interested in this last aspect of anity, because it relates well to the practicesof 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 peopleunderstand 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 torepresent 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 reification (making something concrete, as opposed to abstract) andparticipation 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 reification and participation is an interesting perspective to use whenthinking about resolving ambiguity.



http://www.flickr.com/photos/gcbb/3234180323/

cultural probes, and other ways of engaging with people around design situations areinteresting products of this approach.





When it comes to more mainstream examples of products that demonstrate this, I’mreminded of the ways I can engage with my social media feeds.

Interfaces like flipboard use the visual language of magazines to reify a stream of tweets intoa single idea (in this case a double page spread, implying that all tweets on this page are

somehow related)..



Art as Experience

John Dewey 1934Some artifacts engage dif erently than others. Some artifacts are very prescriptive, theydescribe the requirements for an experience (think of the specification document) Deweycalled these kinds of artifacts ‘statements’, dif erentiating them from ‘expressions’, orartifacts 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 thespecification works, but the paper prototype is quite dif erent. It *is* an experience, thatexploits ambiguity to help focus on dif erent aspects of a design situation.



Energy Gallery, The Science Museum, London, 2004Critical 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 theambiguity 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 aspectto this approach because it tends to expand the understandings of an ambiguous situation,rather than narrowing them down to one shared meaning or idea.



resolve it

exploit it

remove it

ambiguous lenses

So, there you have it:3 takes, rif s, or moves on ambiguity. 3 lenses that you can use when attempting to deal withambiguous 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 througheach kind of lens is

actually there.

Thinking in Systems: a primer

Donnela H. Meadows 2008

“

”



thanks

jeremy.yuille.info

@overlobe

a brief history of ambiguity

Documents