Friday, September 26, 2008
Digression: Stewart/Colbert interview
EW interviewed the two funniest guys in the country about politics and the press. Stewart and Colbert give voice to things we all know but don't have the courage or cleverness to say properly. This interview made me laugh until I couldn't breathe.
Thursday, September 25, 2008
"Thank you for calling the Therapy Hotline..."
What do you think when you read a story about psychotherapy delivered over the phone? A room full of customer service representatives in small cubicles staring at monitors and helping callers with their problems? "You say you had a dream about your high school math teacher, a dragon, and a small dark room? Hold on while I access that information..." It's not necessarily like that. Some companies operate virtual call centers with high priced financial advisors or M.D.s working from their own offices, delivering professional advice while building relationships with the callers.
The history of automated therapy goes back to Weizenbaum's Eliza program in 1965. If phone service therapy catches on it won't be long before someone tries to save a little money by implementing an IVR to take the routine therapy questions. "For dream interpretation, press 1. For a pep talk, press 2. All other calls, press zero or remain on the line." Better yet, therapists could set up shop in Second Life so they could meet their clients "face to face."
The history of automated therapy goes back to Weizenbaum's Eliza program in 1965. If phone service therapy catches on it won't be long before someone tries to save a little money by implementing an IVR to take the routine therapy questions. "For dream interpretation, press 1. For a pep talk, press 2. All other calls, press zero or remain on the line." Better yet, therapists could set up shop in Second Life so they could meet their clients "face to face."
Monday, September 22, 2008
Security and usability
IT security people have a tough task. They need to provide systems that can't be accessed by outsiders but are easy for insiders to use and allow them to get their work done. The problem is, the outsiders who try to crack systems are much, much better at what they do then most computer users are at understanding security. Most people don't give security a thought unless their identities are stolen or their accounts are hacked. The recent news item about VP candidate Palin's Yahoo! account being hacked shows how easy it is to learn someone's security questions and use them to reset a password.
I attended one of the first meetings of IT security and usability engineers at the CHI conference in Ft. Lauderdale in 2003. It was two groups of people who hadn't given the other much thought before, but we all could clearly see the value of collaborating in the future. Part of this is an organizational problem, because people aren't rewarded for practicing good security behavior, and are rarely called on bad behavior because it's not monitored.
I attended one of the first meetings of IT security and usability engineers at the CHI conference in Ft. Lauderdale in 2003. It was two groups of people who hadn't given the other much thought before, but we all could clearly see the value of collaborating in the future. Part of this is an organizational problem, because people aren't rewarded for practicing good security behavior, and are rarely called on bad behavior because it's not monitored.
Saturday, September 20, 2008
Upcoming workshop: Designing for Efficiency!
TriUPA in the Triangle area presents its second training session for UI and UX designers.
Dr. Deborah Mayhew, editor of “Cost-justifying usability” (among many other books) will be hosted by TriUPA on October 22nd! Register for her workshop "Designing for Efficiency" now at http://triupa.org/DesigningEfficiency
Dr. Deborah Mayhew, editor of “Cost-justifying usability” (among many other books) will be hosted by TriUPA on October 22nd! Register for her workshop "Designing for Efficiency" now at http://triupa.org/DesigningEfficiency
Sunday, September 14, 2008
Improving productivity by automating management
The book The Numerati by Stephen Baker has generated a little buzz. It's about companies' efforts to model human behavior from real data generated by web surfing, electronic communications, etc. The thing that grabbed me about this review in BusinessWeek was the line about IBM's effort to "improve productivity and automate management."
I guess we've come a long way from the days when managers got together to decide which of the company's functions were going to be outsourced, and which were going to be automated and people replaced entirely. The notion of automating the management function has a sort of visceral appeal to anyone arbitrarily replaced by a downsizing or outsourcing effort. If you're running a company just by the numbers, and attach little importance to leadership, team building, and other kinds of "soft" skills that many managers put little stock in, maybe you could "automate" management. But I doubt it.
I skimmed the Workers chapter of the book that's excerpted in this review. It's not nearly as dire as the article in BusinessWeek describes. But it's a fact that some managers latch onto tools as a means for solving some of their problems without making a committment to learning the processes and assumptions implicit in the design of the tool. Buy, install, use. And if the results aren't what you expected its a problem with the software.
So we're safe from "automated management" right now. But then I thought personality testing as a means of making hiring decisions would never go anywhere.
I guess we've come a long way from the days when managers got together to decide which of the company's functions were going to be outsourced, and which were going to be automated and people replaced entirely. The notion of automating the management function has a sort of visceral appeal to anyone arbitrarily replaced by a downsizing or outsourcing effort. If you're running a company just by the numbers, and attach little importance to leadership, team building, and other kinds of "soft" skills that many managers put little stock in, maybe you could "automate" management. But I doubt it.
I skimmed the Workers chapter of the book that's excerpted in this review. It's not nearly as dire as the article in BusinessWeek describes. But it's a fact that some managers latch onto tools as a means for solving some of their problems without making a committment to learning the processes and assumptions implicit in the design of the tool. Buy, install, use. And if the results aren't what you expected its a problem with the software.
So we're safe from "automated management" right now. But then I thought personality testing as a means of making hiring decisions would never go anywhere.
Thursday, September 11, 2008
HFES Conference in NYC
The Annual Meeting of the Human Factors and Ergonomics Society runs Sept. 22-26 in New York. I've been an HFES member for 13 years and have attended quite a few conferences. It's fun to see your old friends and meet new people, and find out what's hot in the HF field. Sorry to say I won't be there this year. Don't have the time/money for it. Next year's meeting is in San Antonio, so I'll try again to make it next year. Going to HFES in NYC? Let me know.
Saturday, September 6, 2008
Design anti-patterns: context-free design
I recently presented some training to a group of IT folks who were trying to improve the performance of an existing IVR. Completion rate was only 40%, not high enough to justify the expense of the system. The task seemed easy enough. The caller enters some identifying information, then data about amount of miles driven, fuel used, perhaps a vehicle number, all numeric.
I had started by preaching the importance of writing good scenarios - descriptions of customer behavior in the context of their environment and their tasks. Then I presented some general guidelines for designing prompts. This is harder than it appears because there are often contextual factors that make a suggested prompt worthless in a given case, so every guideline must be wrapped with disclaimers.
Back to the problem with the existing IVR. After cautiously making a few suggestions about prompting I asked the participants to back up and describe the scenario in detail. Then it became clear. The caller was a cashier standing at a check out counter talking to a driver. The driver supplied the information, who sometimes had to pull out a notebook to get the information. Two obvious problems. One, if the system is converted to speech then you'll get a lot of sidetalk recognition errors, where the caller isn't speaking directly to the IVR, but to someone else. Two, speech timeout values are by default pretty short. If you don't have the information the IVR is asking for close at hand, the IVR goes into its Silence error routines.
These are nice design issues and potentially solvable, but not unless you understand the context and the likely outcomes of the caller's behavior. In this case, not having information at hand and needing to talk to someone during the call. An expert can look pretty silly and helpless if he's offering recommendations without understanding the scenario.
I had started by preaching the importance of writing good scenarios - descriptions of customer behavior in the context of their environment and their tasks. Then I presented some general guidelines for designing prompts. This is harder than it appears because there are often contextual factors that make a suggested prompt worthless in a given case, so every guideline must be wrapped with disclaimers.
Back to the problem with the existing IVR. After cautiously making a few suggestions about prompting I asked the participants to back up and describe the scenario in detail. Then it became clear. The caller was a cashier standing at a check out counter talking to a driver. The driver supplied the information, who sometimes had to pull out a notebook to get the information. Two obvious problems. One, if the system is converted to speech then you'll get a lot of sidetalk recognition errors, where the caller isn't speaking directly to the IVR, but to someone else. Two, speech timeout values are by default pretty short. If you don't have the information the IVR is asking for close at hand, the IVR goes into its Silence error routines.
These are nice design issues and potentially solvable, but not unless you understand the context and the likely outcomes of the caller's behavior. In this case, not having information at hand and needing to talk to someone during the call. An expert can look pretty silly and helpless if he's offering recommendations without understanding the scenario.
Subscribe to:
Posts (Atom)