Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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


Published on

UCSF Library Medical Library Association meeting presentation, May 2008.

  • Login to see the comments

  • Be the first to like this

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. </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