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 © 2010 Desirée Sy, All rights reserved

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 © 2010 Desirée Sy, All rights reserved

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 © 2010 Desirée Sy, All rights reserved

THE PROBLEM

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

ﬂ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 © 2010 Desirée Sy, All rights reserved

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 © 2010 Desirée Sy, All rights reserved

agile big picture • Big = “high-level” NOT “detailed” • Not just up front • Capable of continuous improvement • Shared + visible • Just-in-time detail and documentation © 2010 Desirée Sy, All rights reserved

THE FRAMEWORK

Levels of detail Sprint Capability Release Product

AGILE + THE BIG PICTURE

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 © 2010 Desirée Sy, All rights reserved

In action... Product vision • For creative professionals • Sketching: responsive, quick, loose • Drop: Image processing • Rank: Brushes, make it faster, promote ﬂow © 2010 Desirée Sy, All rights reserved

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 © 2010 Desirée Sy, All rights reserved

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 © 2010 Desirée Sy, All rights reserved

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 © 2010 Desirée Sy, All rights reserved

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 © 2010 Desirée Sy, All rights reserved

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) © 2010 Desirée Sy, All rights reserved

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 © 2010 Desirée Sy, All rights reserved

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 © 2010 Desirée Sy, All rights reserved

DESIGN CHUNKING

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” © 2010 Desirée Sy, All rights reserved

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) © 2010 Desirée Sy, All rights reserved

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. © 2010 Desirée Sy, All rights reserved

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 © 2010 Desirée Sy, All rights reserved

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 © 2010 Desirée Sy, All rights reserved

In action Brush Resize design goals: • 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) © 2010 Desirée Sy, All rights reserved

In action Brush Resize with hotkey: Disposable code prototypes • Resizing without Brush Editor • One control for size, not 2-5 • Keep focus in-canvas • Fewer dialogues (covering the work) © 2010 Desirée Sy, All rights reserved

In action • Workﬂow prototype: Disposable coded prototype • First 5 minutes: learn without documents • Combined with 2 other user stories: Brush Palette and Custom Brushes © 2010 Desirée Sy, All rights reserved

MINI-RELEASES

‘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? © 2010 Desirée Sy, All rights reserved

In action Per-brush Properties dialog with Size control: • Overlap with Custom Brushes • First 5 minutes: learn without documents • Resizing without Brush Editor • One control for size, not 2-5 • Stylus only (no keyboard) © 2010 Desirée Sy, All rights reserved

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. © 2010 Desirée Sy, All rights reserved

PUTTING IT TOGETHER

“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 © 2010 Desirée Sy, All rights reserved

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

by DesireeSy

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 3

Statistics

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

http://us-w1.rockmelt.com	1
http://paper.li	1
http://www.techgig.com	1