incremental redesign

a more manageable approach to improving your web site

rose pruyne

the pennsylvania state university

i. history of a classic user interface

i. history of a classic user interface

i. history of a classic user interface

i. history of a classic user interface

i. history of a classic user interface

i. history of a classic user interface

i. history of a classic user interface

i. history of a classic user interface

ii. traditional automobile dashboard

iii. automobile dashboard redesigned by a web committee

iv. the big web site rollout: a time-honored tradition

iv. the big web site rollout: a time-honored tradition

iv. the big web site rollout: a time-honored tradition

iv. the big web site rollout: a time-honored tradition

iv. the big web site rollout: a time-honored tradition

iv. the big web site rollout: a time-honored tradition

iv. the big web site rollout: a time-honored tradition

v. the notion of big rollouts

• has its roots in paper publishing

v. the notion of big rollouts

• has its roots in paper publishing
• and microsoft

v. the notion of big rollouts

• has its roots in paper publishing
• and microsoft
• and extremely outdated "wisdom" ...

v. the notion of big rollouts

• has its roots in paper publishing
• and microsoft
• and extremely outdated "wisdom" ... that recommended a web redesign every six months!

vi. a cycle of big rollouts sends the wrong message

• we're more interested in fiddling with designs than addressing user needs

vi. a cycle of big rollouts sends the wrong message

• we're more interested in fiddling with designs than addressing user needs
• ... or providing good content

vi. a cycle of big rollouts sends the wrong message

• we're more interested in fiddling with designs than addressing user needs
• ... or providing good content
• we're basing our designs on internal decisions, not user requirements

vi. a cycle of big rollouts sends the wrong message

• we're more interested in fiddling with designs than addressing user needs
• ... or providing good content
• we're basing our designs on internal decisions, not user requirements
• we're treating our web presence like print media

vi. a cycle of big rollouts sends the wrong message

• we're more interested in fiddling with designs than addressing user needs
• ... or providing good content
• we're basing our designs on internal decisions, not user requirements
• we're treating our web presence like print media
• our priorities are constantly shifting

vi. a cycle of big rollouts sends the wrong message

• we're more interested in fiddling with designs than addressing user needs
• ... or providing good content
• we're basing our designs on internal decisions, not user requirements
• we're treating our web presence like print media
• our priorities are constantly shifting
• we're not exactly sure what to do with our web site

ix. big rollouts drive users crazy

• the user support network breaks down

ix. big rollouts drive users crazy

• the user support network breaks down
• new AND returning users have to learn where to find everything all over again

ix. big rollouts drive users crazy

• the user support network breaks down
• new AND returning users have to learn where to find everything all over again
• users frequently have to learn a new taxonomy

ix. big rollouts drive users crazy

• the user support network breaks down
• new AND returning users have to learn where to find everything all over again
• users frequently have to learn a new taxonomy
• no matter how carefully you try to inform users, big rollouts still come as a surprise

viii. example: surprising users with constantly shifting navigation

viii. example: surprising users with constantly shifting navigation

viii. example: surprising users with constantly shifting navigation

viii. example: surprising users with constantly shifting navigation

viii. example: surprising users with constantly shifting navigation

viii. example: surprising users with constantly shifting navigation

viii. example: surprising users with constantly shifting navigation

viii. example: surprising users with constantly shifting navigation

ix. big rollouts drive users crazy

• the user support network breaks down
• new AND returning users have to learn where to find everything all over again
• users frequently have to learn a new taxonomy
• no matter how carefully you try to inform users, big rollouts still come as a surprise
• users are disturbed by dramatic (or what they perceive as dramatic) site changes

x. example of a percieved dramatic site change: eBay.com

x. example of a percieved dramatic site change: eBay.com

xi. big rollouts

• take months to accomplish

xi. big rollouts

• take months to accomplish
• can become obsolete even before they're done

xi. big rollouts

• take months to accomplish
• can become obsolete even before they're done
• consume vast quantities of resources

xi. big rollouts

• take months to accomplish
• can become obsolete even before they're done
• consume vast quantities of resources
• frequently require needless content freezes

xi. big rollouts

• take months to accomplish
• can become obsolete even before they're done
• consume vast quantities of resources
• frequently require needless content freezes
• frequently require simultaneous maintenance of two web sites with the same content

xi. big rollouts

• take months to accomplish
• can become obsolete even before they're done
• consume vast quantities of resources
• frequently require needless content freezes
• frequently require simultaneous maintenance of two web sites with the same content
• encourage "design by committee"

xi. big rollouts

• take months to accomplish
• can become obsolete even before they're done
• consume vast quantities of resources
• frequently require needless content freezes
• frequently require simultaneous maintenance of two web sites with the same content
• encourage "design by committee"
• bog down web teams, divert them from issues that require a more immediate response

xi. big rollouts

• take months to accomplish
• can become obsolete even before they're done
• consume vast quantities of resources
• frequently require needless content freezes
• frequently require simultaneous maintenance of two web sites with the same content
• encourage "design by committee"
• bog down web teams, divert them from issues that require a more immediate response
• become unwieldy and disjointed over time

xi. big rollouts

• take months to accomplish
• can become obsolete even before they're done
• consume vast quantities of resources
• frequently require needless content freezes
• frequently require simultaneous maintenance of two web sites with the same content
• encourage "design by committee"
• bog down web teams, divert them from issues that require a more immediate response
• become unwieldy and disjointed over time
• almost always take longer than everybody wants

xi. big rollouts

• take months to accomplish
• can become obsolete even before they're done
• consume vast quantities of resources
• frequently require needless content freezes
• frequently require simultaneous maintenance of two web sites with the same content
• encourage "design by committee"
• bog down web teams, divert them from issues that require a more immediate response
• become unwieldy and disjointed over time
• almost always take longer than everybody wants
• lead to proliferation of site-wide mistakes

xi. big rollouts

• are hell to troubleshoot

xi. big rollouts

• are hell to troubleshoot
• are hell to document

xi. big rollouts

• are hell to troubleshoot
• are hell to document
• are hell to manage

xii. times when a big rollout makes sense

• when a site is in such disarray that every layer needs to be replaced:

xii. times when a big rollout makes sense

• when a site is in such disarray that every layer needs to be replaced:
• new architecture
• new technology
• new organization
• new navigation
• new content

xii. times when a big rollout makes sense

• when a site is in such disarray that every layer needs to be replaced:
• new architecture
• new technology
• new organization
• new navigation
• new content
• when the organization undergoes a drastic change in identity (and how often does that happen?)

xii. times when a big rollout makes sense

• when a site is in such disarray that every layer needs to be replaced:
• new architecture
• new technology
• new organization
• new navigation
• new content
• when the organization undergoes a drastic change in identity (and how often does that happen?)
• when you are migrating to a new architecture...

xii. times when a big rollout makes sense

• when a site is in such disarray that every layer needs to be replaced:
• new architecture
• new technology
• new organization
• new navigation
• new content
• when the organization undergoes a drastic change in identity (and how often does that happen?)
• when you are migrating to a new architecture... MAYBE

xiii. incremental redesign

xix. applying the principles of agile programming

• integrate site changes in small doses. do this regularly and often

xix. applying the principles of agile programming

• integrate site changes in small doses. do this regularly and often
• keep your users close: make them part of the ongoing development

xix. applying the principles of agile programming

• integrate site changes in small doses. do this regularly and often
• keep your users close: make them part of the ongoing development
• fix the bugs they find QUICKLY

xix. applying the principles of agile programming

• integrate site changes in small doses. do this regularly and often
• keep your users close: make them part of the ongoing development
• fix the bugs they find QUICKLY
• accept that you will learn as you go, and that your users are your primary teachers

xix. applying the principles of agile programming

• integrate site changes in small doses. do this regularly and often
• keep your users close: make them part of the ongoing development
• fix the bugs they find QUICKLY
• accept that you will learn as you go, and that your users are your primary teachers
• apply rigorous testing, evaluating, validation

xix. applying the principles of agile programming

• integrate site changes in small doses. do this regularly and often
• keep your users close: make them part of the ongoing development
• fix the bugs they find QUICKLY
• accept that you will learn as you go, and that your users are your primary teachers
• apply rigorous testing, evaluating, validation
• practice team programming (if you've got the team)

xix. applying the principles of agile programming

• integrate site changes in small doses. do this regularly and often
• keep your users close: make them part of the ongoing development
• fix the bugs they find QUICKLY
• accept that you will learn as you go, and that your users are your primary teachers
• apply rigorous testing, evaluating, validation
• practice team programming (if you've got the team)
• adhere to web standards, make usability your mantra

xix. applying the principles of agile programming

• integrate site changes in small doses. do this regularly and often
• keep your users close: make them part of the ongoing development
• fix the bugs they find QUICKLY
• accept that you will learn as you go, and that your users are your primary teachers
• apply rigorous testing, evaluating, validation
• practice team programming (if you've got the team)
• adhere to web standards, make usability your mantra
• leverage reusable objects

xix. applying the principles of agile programming

• integrate site changes in small doses. do this regularly and often
• keep your users close: make them part of the ongoing development
• fix the bugs they find QUICKLY
• accept that you will learn as you go, and that your users are your primary teachers
• apply rigorous testing, evaluating, validation
• practice team programming (if you've got the team)
• adhere to web standards, make usability your mantra
• leverage reusable objects
• practice comprehensive documentation

xx. example of incremental redesign: eBay.com

xx. example of incremental redesign: eBay.com

xx. example of incremental redesign: eBay.com

xx. example of incremental redesign: eBay.com

xx. example of incremental redesign: eBay.com

xx. example of incremental redesign: eBay.com

xxi. example of incremental redesign: amazon.com

xxi. example of incremental redesign: amazon.com

xxi. example of incremental redesign: amazon.com

xxii. example of incremental redesign: das.psu.edu

xxii. example of incremental redesign: das.psu.edu

xxii. example of incremental redesign: das.psu.edu

xxii. example of incremental redesign: das.psu.edu

xxii. example of incremental redesign: das.psu.edu

xxii. example of incremental redesign: das.psu.edu

xxii. example of incremental redesign: das.psu.edu

xxii. example of incremental redesign: das.psu.edu

xxii. example of incremental redesign: das.psu.edu

xxii. example of incremental redesign: das.psu.edu

xxii. example of incremental redesign: das.psu.edu

xxii. example of incremental redesign: das.psu.edu

xxii. example of incremental redesign: das.psu.edu

xxii. example of incremental redesign: das.psu.edu

xxiii. advantages of incremental design

• far more manageable - especially for small teams and lone webmasters

xxiii. advantages of incremental design

• far more manageable - especially for small teams and lone webmasters
• can make better use of part-time, temporary employees, e.g. students

xxiii. advantages of incremental design

• far more manageable - especially for small teams and lone webmasters
• can make better use of part-time, temporary employees, e.g. students
• allows for prototyping and perfecting technologies before moving on

xxiii. advantages of incremental design

• far more manageable - especially for small teams and lone webmasters
• can make better use of part-time, temporary employees, e.g. students
• allows for prototyping and perfecting technologies before moving on
• more feasible to drop technologies that are not working

xxiii. advantages of incremental design

• far more manageable - especially for small teams and lone webmasters
• can make better use of part-time, temporary employees, e.g. students
• allows for prototyping and perfecting technologies before moving on
• more feasible to drop technologies that are not working
• conversion of future sections becomes increasingly a breeze

xxiii. advantages of incremental design

• far more manageable - especially for small teams and lone webmasters
• can make better use of part-time, temporary employees, e.g. students
• allows for prototyping and perfecting technologies before moving on
• more feasible to drop technologies that are not working
• conversion of future sections becomes increasingly a breeze
• far less large-scale trouble shooting

xxiii. advantages of incremental design

• far more manageable - especially for small teams and lone webmasters
• can make better use of part-time, temporary employees, e.g. students
• allows for prototyping and perfecting technologies before moving on
• more feasible to drop technologies that are not working
• conversion of future sections becomes increasingly a breeze
• far less large-scale trouble shooting
• documentation less cumbersome

xxiii. advantages of incremental design

• far more manageable - especially for small teams and lone webmasters
• can make better use of part-time, temporary employees, e.g. students
• allows for prototyping and perfecting technologies before moving on
• more feasible to drop technologies that are not working
• conversion of future sections becomes increasingly a breeze
• far less large-scale trouble shooting
• documentation less cumbersome
• simpler rollback, if necessary

xxiii. advantages of incremental design

• easier to collect and manage content

xxiii. advantages of incremental design

• easier to collect and manage content
• easier to manage content providers

xxiii. advantages of incremental design

• easier to collect and manage content
• easier to manage content providers
• nearly painless for users

xxiii. advantages of incremental design

• easier to collect and manage content
• easier to manage content providers
• nearly painless for users
• users are happier with your product

xxiii. advantages of incremental design

• easier to collect and manage content
• easier to manage content providers
• nearly painless for users
• users are happier with your product
• users are more involved - easier to get feedback

xxiii. advantages of incremental design

• easier to collect and manage content
• easier to manage content providers
• nearly painless for users
• users are happier with your product
• users are more involved - easier to get feedback
• usability studies more focused, less amorphous

xxiv. watch out for these

• clutter creep (amazon did this)

xxiv. watch out for these

• clutter creep (amazon did this)
• taped-on, glued-on, bolted-on features and technologies

xxiv. watch out for these

• clutter creep (amazon did this)
• taped-on, glued-on, bolted-on features and technologies
• rabbiting

xxv. the bottom line

• more fun

xxv. the bottom line

• more fun
• more creativity

xxv. the bottom line

• more fun
• more creativity
• more innovation

xxv. the bottom line

• more fun
• more creativity
• more innovation
• less burnout!

xxvi. further reading

• this presentation: blogs.das.psu.edu/webcontent/wp-content/uploads/id/
• zip file of this presentation: blogs.das.psu.edu/webcontent/wp-content/uploads/id/id.zip
• companion article: blogs.das.psu.edu/rpruyne
• jared spool: the quiet death of the major re-launch
• jared spool: designing embraceable change
• ron jeffries: what is extreme programming?
• j. donovan welles: extreme programming: a gentle introduction
• manifesto for agile software development
• content.psu.edu