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.

http://scienceblogs.com/stoat/2008/09/ambiguous_dog_signs.phpambiguity 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 SummaryThis chapter provides a Summary of the entire System. It must include:-

• A definition 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 required legislative changes.• Any required changes to work practices.• Any critical assumptions made during the Functional Specification Phase.• Recommendations to Management.

8.02 Chapter 2 - Functional DescriptionsThis 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 StructuresThis 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 DescriptionsThis 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.

All data attributes used in input/output layouts must be defined in Chapter 17 - Data Attribute Definitions.

8.05 Chapter 5 - Interfaces to Other SystemsThis chapter describes the interfaces to any existing or proposed automated Systems. It must include:-

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

• A description of the proposed system level security in terms of access.• A description of any required sub-system/function level security in terms of access.• A description of any security relating to particular entities and/or data attributes.

8.07 Chapter 7 - Business ContinuityThis chapter describes the User requirements for maintaining business continuity, systems back-up, restart and recovery. It must include:-

• A description of how the business/service is to be maintained in the event of an unplanned interruption.• A description of backup requirements in terms of frequency, off site storage, and archiving duration.• A description of the restart requirements for batch functions.• A description of the recovery requirements for online functions.• Requirements for backup machines.• Requirements for disaster recovery.• Requirements for manual fall back procedures including at what stage these procedures would be invoked.• A description of all System Housekeeping requirements, (eg run utility monthly to remove obsolete records from indexes).

8.08 Chapter 8 - AuditabilityThis chapter describes the requirements for audit trails and controls. It must include:-

• Constraints on specific data attributes (e.g., Account Number is allocated sequentially and must be cancelled not deleted, requires a check digit).• Constraints on using specific functions (e.g., available only to supervisor).• Control features (e.g., batching, totals etc).• Any requirements for maintaining a separate audit trail for additions, deletions or modifications to data attributes.

8.09 Chapter 9 - User Performance RequirementsThis chapter describes the User Performance requirements for the proposed System. It should include:-

• A description of the Users Online System Performance Criteria described in terms of simple, medium and complex transactions.• A description of the Users Batch System Performance Criteria described in terms of the required timings of updates and outputs (e.g., overnight, two working

days etc).

8.10 Chapter 10 - Summary of Capacity Requirements DocumentThis chapter provides a summary of the Capacity Requirements Document updated during this Phase.

8.11 Chapter 11 - Data Capture/Conversion RequirementsThis chapter describes the proposed strategy for any data capture or data conversion which must take place prior to or as part of the implementation process.

For example it must cover topics such as whether the System will start with an empty or partially loaded database, how this will be achieved, how tables/code lists will be loaded, which are mandatory fields and what validation must occur, how data takeon will be achieved etc.

8.12 Chapter 12 - Testing StrategyThis chapter describes the testing strategy to be used on the System. It must include:-

• An overview of the testing strategy to be used to test the System for both functionality and performance (e.g., whether a levels/passes approach to testing will be used, what functionality will be tested in each level/pass, what performance tests will be conducted and how, whether testing will be conducted prior to construction completing etc).

• Definition of roles and responsibilities for conducting the various levels of testing (e.g., ISB/User/Audit etc).• The requirements for any specific software testing tools (e.g., CICS VERIFY/COMPAREX).• A description of the System Acceptance Criteria and the threshold for Acceptance.

8.13 Chapter 13 - Implementation and Training StrategiesThis chapter provides an overview of implementation and training strategies to be adopted. It must include:-

• A description of proposed staging of implementation in terms of functionality to be introduced and User locations.• A description of the proposed training programme to be put in place for the various levels of User staff (e.g., whether on-the-job, training course(s), likely

duration(s) etc).• Definition of the roles and responsibilities for implementing these strategies (e.g., ISB/User etc).

8.14 Chapter 14 - Clerical ActivitiesThis chapter describes any clerical activities associated with the System. It must include:-

• A brief description of existing clerical activities within the scope of the System which remain unchanged and a justification for this decision.• A brief description of new/altered clerical activities and a synopsis of the impact of these changes on work practices. Highlight any critical clerical activities

which may affect the success of the System (e.g., write system generated reference number on original documents so they can be located).

8.15 Chapter 15 - StandardsThis chapter defines any System specific standards to be used. For example naming conventions to be used for files and screens; or use of function keys; or standards to be used for screens/report headings etc.

8.16 Chapter 16 - AssumptionsThis chapter is used to document any assumptions made during the preparation of this document which may prove critical to the success of the System. For example legislative changes, work practice changes, technical capabilities of hardware and/or system software etc.

8.17 Chapter 17 - Data Attribute DefinitionsThis chapter describes all data attributes identified for the proposed System. It must include:-

• For each data attribute a brief narrative description, its size, its type (e.g., numeric, alphanumeric etc). Editing and validation rules should be included where these have been defined (e.g., range checks; right justified left space filled etc).

• A cross reference of data attributes to entities, and inputs/outputs.

8.18 AppendicesWhen required Appendices should be provided for items such as Glossary of Terms, sizing information, diagrammatic conventions, supporting documentation etc.

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

THE SPECIFICATION DOCUMENT

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 removing ambiguity are more difficult to understand than the original situation!

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 reification (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 reification 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 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)..

Art as ExperienceJohn 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, 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 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.

resolve it

exploit it

remove it

ambiguous lenses

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 primerDonnela H. Meadows 2008

“”

thanks

jeremy.yuille.info@overlobe