Languages
Pages
Legal
Introduction
What is DesignWhat is Coding
XP and Agile Programming
Agile Design: How to merge Agile processes and design principles
Q&A
Web 2.0 = ?
Web 2.0 = play
Web 2.0 = play faster
Design Methods
Design
Strategy
Graphics
User Centered
Front End Coding
User Interface
Information Architecture
InteractiveInteraction
Research
User Flow
Concepts
Design Methods
Design
I design.
Design Methods
Research
Thought
Modeling
Communication
Play
Re-design
Design Methods
I design.
Coding
Coding Methods
Model-View-Controller
Databases
JavaScript
Java
Debugging
CSS
Version Control
IDEs Research
CodingRuby
Design Patterns
UML Diagrams
Deploying
Perl
Object-Oriented Design
Best Practices
Scripting
Coding Methods
I code.
Coding Methods
I code.Research
Thought
Modeling
Communication
Play
Re-design
Coding Methods
“Design is finding the problem, not the solution.”
—Leslie Chicoine
The Big Idea
The hard problems are…
• people problems– (mis-) communication– (not enough) feedback– (not fully) comprehending constraints
• process problems– deadline and resource management– design flexibility in the face of frequent change
Where can we find a people-oriented process, and process-oriented people?
Extreme Programming is an Agile Process
– Motto: Embrace Change– Other Agile Processes include Scrum, Crystal Clear,
Adaptive Software Development, Feature Driven Development, DSDM, Agile Modeling
XP Defined
Extreme Programming is an Agile Process• Values
FeedbackCommunicationSimplicityCourage
XP Defined
XP Practices
Collective Ownership
Pairing
Continuous Improvement
Continuous Integration
testing
refactoring
simple design
High code quality
Sustainable PaceOn-site Customer
design by discussion
frequent spontaneous
working sessions
Suggest and agree to process changes
”Ask the room”
“Don’t be stupid.”
retrospectives
Incremental design,
development, deployment
Weekly demos
XP Practices
XP Cycles– Rapid Iteration, small releases
– Frequent planning/design sessions• Iteration Planning, Release Planning• Break down requirements into stories into tasks• Daily Standup• Regular All-Hands Retrospectives
– Frequent (weekly) demos• of deployed, 100% functional software• real code, real db, real ui, but only some of the stories• coders, clients, designers, PMs are all in the room
XP Cycles
XP Meets Waterfall Design
Extreme Programming
Waterfall Design
XP Meets Waterfall Design
Extreme Programming Waterfall Design
XP Meets Waterfall Design
• The three things we do in XP that any team should do
Weekly demos Daily standups Pairing
Caution: May provoke resistance and hostility
XP Staples
Agile Design
Agile Design
“Plans are useless, but planning is indispensable.”
-Dwight D. Eisenhower
Agile Design
Embracing change
Communal design ownership
Evolving solutions
Agile Design
Agile Design
Agile Design
“Make it OK for people to challenge an idea or two, the good ideas can withstand it and the weaker ideas fall away and make room for something [better].”
-Brad Bird, Writer/Director of the Incredibles
Agile Design
“He’ll take good ideas from wherever they come from.”
“He asks you, he wants to know what you think.”
Agile Design
Scales of Design
Scales of Design
ConceptBusiness GoalsUser Tasks / MotivationsSite Flow & WayfindingSupporting SystemsNavigationWidgetsGlobal StylesLanguageButtons GraphicsFonts
Large Scale
Small Scale
Scales of Design
The Large Scale is tested in the Small Scale.
The Small Scale reveals if the Large Scale ideas are solid.
Scales of Design
Play faster.
Scales of Design
Play faster.
Scales of Design
Play faster.
Scales of Design
Play faster.
Scales of Design
ConceptBusiness GoalsUser Tasks / MotivationsSite Flow & WayfindingSupporting SystemsNavigationWidgetsGlobal StylesLanguageButtons GraphicsFonts
Large Scale
Small Scale
Scales of Design
Problems vs. Solutions
Problems vs. Solutions
“Design is finding the problem, not the solution.”
Problems vs. Solutions
Documents as communication space
Not as blueprints
Problems vs. Solutions
Problems vs. Solutions
Problems vs. Solutions
Expose and flesh out the problems
While manage constraints
Problems vs. Solutions
Suggest solutions
Share the outcome to create buy-in
Problems vs. Solutions
Open Design
Open Design
Agile demands open: it’s got to be flexible and extensible.
Open Design
Open Design
Expose to create depth.
ConceptBusiness GoalsUser Tasks / MotivationsSite Flow & WayfindingSupporting SystemsNavigationWidgetsGlobal StylesLanguageButtons GraphicsFonts
Large Scale
Small Scale
Scales of Open Design
Open Design
Open Design
Open Design
Open Design
Small Scale as reflection of Large Scale
Design emerges from simple rules
Designers should…
• Design a week in advance of coding• Not make your mockups pixel-perfect• Work literally side-by-side with coders when
implementing mockups• Allow coders to participate in IA/UI design —
Especially after the coding has already started
Coders should…• Coders should ask designers… or else
– time is wasted re-working solved issues– solutions are implemented that don't work with other parts of
the designed system– coders make assumptions based on mockups
• Coders should give frequent live demos… or else– designers don't know what parts of the design are/aren't
working– designers don't know what parts of the design aren't working
together– coders don't know their code has bugs or needs tweaking
How to integrate with an outside design company?
• Communication and feedback are naturally more stretched out
• Some unnatural (or at least un-Agile) barriers are imposed
– Time and space
– Signoff procedures
– Documentation / specs
– Perfectionism
– Mistrust
• Bring them in to your process as much as you can
• Don’t force them to adapt too much or they’ll resent and demonize you
• Iterate per-month at first, then per-week
• Invite them to your demos (remotely if need be)