53
CONFIDENTIALITY The concepts and methodologies contained herein are proprietary to Regular Joe Consulting LLC. Duplication, reproduction or disclosure of information is this document without the express written permission of Regular Joe Consulting is prohibited. Enjoy the work. We hope you find it useful. Nailing it down Specifying experience design so it can be built UX Australia Joe Sokohl @mojoguzzi Friday, August 27, 2010

Nailing it down: Specifying experience design so it can be built

  • View
    2.853

  • Download
    0

Embed Size (px)

DESCRIPTION

So you’ve done ethnographic user research. You’ve also analyzed log files. You’ve interviewed help desk and customer service folks, You’ve had heaps of meetings with stakeholders. And you’ve nailed a sense of the user, so you’ve got some great personas. You even held some design sketching sessions.NOW what? While Dan Brown, Ginny Redish, and others have codified the early phases of experience documentation, there’s a disjunction that often happens when business analysts write requirements documents or developers and product managers write user stories. Despite the best personas and user/task grids and wireframes, other documents override the best UX intentions. We need to get back in the game and stay there in some role as products are developed. Design doesn’t end with design; development is the fruition of design.Let’s discuss moving from design to development, with a concentration on specifying experience design artifacts for those who have to glean meaning from our work: developers, business stakeholders, and other teams. How does experience design specify its output in a way that developers can code and business can understand how the UX relates to business requirements? And are specifications the definition of design?After quickly reviewing typical deliverables such as use cases, annotated wireframes, requirements specifications, and user stories, we’ll discuss where we should create, where we should influence, and where we should keep the hell away.

Citation preview

Page 1: Nailing it down: Specifying experience design so it can be built

CONFIDENTIALITY

The concepts and methodologies contained herein are proprietary to Regular Joe Consulting LLC. Duplication, reproduction or disclosure of information is this document without the express written

permission of Regular Joe Consulting is prohibited. Enjoy the work. We hope you find it useful.

Nailing it downSpecifying experience design so it can be built

UX AustraliaJoe Sokohl@mojoguzzi

Friday, August 27, 2010

Page 2: Nailing it down: Specifying experience design so it can be built

A bit about me

2

Friday, August 27, 2010

Page 3: Nailing it down: Specifying experience design so it can be built

A bit about me

2

http://www.uxaustralia.com.au/conference-2010/design-thinking-is-this-our-ticket-to-the-big-table

Friday, August 27, 2010

Page 4: Nailing it down: Specifying experience design so it can be built

My Aussie props

3

Friday, August 27, 2010

Page 5: Nailing it down: Specifying experience design so it can be built

My Aussie props

3

Friday, August 27, 2010

Page 6: Nailing it down: Specifying experience design so it can be built

My Aussie props

3

Friday, August 27, 2010

Page 7: Nailing it down: Specifying experience design so it can be built

Defining the damn things

What’s the problem

What are some solutions

What’s your story

Agenda

4

Friday, August 27, 2010

Page 8: Nailing it down: Specifying experience design so it can be built

Defining the damn things

What’s the problem

What are some solutions

What’s your story

Agenda

4

Friday, August 27, 2010

Page 9: Nailing it down: Specifying experience design so it can be built

Determining what the problem is

So what’s the big deal, anyway?

5

Friday, August 27, 2010

Page 10: Nailing it down: Specifying experience design so it can be built

Who this talk applies to

Agencies

Independent UXers

Highly regulated areas: healthcare, government, military

Anyone working with distributed teams (including cross-border, multiple time zone teams)

6

Friday, August 27, 2010

Page 11: Nailing it down: Specifying experience design so it can be built

Who this talk might not apply to

Heterogenous teams

UXers who also do front-end development

Co-located, nimble teams who don’t have a need to retrace steps

7

Friday, August 27, 2010

Page 12: Nailing it down: Specifying experience design so it can be built

Who this talk might not apply to

Heterogenous teams

UXers who also do front-end development

Co-located, nimble teams who don’t have a need to retrace steps

7

Then again....

Friday, August 27, 2010

Page 13: Nailing it down: Specifying experience design so it can be built

Typical documentation approaches

Research artifacts such as competitive reviews, heuristic analysis, mental models/affinity diagrams, and personas

User/task matrixes

Annotated wireframes

Concept models

Card sorts

And on and on and on...

8

Friday, August 27, 2010

Page 14: Nailing it down: Specifying experience design so it can be built

Typical documentation approaches

Research artifacts such as competitive reviews, heuristic analysis, mental models/affinity diagrams, and personas

User/task matrixes

Annotated wireframes

Concept models

Card sorts

And on and on and on...

8

Friday, August 27, 2010

Page 15: Nailing it down: Specifying experience design so it can be built

08/27/10

FiveDs Summary

Discover Design Define Develop Deliver

Define project goals,

business reqs,

and initial scope.

Activities

•Define goals

•Key success factors

•VOC workshops

•EOC interviews

•B/U/S requirements

•Site analysis

•Audience analysis

•Initial use cases

•Business processes

Further define a

set of requirements

and create systems

and UX models

Activities

•Brainstorming

•Scenario building

•Wireframes

•Visual direction

•HL Info Architecture

•HL Sys Architecture

•Define technology

Refine design details,

create final design and

obtain signoff.

Activities

•Merge visual and

functional design

•Final content

•Test scenarios

•Object analysis,

modeling, design

•Database analysis and design

•Design

documentation

Build and integrate

front-end and

back-end systems.

Activities

•Image and page

creation

•Content integration

•Coding

•Unit testing

•System staging in QA environment

•Incremental QA and testing on multiple

platforms

Complete the

commercialization of

the product

Activities

•Acceptance testing

•System and knowledge transfer

•Product deployment

•Marketing campaign

Friday, August 27, 2010

Page 16: Nailing it down: Specifying experience design so it can be built

08/27/10

FiveDs Summary

Discover Design Define Develop Deliver

Define project goals,

business reqs,

and initial scope.

Activities

•Define goals

•Key success factors

•VOC workshops

•EOC interviews

•B/U/S requirements

•Site analysis

•Audience analysis

•Initial use cases

•Business processes

Further define a

set of requirements

and create systems

and UX models

Activities

•Brainstorming

•Scenario building

•Wireframes

•Visual direction

•HL Info Architecture

•HL Sys Architecture

•Define technology

Refine design details,

create final design and

obtain signoff.

Activities

•Merge visual and

functional design

•Final content

•Test scenarios

•Object analysis,

modeling, design

•Database analysis and design

•Design

documentation

Build and integrate

front-end and

back-end systems.

Activities

•Image and page

creation

•Content integration

•Coding

•Unit testing

•System staging in QA environment

•Incremental QA and testing on multiple

platforms

Complete the

commercialization of

the product

Activities

•Acceptance testing

•System and knowledge transfer

•Product deployment

•Marketing campaign

Friday, August 27, 2010

Page 17: Nailing it down: Specifying experience design so it can be built

What’s the difference between reqs & specs?

Requirements

Requirements cannot be “gathered”

Requirements are not features

Requirements are not specifications

Specifications

“Effective documentation combines text and images to describe the anatomy and physiology of a product.”

11

Friday, August 27, 2010

Page 18: Nailing it down: Specifying experience design so it can be built

What’s the difference between reqs & specs?

Requirements

Requirements cannot be “gathered”

Requirements are not features

Requirements are not specifications

Specifications

“Effective documentation combines text and images to describe the anatomy and physiology of a product.”

11

My definition? A specification is

Friday, August 27, 2010

Page 19: Nailing it down: Specifying experience design so it can be built

What’s the difference between reqs & specs?

Requirements

Requirements cannot be “gathered”

Requirements are not features

Requirements are not specifications

Specifications

“Effective documentation combines text and images to describe the anatomy and physiology of a product.”

11

My definition? A specification is

The body of information that conveys sufficient detail to communicate that which can be coded.

Friday, August 27, 2010

Page 20: Nailing it down: Specifying experience design so it can be built

What’s the difference between reqs & specs?

Requirements

Requirements cannot be “gathered”

Requirements are not features

Requirements are not specifications

Specifications

“Effective documentation combines text and images to describe the anatomy and physiology of a product.”

11

My definition? A specification is

The body of information that conveys sufficient detail to communicate that which can be coded.

Just enough detail to enable the developer to understand the UX designer’s intent.

Friday, August 27, 2010

Page 21: Nailing it down: Specifying experience design so it can be built

Where do they break? Why

12

Friday, August 27, 2010

Page 22: Nailing it down: Specifying experience design so it can be built

Where do they break? Why

12

Team proximity or regulatory need (or both)

Spe

c ne

ed

Friday, August 27, 2010

Page 23: Nailing it down: Specifying experience design so it can be built

Where do they break? Why

12

Team proximity or regulatory need (or both)

Spe

c ne

ed

Friday, August 27, 2010

Page 24: Nailing it down: Specifying experience design so it can be built

Requirements masquerading as specifications

1.1.1. The system shall allow the teacher to click a control which displays the first answer in the lesson.

NOTE: Subsequent answers can be accessed by individual controls after the first answer is displayed. The “Show Answers” and “Show First Answer” controls shall be displayed outside of lessons in a toolbar in the Learning Environment. Answers should be displayed to both the teacher and student.

13

As a clinician and/or front desk assistant, I need to record the writer, provider(s), assistant(s), as well as the date and time of entry for every clinical note, so that I can maintain accurate clinical records.

Traditional approach

User story approach

Friday, August 27, 2010

Page 25: Nailing it down: Specifying experience design so it can be built

A bridge to nowhere?

14

Friday, August 27, 2010

Page 26: Nailing it down: Specifying experience design so it can be built

15http://static.guim.co.uk/sys-images/Guardian/Pix/pictures/2009/3/30/1238371335802/TS-Eliot-003.jpg

That is not it at all, That is not what I meant, at all. . . . . .

Friday, August 27, 2010

Page 27: Nailing it down: Specifying experience design so it can be built

Big, grandiose statement

16

Anything that specifies user

behavior or activities that

affect users belongs to the

user experience team

Friday, August 27, 2010

Page 28: Nailing it down: Specifying experience design so it can be built

More detail at the right time

Solutions

17

Friday, August 27, 2010

Page 29: Nailing it down: Specifying experience design so it can be built

18

Requirement: Turn indicators

1.3.2.5a: The system shall include the ability for the operator to indicate a changed direction of travel

Friday, August 27, 2010

Page 30: Nailing it down: Specifying experience design so it can be built

18

Requirement: Turn indicators

Friday, August 27, 2010

Page 31: Nailing it down: Specifying experience design so it can be built

Sketches provide documentation

19

Friday, August 27, 2010

Page 32: Nailing it down: Specifying experience design so it can be built

Sketches provide documentation

19

The genius in our styling department is that they not only have a great feel for

design, but also for the fact that the design needs to function properly on a

motorcycle. That melding of functionality and styling is what makes our

motorcycles very, very special

Friday, August 27, 2010

Page 33: Nailing it down: Specifying experience design so it can be built

Detailed sketches

20

Friday, August 27, 2010

Page 34: Nailing it down: Specifying experience design so it can be built

Embeded specifications

21

Friday, August 27, 2010

Page 35: Nailing it down: Specifying experience design so it can be built

The finished product

22

Friday, August 27, 2010

Page 36: Nailing it down: Specifying experience design so it can be built

Prototypes help, too

23

Friday, August 27, 2010

Page 37: Nailing it down: Specifying experience design so it can be built

What Are Some Solutions

Frameworks

Style guides and pattern libraries

Accurate diagrams and traceable notes

A proverbial seat at the table.

24

Friday, August 27, 2010

Page 38: Nailing it down: Specifying experience design so it can be built

What Are Some Solutions

Frameworks

Style guides and pattern libraries

Accurate diagrams and traceable notes

A proverbial seat at the table.

24

Friday, August 27, 2010

Page 39: Nailing it down: Specifying experience design so it can be built

Embedding Specs with Wireframes or Prototypes

25

Friday, August 27, 2010

Page 40: Nailing it down: Specifying experience design so it can be built

Embedding Specs with Wireframes or Prototypes

26

Friday, August 27, 2010

Page 41: Nailing it down: Specifying experience design so it can be built

27

But...but...what about Agile?Friday, August 27, 2010

Page 42: Nailing it down: Specifying experience design so it can be built

Sometimes specs fall into the wrong hands

28

Friday, August 27, 2010

Page 43: Nailing it down: Specifying experience design so it can be built

Special order 191

29

Friday, August 27, 2010

Page 44: Nailing it down: Specifying experience design so it can be built

Special order 191

29

Major Taylor will proceed to Leesburg, Va., and arrange for transportation of the sick and those unable to walk to Winchester, securing the transportation of the country for this purpose. The route between this and Culpeper Court-House east of the mountains being unsafe will no longer be traveled. Those on the way to this army already across the river will move up promptly; all others will proceed to Winchester collectively and under command of officers, at which point, being the general depot of this army, its movements will be known and instructions given by commanding officer regulating further movements.

III. The army will resume its march tomorrow, taking the Hagerstown road. General Jackson's command will form the advance, and, after passing Middletown, with such portion as he may select, take the route toward Sharpsburg, cross the Potomac at the most convenient point, and by Friday morning take possession of the Baltimore and Ohio Railroad, capture such of them as may be at Martinsburg, and intercept such as may attempt to escape from Harper's Ferry.

IV. General Longstreet's command will pursue the main road as far as Boonsborough, where it will halt, with reserve, supply, and baggage trains of the army.

V.General McLaws, with his own division and that of General R. H. Anderson, will follow General Longstreet. On reaching Middletown will take the route to Harper's Ferry, and by Friday morning possess himself of the Maryland Heights and endeavor to capture the enemy at Harper's Ferry and vicinity.

Friday, August 27, 2010

Page 45: Nailing it down: Specifying experience design so it can be built

30http://www.civilwar.org/battlefields/antietam/maps/antietammap3.html

Friday, August 27, 2010

Page 46: Nailing it down: Specifying experience design so it can be built

31

In preparing for battle, I have always found that plans are useless...

Friday, August 27, 2010

Page 47: Nailing it down: Specifying experience design so it can be built

31

In preparing for battle, I have always found that plans are useless...

...but planning is indispensable.—Dwight Eisenhower

Friday, August 27, 2010

Page 48: Nailing it down: Specifying experience design so it can be built

So...

32

Friday, August 27, 2010

Page 49: Nailing it down: Specifying experience design so it can be built

So...

32

A specification is

Friday, August 27, 2010

Page 50: Nailing it down: Specifying experience design so it can be built

So...

32

A specification is

The body of information that conveys sufficient detail to communicate that which can be coded.

Friday, August 27, 2010

Page 51: Nailing it down: Specifying experience design so it can be built

So...

32

A specification is

The body of information that conveys sufficient detail to communicate that which can be coded.

Just enough detail to enable the developer to understand the UX designer’s intent.

Friday, August 27, 2010

Page 52: Nailing it down: Specifying experience design so it can be built

What’s your story?

33

Friday, August 27, 2010

Page 53: Nailing it down: Specifying experience design so it can be built

Joe [email protected]@mojoguzzi

Many thanks!

Friday, August 27, 2010