1 / 13

Dollars as Metric

Dollars as Metric. Randolph G. Bias School of Information The University of Texas at Austin rbias@ischool.utexas.edu June 12, 2006. Why the book?. Three years at Bell Labs, and a decade at IBM, as a usability-slash-human-factors professional had led to frustration and hair loss.

nero-brennan
Download Presentation

Dollars as Metric

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Dollars as Metric Randolph G. Bias School of Information The University of Texas at Austin rbias@ischool.utexas.edu June 12, 2006

  2. Why the book? • Three years at Bell Labs, and a decade at IBM, as a usability-slash-human-factors professional had led to frustration and hair loss. • I thought we needed a way to convince the ever-doubtful developer community of our value.

  3. Benefits I have known and loved • To the development team • Increased development efficiency • Reduced training materials need • To the development company • Increased sales/visits/conversion rates • Reduced customer support burden • Increased confidence at ship/go-live time • Increased trade press joy, and a resultant halo effect • To the customer/user • Increased efficiency/throughput (reduced time making and recovering from errors) • Reduced training time • Reduced turnover

  4. The Cost-Benefit Analysis approach has been a panacea – universally lauded as THE reason usability has become a de facto part of the software development process. • Well, OK . . . maybe not so much.

  5. Now I’d like to offer . . . • 2 reasons why we have a problem • 2 reasons why it’s worse with the Web • 2 joys • 2 agonies • 1 new idea

  6. Why we have a problem • What other service provider in the world has to spend so much of his/her time convincing would-be clients that this service is needed? • If you need a plumber, the evidence is sloshing around your feet. • Software developers think they are human, and so they think they can depend on their own intuitions.

  7. Why it’s only WORSE with the Web • Web developers have even LESS of an understanding of their (broader) user audience. • Web development managers USED to be client-server application developers. • And the ol’ “let’s get something out there and make improvements as we get user feedback” technique doesn’t work.

  8. Two Joys • Joy #1 – It IS possible to quantify the benefits, and such an effort tends to demonstrate the ROBUST ROI for one’s usability dollar and hour. • Joy #2 – Many usability professionals report having used such an approach, with good results.

  9. Two Agonies • Agony #1 – Confounds. It is not often the case that we can attribute benefits solely to usability work. • Agony #2 – Projections. To be most effective and convincing, we gotta offer PROJECTED ROI. Which can be hard to do.

  10. Why “confounds” aren’t a deal-breaker • First, an anecdote. • EVERYTHING in business is confounded, anyway. • Hooray for reduction of uncertainty. • In my experience, after we prove ourselves once, we don’t have to do so anymore with that team. • (An aside – please note, this is about MORE than proving ourselves. We also need to show ourselves WHICH method is best when.)

  11. Why “projections” aren’t a deal-breaker • EVERYTHING in business (that we’re competing against) is based on projections, anyway. • LOC • We CAN do this – e.g., based on early prototype testing.

  12. One new idea • Software Development VPs can’t hold very much information in their heads at one time (he overgeneralizes). • What they need is one number: • “That UI is a ‘6,’ and it needs to be a ‘7.’” • Imagine some baseline data on various types of UIs (eCommerce, word processor) – with weightings for time on task, error rates, # of references to the helps, # of calls to the help desk . . . . Combine the data for a single number. • Establish a “best of show” for each type. Compare all future UIs to it.

  13. And so . . . • I dunno. • Rich, what’s next?

More Related