1. 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 ‘flip’ backwards and forwards.. such that the top right corner
is either on the front or the back of the cube.

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

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

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

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

6. affinity

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

8. “ 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.

9. 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)

10. 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) and
participation is one way that ambiguity can be resolved.

11. 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 when
thinking about resolving ambiguity.

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

13. 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 flipboard 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)..

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

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

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

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

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

19. thanks
jeremy.yuille.info
@overlobe