Middle Out Design

Middle-Out Design

Audrey Crane

Dubberly Design Office(DDO)

new design method

middle-out design

issues =

HandScript

HandScriptTopSecret

product

medical order-entry system

physicians

hospital

writing

problems

hand-held device with WiFi

“discontinue TUMS”

“ IVF to 100cc/hr”

“Reglan 10mg po 30 min qac TID”

client team

Kevin, engineering manager

Kevin, engineering manager Eliot, voice interaction designer

Kevin, engineering manager Eliot, voice interaction designerClaire, “front end” engineer


Howard, local doctor


Howard, local doctor Dr. Famous, content expert

us

him

DavidCTO



David, CTO

5 + 3 Kevin, engineering manager Eliot, voice interaction designerClaire, “front end” engineer


David, CTO



Audrey, design & project manager




Greg, interaction designer




Greg, interaction designer

Hugh, principal

project background

company = engineers

(so that has some implications)

privately funded

$

$$

$

$$

alpha(1 year old, some content)

1 year to go

(1 year late)

Gino, designer-e x

“just a little help”

(background background)

Gino, designer-e x

Claire, “front end” engineerGino, designer-e x

frustrated

content entry tool ~ product UI

Dr. Famouscontent expert

information architect

Dr. Famous, content expert

information architect

Dr. Famous, content expertinformation architect( )de s ig ne r

Dr. Famous doesn’t need any stinkin’ designers

Dr. Famous, content expertinformation architect

(serious chronic illness)

getting started

first meeting

Santa Cruz

mostly Working At Home“WAH”

(so that has some implications)

no receptionist

barefoot engineer

lights off

?

“What is an order?”

“NPO until procedure, then…

“…ice chips for 1 hour, then…”

“…full liquid diet until patient requests food, then…”

“…regular diet.”

“…regular diet. Low sodium.”

1? 2? 5?

?

?

?

?

?

?

?

?

?

?

?

??

?

?

?

?

?

?

??

??

??

?

?

?

??

?

?

?

?

?

? ?

??

?

?

?

?

?

?

???

?

?

?

?

??

?

?

?

?

?

?

?

domain =

competition =

work =

product =

finite

DDO engagement =

DDO process

1. Research 2. Model 3. Prototype 4. Test 5. Specify

1. Research 2. Model 3. Prototype 4. Test 5. Specify- studies

1. Research 2. Model 3. Prototype 4. Test 5. Specify- studies- reviews


- analysis


- analysis- synthesis



- maps



- maps- wireframes



- maps- wireframes- comps




- studies




- studies - detail




- studies - detail- document





1. Analyze 2. Define 3. Ideate 4. Select 5. Implement

1. Define 2. Measure 3. Analyze 4. Design 5. Verify

1. Plan 2. Learn 3. Specify 4. Produce 5. Evaluate

(whole other talk)

1. research or analysis

Work already!

9 engineers sitting

…or worse!

What to do?





3 participant user testing?

1 week for modeling?

?





OR


“Um…sure.”

Admit/Xfr/DschgDiet

Regular diet as tol.Soft dietFull liquid dietClear liquid dietNPOMore Consistencies

Mechanical Soft DietPureed DietSips of WaterIce chps

Common / Diabetic DietsMore Modified Diets

Low / High / Amount Per DayFood AllergyRestrictedFluid RestrictionDisease / ConditionSpecial

Advance as tol.Advance as tol. to…

Regular diet as tol.Soft dietMechanical soft diet

“What if the handheld is lost?”

“Er…Log out after 30 seconds.”

lacks coherence, consistency

?

?

?

?

?

?

?

?

?

?

?

?

??

?

?

?

?

?

?

??

??

??

?

?

?

??

?

?

?

?

?

? ?

??

?

?

?

?

?

?

???

?

?

?

?

??

?

?

?

?

?

?

?

✔

✔

✔

✔

✔

✔✔

✔

✔

✔

✔

✔

✔




what we did

wrote down questionsquestions

?

?

?

?

?

?

?

?

?

??

??

??

?

?

?

?

??

?

? ?

? ?

? ?

??

wrote down questions

?????

?

?

?

?

?

prioritized

?

SQA tangent

Software Quality Assurance

Bug:

Bug:

1. Summary

Bug:

1. Summary2. Description

Bug:

1. Summary2. Description3. Owner

Bug:

1. Summary2. Description3. Owner4. Status (open, working, closed)

Bug:

1. Summary2. Description3. Owner4. Status (open, working, )

Bug:

1. Summary2. Description3. Owner4. Status (open, working, ) 5. (Severity)

Bug:

1. Summary2. Description3. Owner4. Status (open, working, ) 5. (Severity)6. Priority

P1P2P3P4P5

P1P2P3P4P5

✔✔✔

(or whatever)

P3?? P4!!

P1 (pe wun) adj.

P1 - crash, data loss

(or whatever)

= issues

Design Issue Priority Definitions

Design Issue Priority DefinitionsP1: Global or core issue that prevents a

significant number of other issues from being resolved.

Design Issue Priority DefinitionsP1:

P2:

Global or core issue that prevents a significant number of other issues from being resolved.Prevents some issues from being resolved, but not a large number.


P2:

P3:

Global or core issue that prevents a significant number of other issues from being resolved.Prevents some issues from being resolved, but not a large number.Isolated issue, must be resolved but does not prevent other work.


P2:

P3:

P4:

Global or core issue that prevents a significant number of other issues from being resolved.Prevents some issues from being resolved, but not a large number.Isolated issue, must be resolved but does not prevent other work.Detail, does not prevent other work.


P2:

P3:

P4:

P5:

Global or core issue that prevents a significant number of other issues from being resolved.Prevents some issues from being resolved, but not a large number.Isolated issue, must be resolved but does not prevent other work.Detail, does not prevent other work.Detail, resolution not required for beta.

An issue is resolved when…

?

When are agreedthat we have a good fix.

good?

?

my good = your good?

Ha.

good (güd)adj. bet·ter, best

1. Being positive or desirable in nature; not bad or poor

(whole other talk)

team “good”= team “good”

Good:

Good:

1. Efficient, meaning…a. intuitiveb. fast (application)c. quick access to information

Good:


2. Meets expectations; consistent, no surprises.

Good:



3. Keeps users from getting lost.

Good:




4. Minimal barriers and constraints.

consistency class

ANYWAY

Go!

tools

Issue List Issue Priority Definitions: P1 - global or core issues that prevents a significant number of other issues from being resolved P2 - prevents some other issues from being resolved, but not the bulk of issues at hand P3 - isolated issue, must be resolved at some point, but does not prevent other work P4 - detail, does not prevent other work P5 - detail, resolution not required for beta

# Priority Title Description Resolution Notes 1 P1 Form Navigation Decide how to

navigate within the hierarchy of forms.

From 8/19 brainstorm.

5 P1 Order Navigation Decide how to navigate to new, saved, and placed orders.


2 P1 Navigation Size Problems

Deal with long form names in navigation.

From 9/3 meeting.

3 P2 Forms States If a user visits a form, fills it out, navigates away and then navigates back , is the form still populated? What if it is added to the order?

From 8/19 brainstorm. To be addressed at 9/15 meeting.

4 P3 Logout time What if the user loses the handheld? Personal information could be compromised.

From 9/3 meeting.


P2:

P3:

P4:

P5:

Global or core issue that prevents a significant number of other issues from being resolved.Prevents some issues from being resolved, but not a large number.Isolated issue, must be resolved but does not prevent other work.Detail, does not prevent other work.Detail, resolution not required for beta.

Good:




4. Minimal barriers and constraints.

document decisions

Issue List Issue Priority Definitions: P1 - global or core issues that prevents a significant number of other issues from being resolved P2 - prevents some other issues from being resolved, but not the bulk of issues at hand P3 - isolated issue, must be resolved at some point, but does not prevent other work P4 - detail, does not prevent other work P5 - detail, resolution not required for beta

# Priority Title Description Resolution Notes 1 P1 Form Navigation Decide how to

navigate within the hierarchy of forms.


5 P1 Order Navigation Decide how to navigate to new, saved, and placed orders.


2 P1 Navigation Size Problems

Deal with long form names in navigation.

From 9/3 meeting.

3 P2 Forms States If a user visits a form, fills it out, navigates away and then navigates back , is the form still populated? What if it is added to the order?

From 8/19 brainstorm. To be addressed at 9/15 meeting.

4 P3 Logout time What if the user loses the handheld? Personal information could be compromised.

From 9/3 meeting.

Log out when inactive. Let inactivity period be set by user in preferences.

systems?

Page Type and Widget Libraries

Widget Library:

1. default appearance

2. appropriate use case

3. behavior

5 purposes

1. Documentation

2. Good work

3. Surface issues

4. Basic toolkit

5. Final deliverable

ongoing process

met weekly

?????

?

?

?

?

?

?????

?

?

?

?

?

✔

✔

✔

?????

?

?

?

?

?

✔

✔

✔

?

?????

?

?

?

?

?

✔

✔

✔

?

(closing = documenting)

72 issues

48 closed

P1s and P2s closed

15 P5s

10 open P3 or P4 issues

tangible deliverables

intangible deliverables

what this means

interesting (?)

not unique

“clean slates” are rare

$

never enough time

all projects have “design bugs”

middle

or beginning

the main points

bugs : software development::

issues : design process

Middle-Out Design:

1. priority definitions

2. “good” definition

3. tracking issues

4. assigning priorities

5. important things first

6. document solutions

<boss’ slides>

design methods movement

design rationale

Horst Rittel

IBIS

design = argument

</ boss’ slides>

Try it!

Thank You.

Audrey [email protected]

Dubberly Design Office

Thumb twiddling images from artwork by Naomi Roberston.

Middle Out Design

Design

studies detail1

studies reviews1

analysis synthesis maps1

analysis synthesis1

design issues

thenregular diet

content1 year

thenfull liquid diet