Embracing Collaborative Design

Memi Beltrame: Embracing Collaborative Design - UXCon Lugano

Memi Beltrame

Embracing Collaborative Design

On the Acceptance of UX in the Development Process

UXCon, December 3rd 2009Lugano, Switzerland


• Developing websites since 1997• 2003-2007 Study of cinematography• Since 2007 specialising in frontend and interaction design

• Since 2008 for Liip Agile Web Development

About


Show the dynamics of collaborative design

Show ways to raise acceptance of UX in development

Misson


1993 200920001998

Browser War

1995

dotcom

Pl op !

The Internet

03 04 05 06

High interaction apps,Increased need for UX


Until 2003 UX Design was only rarely a part of the commission and

development process for websites.


Rich internet applications brought a higher sensitivity to the users needs.


UX concepts as a response to shape customer and user experience


Developers meet UX experts with scepticism and little acceptance


Why?


To find out we need to do two things:

● Know the process● Understand the expectations


The process:

Collaborative Design


From Collaboration To Collaborative Design


Collaboration is the successful sharing of a working environment in a joint effort to accomplish a task


Collaborative design is collaboration with the task of creating an artefact


Collaborative Design takes place whenever an artefact is planned

and/or implemented by two or more participants.


Typical Collaborative Design Areas

ArchitectureSoftwareMovies


The Internet is (probably) the biggest single instance of

Collaborative Design


Collaborative Design is a reality.

It is the inevitable process that emerges when you build something

as a team.


Unlike UCD or TDD it is nothing you choose, it just happens,

nolens volens.

UCD: User centered designTDD: Test driven development


Even the simplest Customer < > Contractor Relationship

involves Collaborative Design


It involves is a network of participants


The goal is a common product with a high overall utility


Every participant can propose solutions for design issues


Participants are inter-dependent.


Participants are inter-dependent.Inter-dependency means

„I need something“


Every participant has a self-interest

Customer:Affordable yet magic

Designer:beautiful and usable

Developer:solid, stable and performing


Fulfilling self-interest meansReaching a local optimum of utility


Are participants willing to compromise their self interest for

the sake of a global optimum?


A B C D global Utility


A B C D global Utility


The system can become very complex

Webserver

DB Admin

Developer

Proxy

Mobile Services

Interface Designer

UX expert

DB Specialist

Project Lead

Management


It's hard to keep track of the interactions and design decisions

Webserver

DB Admin

Developer

Proxy

Mobile Services

Interface Designer

UX expert

DB Specialist

Project Lead

Management


Subsytems can emerge

Webserver

DB Admin

Developer

Proxy

Mobile Services

Interface Designer

UX expert

DB Specialist

Project Lead

Management


Subsytems also have a local optimum utility plus they are loyal!

Webserver

DB Admin

Developer

Proxy

Mobile Services

Interface Designer

UX expert

DB Specialist

Project Lead

Management


Every new participant brings a shift in the global utility.


Every old participant must be aware of this and accept it. Otherwise the team is possibly ripped apart.


Successful Collaborative Design is based on the commitment of each participant to achieve an optimum

of overall utility.


Acceptance


UX brought a paradigm shiftto a whole industry

UX


UX brought a paradigm shiftto a whole industry

UX


Why does this change happen with considerable problems?


Before UX:Developers modelled processes according to their instead of the user's needs.


Before UX:An application's utility was not anyone's explicit responsibility


Before UX:Utility did not figure as a criteria for quality assertion in the conceptual phase


Measurability


Criteria for quality assertion:

● Performance (computing speed, interface response)

● Drain on resources (bandwidth, disk-space, file-size)

● Implementation standards (normalisation, unit/functional testing, validation)

● Deficiency (incomplete or faulty implementation)

● Duration, cost (on time, on budget)

● Utility (relevance of information, ease of task completion)


Criteria for quality assertion:

● Performance (computing speed, interface response)

● Drain on resources (bandwidth, disk-space, file-size)

● Implementation standards (normalisation, unit/functional testing, validation)

● Deficiency (incomplete or faulty implementation)

● Duration, cost (on time, on budget)

● Utility (relevance of information, ease of task completion)

Easy to measure

Hard to measure


Hard to measure:Utility needs a process involving users to be asserted.

It's findings are hard to read and difficult to interpret.


The user is the only valid measuring instrument to assert utility.

Simultaneously being tester and testee deprives the developer from objectivity.


Objectivity is only possible if the results do not depend on the tester.

Only measurements based on objectivity lead to reliability and validity.


Expectation Management


It is important to continuously manage stakeholder expectations.

Identify what each stakeholder can and cannot do.


Two essential demands:

1. Device proficiency

2. Completenes of information


Device proficiency

Be familiar with the conventions of use on the device as well as its limitations.


Completenes of information:

Information architecture proposed mustbe complete and consistent.

Incompleteness paves the way for arbitrariness

Provide methodological guidance


Raising Acceptance


Successful Acceptance:

Reciprocal understanding of each others standards and expectations


This helps acceptance:

● Clear, unambiguous negotiation● Alliances● Shared experiences● Common achievements● High iteration workflows● Frequent synchronisation


Questions?


Thank you!

Slides: http://slides.liip.ch