Big picture design without Big Design Up Front (Agile Roots 2010)

Big picture design
without
Big Design Up Front
Agile Roots 2010

Desirée Sy
Media + Entertainment

ﬂexible tunnel vision

just enough sprint tools
small increments
quality faster to wrong
timeboxed
product
iterative
change-friendly
t collaborative
react instead of
faster to product reﬂect

continuous treadmill


missing ingredient?

context

UX methods can provide this


Ye olde UX

• Often front-loaded
• Data isn’t refreshed during project
• Documents have detail, but often no insight


a.k.a.
Big Design Up Front


a.k.a.
UX methods “but”


• “Adapting Usability Investigations for Agile
User-Centered Design” JUS, May 2007

• http://tiny.cc/agileUCD

dsy.agileUX@gmail.com
Twitter: @DesireeSy
(tweeting all links in this presentation)


can’t code
(no... really!)


agile UX practitioner
(a very good one)


ethnography
+
behaviour prototyping
+
UX validation

user research
+
‘mini-ﬁ’* prototypes
+
usability testing
*‘minimum-ﬁdelity’

... deconstructed to ﬁt within sprint-length


Usually, I speak here....

... So if I use UX jargon, please ask me right away


4

I
agile UX

Agile UX: the good
• Narrows the gap • Contextual inquiry &
between finding and usability testing on
fixing issues actual product

• Less “design drift” • Satisfying to see designs
in real use
• User data has effect on
current release • Face-to-face is better
than “over the wall”
• Most important features
are done first • Enables requirements
iteration


My agile UX
background
Before we were Autodesk...
Alias
• products and users
• UX team
• agile team


• Commercial,
shrinkwrapped software

• 3D graphics,
highly interactive

• Non-standard UI

• Users:
Creative professionals

• Generative, open-ended
tasks


UX team
• 1 manager
• 4 interaction designers (generalists)
• 2 graphic designers
• UX developer (student intern)


established UX team


agile team
• 1 product manager
• 1 dev lead
• 2.5 developers (the 0.5 is the dev lead)
• 1.5 interaction designers
• 1 UX developer (student intern)
• 1 QA
• 1 documentation
• 1 graphic designer

full-time*, co-located

*except for managers & graphic designer

product owner
=
product manager
+
dev lead
+
interaction designer

product owner

=
every team member


Sprint Zero
+
Iteration Planning


Stay tuned for...

agile UX planning
(Agile 2010)


Big picture of the talk
• The problem + the framework
• Agile + the big picture
• Design chunking
• Mini-releases
• Putting it together


from
Jeff Patton’s keynote


output outcome

we build this we want this

©
2009
Jeﬀ
Pa+on,
all
rights
reserved,
www.AgileProductDesign.com 42

solving problems
NOT
building solutions


Learning about the
world, imagining
solutions, evaluating
working solutions in
the world

Building high-
quality working
software

Pay equal attention to “discovery”
practice and “delivery” practice

discovery:
problem deﬁnition


some problems take
>2 weeks to solve
(but they can still be solved in 2-week increments)


output outcome

we build this we want this

©
2009
Jeﬀ
Pa+on,
all
rights
reserved,
www.AgileProductDesign.com 47

Outcomes ARE
measurable


Joshua Porter: http://slidesha.re/bDtLpG

Dana Chisnell: http://j.mp/aTV8fX

discovery tools
big
up front


The big picture
is true north


big picture symptoms
• Incomplete user workﬂows
• Feature creep (but in smaller units)
• “Value” thresholds aren’t deﬁned
• Can’t cope with new feedback
• Don’t know what “done” means


agile big picture
• Big = “high-level” NOT “detailed”
• Not just up front
• Capable of continuous improvement
• Shared + visible
• Just-in-time detail and documentation


Levels of detail
Sprint

Capability

Release

Product

Goals
• Applied to backlog, let you:
• discard
• sort
• rank
• Focus UX investigations
• As requirements, they can deﬁne “done”

John Schrag: http://j.mp/9WTn8c

Example
• SketchBook Pro
• Tablet PC + Wacom tablets


Before breaking
designs into iterations...


... think about
Product and Release
goals


Product goals
Product vision
• Who it’s for (and not)
• What it is (and isn’t)
Design/Engineering/Business
Principles
• Deﬁne product characteristics to drive
decisions


In action...
Product vision
• For creative professionals
• Sketching: responsive, quick, loose

• Drop: Image processing
• Rank: Brushes, make it faster,
promote ﬂow


In action...
Design Principles
• Elegant simplicity, Stylus-friendly,
Self revealing, Maximum work area

• Drop/Rank: Don’t add because we can
• Design “Done”: All features must have
access without a keyboard
• Investigate: Discoverability, Clutter

In action...
Design and Engineering Principles
• Self revealing/Optimize (fast + small code)
• Design had large set of icons, but that
added to code weight. We redesigned.
Business Principles
• Enter broader market
• Design and code for trial version

In action...
TiVo Design Principle
• It’s entertainment, stupid
• “Lean back, not forward”
• Drop/rank: No keyboard entry
- “How (Not) to Destroy a Great
User Experience” UPA 2006
Rich Fulcher, Rachel Garb, Alex Liston, Donna Slote


In action...
Apple iPhone
iOS 1.0 and 2.0
• “Done”:
Cut + Paste


When?
• Good projects already have them
(regardless of SW methodology)
• Before Sprint Zero
• At the time project is ‘green-lit’
• OR if a product is being ‘reset’
• For small products, could be Sprint Zero
of v1 release


Release goals
• Pragmatic distillation of business goals
• Although business-focused, needs to be
input from development and design
• Aligns the team trajectory
• Guidance for course corrections
• Not the backlog (or a subset of it)

In action
• SketchBook Pro v2
• “Remove barriers to purchase from trial”
• Research: Survey. Focused the ‘who’
• Drop/Rank: 200 > 25 > 10 (top 5)
• Drop: Saving colours
• Consensus: Dropped Rotate Canvas

In action
• Rare but powerful: Redeﬁne the release
• SketchBook Pro v1.1
• “Mac OS X port”
• Reset the alignment
• Promote: Add keyboard shortcuts

When and how?
• Sprint Zero of upcoming release
• How many iterations per release?
• NO designs!
• Just enough detail to share direction
• Deﬁne problems, not solutions


Once you have the
big picture...


... set design goals
at the Capability level


Capability/Sprint goals
• Articulate problems to solve for a
workflow/user story
• Carry forward as sprint goals
• Defined through chunked research
• Used to chunk designs
• Used to chunk mini-releases
• Used to define “done”

In action
Brush Resize


In action
Brush Resize
• First 5 minutes: learn without documents
• Resizing without Brush Editor
• One control for size, not 2-5
• Keep focus in-canvas
• Fewer dialogues (covering the work)
• Stylus only (no keyboard)

Tear and build
• Design a capability over >1 cycle.
• Break a design into chunks.
• Mix and match chunks in investigations:
mini-research, usability test and iterate on
mini-prototype.
• Look at the design at the Capability level.
Now break it into mini-speciﬁcations, to be
coded over >1 sprint.

(To repeat:) Stay tuned for...

agile UX planning
(Agile 2010)


Caveats
• You’ll need to establish a buffer ﬁrst
• Even with the buffer, you’ll still need to
write mini-specs for the next cycle
• It is Big Design if
>1 = too many sprints


Design chunking
• Look at the list of capability goals
• What can you investigate over next few
sprints?
• Layer sprint-sized investigations and
prototypes to meet all required goals


In action
Brush Resize design goals:
• Fewer dialogues (covering the work)

In action
Brush Resize design chunks:
• Brush Resize with hotkey
• Brush Resize with stylus (interaction)
• Brush Resize with stylus (look)
• “Workﬂow” prototype


In action
Brush Resize with hotkey:
Disposable code prototypes

• Resizing without
Brush Editor
• One control for size,
not 2-5
• Fewer dialogues
(covering the work)


In action
• Brush Resize with stylus (interaction):
Whiteboard prototype



In action
• Brush Resize with stylus
(look):
Graphic designs

• Stylus only (no
keyboard)


In action
• Workﬂow prototype:
Disposable coded prototype

• Combined with 2 other user stories:
Brush Palette and Custom Brushes


‘Small Design’
User Stories
• Look at the list of the Capability goals
• Which users will see the next cuts + when?
• Layer the implementation to deliver on key
Capability/Release goals in every sprint
• Think worst-case scenario: is each
incremental build shippable?


In action
Brush Resize implementation:
• Per-brush Property Editor, with Size control
• Brush Resize widget


In action
Per-brush Properties dialog
with Size control:
• Overlap with Custom Brushes

• First 5 minutes: learn without
documents





In action
Brush Resize widget:


• Fewer dialogues (covering the
work)


Usability
acceptance criteria
• Sit with developers as they are turning the
user stories into hard estimates.
• Make sure you understand how each of
their pieces ﬁts in the capability.
• Sit with testers to add code-testable
usability criteria if needed.


In action
Heads up display

• Fixed decimal point


“Big picture” design
• product + release goals = big picture
• capability goals come from this
• multi-sprint designs become design chunks
• design is “done” when design goals are met
• write Small Design user stories
• UX requirements: on unit with estimates
• check incoming reqs against all goals

expanding
agile UX activities


• Create prototypes

• Rapid usability testing

• Identify and fix problems

• Define mini-specifications

• Check implementation


Machete
Clear obstacles

(faster and better)


Compass
Check direction

(reﬁne intent)


• Rapid longitudinal user
research

• Set design goals

Help to:

• Group and prioritize backlog

• Plan product exposure

• Recognize “done”


Thanks.

dsy.agileUX@gmail.com
@DesireeSy


Big picture design without Big Design Up Front (Agile Roots 2010)

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Big picture design without Big Design Up Front (Agile Roots 2010)

Semelhante a Big picture design without Big Design Up Front (Agile Roots 2010) (20)

Último

Último (20)

Big picture design without Big Design Up Front (Agile Roots 2010)