Perpetual Beta: Treating Users As Co-Developers Marcus Banks, Sadie Honey, and Julia Kochi UC San Francisco Library and CK...
What Is Perpetual Beta? <ul><li>“ The open source dictum, ‘release early and release often’ in fact has morphed into an ev...
Iterative Design: Decision Continuum May 2008 Iterative Design Potential: Decision Continuum Low High Interdependent servi...
Three Projects, One Concept <ul><li>Federated / Metasearch </li></ul><ul><li>Question Tracking System </li></ul><ul><li>Us...
Federated / Metasearch May 2008
Question Tracking System May 2008
User Toolbars May 2008
Three Projects, One Concept <ul><li>Lessons we have learned along the way… </li></ul>May 2008
Set Expectations <ul><li>Be clear (to yourself as well) that this is an experiment </li></ul><ul><li>Be clear about whose ...
Question Authority <ul><li>Most people don’t look at an interface and see the ways that it can be improved  </li></ul><ul>...
Be Realistic <ul><li>Establish a realistic pace for change—to yourself and users </li></ul><ul><li>Be aware of staff views...
Get Feedback <ul><li>Determine how you will get feedback before the project begins </li></ul><ul><li>It will not come with...
Consider Interdependencies <ul><li>Cascade effect in which one change can affect many other services </li></ul><ul><ul><li...
Pull the Plug  <ul><li>Be willing to accept a project isn’t worth continuing </li></ul><ul><li>Letting something drag on i...
Rinse, Repeat <ul><li>Hold a post-mortem, or “after party” </li></ul><ul><li>Reviewing what went wrong is not a personal c...
Upcoming SlideShare
Loading in …5
×

Treating Users as CoDevelopers: One Library's Experience with Perpetual Beta

468 views

Published on

UCSF Library Medical Library Association meeting presentation, May 2008.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
468
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 06/07/09
  • Treating Users as CoDevelopers: One Library's Experience with Perpetual Beta

    1. 1. Perpetual Beta: Treating Users As Co-Developers Marcus Banks, Sadie Honey, and Julia Kochi UC San Francisco Library and CKM Medical Library Association Annual Meeting, Chicago May 2008
    2. 2. What Is Perpetual Beta? <ul><li>“ The open source dictum, ‘release early and release often’ in fact has morphed into an even more radical position, ‘the perpetual beta,’ in which the product is developed in the open, with new features slipstreamed in on a monthly, weekly, or even daily basis.” </li></ul><ul><ul><li>Tim O'Reilly. What Is Web 2.0., Page 4. End of the Software Release Cycle. http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html?page=4 </li></ul></ul><ul><li>A less loaded term is “iterative design” </li></ul>
    3. 3. Iterative Design: Decision Continuum May 2008 Iterative Design Potential: Decision Continuum Low High Interdependent services with other libraries (ILL) Established policies at own library (Loan periods) New services (wiki server for the campus)
    4. 4. Three Projects, One Concept <ul><li>Federated / Metasearch </li></ul><ul><li>Question Tracking System </li></ul><ul><li>User Toolbars </li></ul><ul><li>All released before they were perfect </li></ul><ul><li>Plan is/was to iterate to improve the product </li></ul><ul><li>Lessons we have learned along the way… </li></ul>May 2008
    5. 5. Federated / Metasearch May 2008
    6. 6. Question Tracking System May 2008
    7. 7. User Toolbars May 2008
    8. 8. Three Projects, One Concept <ul><li>Lessons we have learned along the way… </li></ul>May 2008
    9. 9. Set Expectations <ul><li>Be clear (to yourself as well) that this is an experiment </li></ul><ul><li>Be clear about whose problem you are attempting to solve </li></ul><ul><ul><li>Those impacted by the change may not be the beneficiaries </li></ul></ul><ul><li>Define success (and failure) </li></ul><ul><li>Be clear that you will significantly change course, or abandon a project altogether if warranted </li></ul>May 2008
    10. 10. Question Authority <ul><li>Most people don’t look at an interface and see the ways that it can be improved </li></ul><ul><li>You have to train your users (including staff members) to constructively criticize the product </li></ul><ul><li>You have to train yourself to hear and respond appropriately to the criticism </li></ul>May 2008
    11. 11. Be Realistic <ul><li>Establish a realistic pace for change—to yourself and users </li></ul><ul><li>Be aware of staff views re: rate of change </li></ul><ul><ul><li>Exhausting if constant; need times of stasis </li></ul></ul><ul><li>Limited resources mean a slower rate of change </li></ul>May 2008
    12. 12. Get Feedback <ul><li>Determine how you will get feedback before the project begins </li></ul><ul><li>It will not come without effort </li></ul><ul><li>“Watch” usage </li></ul><ul><ul><li>Are you able to track user statistics? </li></ul></ul>May 2008
    13. 13. Consider Interdependencies <ul><li>Cascade effect in which one change can affect many other services </li></ul><ul><ul><li>Handle with care </li></ul></ul><ul><li>Rate of iteration will be slower with interdependent projects </li></ul>May 2008
    14. 14. Pull the Plug <ul><li>Be willing to accept a project isn’t worth continuing </li></ul><ul><li>Letting something drag on indefinitely is demoralizing </li></ul><ul><li>Define success and/or failure at the beginning of the project </li></ul><ul><li>Be aware that staff may feel like they have “failed” if a project gets cut </li></ul>May 2008
    15. 15. Rinse, Repeat <ul><li>Hold a post-mortem, or “after party” </li></ul><ul><li>Reviewing what went wrong is not a personal criticism </li></ul><ul><li>There is a lot to learn from a “failed” project </li></ul><ul><ul><li>Hard but essential step </li></ul></ul><ul><li>Try and try again </li></ul><ul><ul><li>Act on what you’ve learned </li></ul></ul>May 2008

    ×