http://www.thehealthcareblog.com/the_health_care_blog/2008/10/an-impending-ha.html

“The other big idea is that the Web can facilitate the efficient aggregation and reformulation of knowledge and data to create new information that is not only descriptive, but prescriptive, evaluating complex situational configurations and recommending next steps based on current best knowledge and experiential data. Health care is fundamentally an information-based discipline, and the Web catapults us way beyond individual expertise to the organically evolving wisdom of mass collaboration.”

This is precisely what Gazoont does at its core.

When I called her to set up the appointment, she said, “you know, I’m not sure how much you’re going to get out of watching me. I don’t use the laptop and software on the job. I write everything down and then go back home to use it.” What she didn’t realize is that her description of her situation is actually a gold mine for people like me. The real puzzle is why it’s better to do things twice than do them once with the available tool.

In the day I spent with her, I learned a lot of detail about “real life” in a job like hers. Because realistically, when I set out to design a system for someone whose occupation is very different from mine, involving people very different from me, I can’t do a very good job unless I immerse myself in that world. Design isn’t in the details, it is the details. Those details are the difference between something people like to use, and something they leave at home.

For example, the software program she uses expects information in a linear format. You fill in a section, click next, fill in another, change tabs, and so on. But the delivery of that information, from the customer, isn’t linear at all. Part of this has to do with the fact that the customers are elderly and generally in poor health. They forget things and then “ah-hah!” they come back to them (don’t we all). The software has to be forgiving in instances like this, and right now it’s not. The domain is a fuzzy one. Things don’t always go according to plan. Anticipating these kinds of situations and handling them gracefully is essential in an effective software application.

There’s just no substitute for ethnographic research in an unfamiliar domain. Even in a familiar one, you can always learn something when you view the situation from a different perspective. Before you set out to define requirements, take a stab at understanding context. You’ll be suprised at how much that shapes the entire endeavor.

http://developer.apple.com/iphone/program/?nda

Go to article

For copy/paste:

http://tinyurl.com/6gngl4

Study: Most Children Strongly Opposed To Children’s Healthcare

I’m no Olympian but I’ve been fortunate enough to dip my toes into the pool of professional cycling. It’s both a blessing and a curse: when you reach a certain level as a female cyclist, you can compete with professionals in national events. It means you have the opportunity to race with the best, but it also means you’re not likely to win.

In my four years of competition (probably around 100 races), I’ve only won four times. Two road races and two time trials. I consider my top achievement to be an 11th place finish in a national time trial, where I competed against pros and actually beat some of them. I have been thrilled beyond belief to get 2nd, 3rd, and even 10th. Sometimes in national stage races I am thankful just to make the time cut. If people know I’ve competed in race, sometimes they will ask, “did you win?” Rarely do I get to say, “yes.”

To me, winning isn’t everything. I figure if I’m winning I should go find some better people to compete against. There are many times that something within the race (a lap led, a prime won, a rival out-sprinted, a climb conquered) is what really fuels my fire.

I’m proud of everyone who competes in the Olympics, even that guy who comes in after Michael Phelps has his goggles off, already cheering his latest gold and world record. It’s an incredible accomplishment, whether you’re first, third, or dead last.

My husband and I both use our online banking site and I doubt we’re unusual in this. But how is he supposed to remember the make of my first car (he didn’t know me then) or my favorite teacher? Luckily four of the five questions were things we would both know, but I had to pick a personal one for the fifth, and just tell him the answer.

Next I used two of my new nifty questions and answers to log in. I’m assuming that they’ll rotate with every log in. I can see all kinds of problems here. One of the answers has a hyphen in it. What if I forget to put it? Will I be able to log in? What if we move (since this question is geographically specific)? Can I change it? A favorite thing of mine has a weird spelling. What if my husband misspells it? What if our pet dies? The security questions are fraught with issues, especially because they involve the input of free text. Seems like these work a lot better on the phone.

This reminds me of a bank application problem someone described to me once. You get three tries to log in before you are “blocked out.” But someone isn’t careful with the implementation, and three erroneous tries over a period of several months leave you blocked with not much understanding of why. Ugh, bad planning!

I’m all for security but it has lots of gotchas. When I see people’s printouts of their passwords taped to their desks, I know something could have been done a little better. Maybe I should just tape a printout of our security questions and answers to the fridge, so we don’t mess up.

UPDATE:

Well, I knew it. On his first login, my husband got us locked out of the account. First, I couldn’t remember if my favorite animal was a dog or a black lab. Then he got the location of our rehearsal dinner wrong! (I do understand…could the answer be the hotel? Or the city? Or the state?). So I call the help desk, and this nice lady informs me that no, I can’t change the settings…this is all very important to keep people who want to phish my account out (no matter that I can’t get in). Then she says, “why don’t you just print the questions and answers?” Oh right, because that is so secure! Geez. :)

Recently, I finished reading Subject to Change: Creating Great Products and Services for an Uncertain World,¹ by several authors from the venerable flagship of ‘product experience, strategy and design’, Adaptive Path. One may take Subject to Change as a manifesto of sorts for the software experience/user-focused software movement (note Adaptive Path would probably object being placed in so narrow a category as ‘software’). In order to support their claims, the authors of Subject to Change rely on inductive reasoning: they describe a number of anecdotes and observations that confirm and support their theories on the value of user experience to companies and the marketplace. The problem with this approach is that it tends to obfuscate the outliers, or the exceptions to the rule (which tend to be more interesting, but, alas, are rarely considered). In his book Fooled by Randomness, Nassim Nicholas Taleb describes the problem of induction from the perspective of philosopher Karl Popper:

There are only two types of theories:

1. Theories that are known to be wrong, as they were tested and adequately rejected (he [Popper] calls them falsified).
2. Theories that have not yet been known to be wrong, not falsified yet, but are exposed to be proved wrong.²

Or, put another way: “to paraphrase baseball coach Yogi Berra again, past data has a lot of good in it, but it is the bad side that is bad”.³

One is left with the impression that the claims based on inductive logic are more absolute and immutable than they really are. The authors of Subject to Change are really saying is ‘this is what works for the majority of cases we have seen in our (necessarily) limited experience, but there is always the possibility of an exception that is completely violates that patterns we describe’ (even though they don’t explicitly put it this way). With this in mind, I would like to explore what some of the exceptions to the rule might be (Black Swans, Taleb calls them), and, more importantly, how ignoring them can actually increase the probably of a software project failing. So, what are the limits of user experience? Are there domains in the practice of designing and building software where user experience is of little value?

Earlier in my career, I worked as a software engineer for a company that builds software for storing, managing and using digital images (e.g. MRIs, CT scans, mammograms, etc.) for hospitals. In the spirit of Subject to Change, I’ll call them PacsCo.⁴ The size of these images used in a clinical environment is quite large relative to those stored, for example, on a standard consumer digital camera. Not only this, but some devices such as CT scanners take pictures of ‘slices’ of the subject, increasing the size of the data by ‘orders of magnitude’, as folks at PacsCo are found of saying. PacsCo started with this particular problem: how can all this clinical information be stored and managed reliably and securely, in such a manner as the right information gets to the other systems when it is needed? Note this fundamental question has nothing to do directly with the user, as the ‘users’ of the PacsCo software are actually other software systems! They were building a software product essentially with no user interface.⁵ The raison d’être of PacsCo was to solve a plumbing and infrastructure issue. Their salespeople never demonstrated how intuitive their user interface was. There were no user interviews to determine their tastes, as there were no users to be found that could be interviewed. All the tools of traditional user experience research—card sorting exercises, information architecture, user empathy, etc.—would have absolutely no value for PacsCo. This is an example of software that mostly interacts with other systems, not humans. When PacsCo software is working as designed, there is no need for user interaction.

Now, PacsCo was quite effective at solving this core problem. They grew and became more successful. Eventually, the decision was made to expand their product offerings into something besides just infrastructure technology, and PacsCo merged with another company that we will call ‘ImageCo’. ImageCo in many ways was the counterpoint to PacsCo: ImageCo’s software was used by clinicians to view and manipulate all these complex medical images. ImageCo provided a very valuable tool to physicians. Their software helped physicians improve the accuracy and efficiency of their diagnoses (and consequently, improved patient care). ImageCo placed extremely high value on the user experience of its software products, and saw it as a competitive advantage in a crowded marketplace. ImageCo placed most of its engineering resources on optimizing the user experience, to the neglect of almost everything else.

Once PacsCo and ImageCo became one company, the focus of the combined engineering teams initially was integrating the two companies’ product lines. It was thought that this would be a fairly quick effort—after all, the two products could already ‘talk’ to each other. As it turned out, however, this effort was not completed for well over a year. ImageCo, while having done a superior job at delivering a unique and compelling user interface, had neglected other fundamental software issues such as performance and scalability. As a result, when ImageCo was integrated in hospital environments with extremely high volumes of traffic (where PacsCo excelled), the ImageCo applications bogged down and became unresponsive. One may claim that application responsiveness is, in itself, a key component of user experience. However, as a practical matter, ImageCo applied all the ‘traditional’ approaches of user experience and still missed this. The reason was simple: ImageCo had only so many resources, all of whom were busy optimizing the experience of the clinicians with the user interface. Classic user experience techniques often focus too narrowly on user interface, aesthetics, design, etc. This risks losing the bigger picture of the software problem, which may yield the unintended consequence degrading the user experience once the product is placed in real world situations.

Am I dismissing the value of user experience altogether? Certainly not! At PointClear, we consider our entire approach to designing and building software to be infused with concern for the user and how they will interact with what we build. By exploring the boundaries of where an idea or approach starts to fail, one can achieve a more balanced view of where a methodology can add value and where it cannot. More often than not, software companies put too much emphasis on the nut of bolts of building software and neglect user experience, resulting in products that users hate. On the other hand, one can allow the pendulum to swing too far in the other direction, resulting in myopic obsession for user experience. Strangely, this too can result in software that users hate—not because of poor UI, but because it doesn’t work. And further, as we have seen, there are some domains in software where user experience simply isn’t relevant.

What is required is a balanced approach: passionate empathy for the user’s experience, vigilant concern for traditional software problems such as performance and security, and the maturity and experience to know the limits of each.

¹Peter Merholz, Todd Wilkens, Brandon Schauer, and David Verba, Subject to Change: Creating Great Products and Services for an Uncertain World. Beijing: O’Reilly, 2008.

²Nassim Nicholas Taleb, Fooled by Randomness (New York: Random House, 2005) 126.

³Taleb 126.

⁴PACS stands for ‘Picture Archiving and Communication System’. http://en.wikipedia.org/wiki/Picture_archiving_and_communication_system

⁵One might argue that there had to be some user interface—such as an administrative tool—and this is true. The key point is that the value of the user interface was dwarfed by the need to solve the fundamental question with which PacsCo started.

I’m somewhat of a political junkie, having been raised by two of them. I enjoyed watching Tim’s neutral, hard-hitting interviews on Meet the Press and his segments on the Today Show.

This morning I was watching some TV while making coffee. I caught the end of Inside the Actor’s Studio with Matt Damon. One of the questions he was asked was, “what turns you on?” Instead of giving a trite or pat answer, he said (and I paraphrase), “People who are intellectually curious.”

Matt also recounted the time when Mickey Rourke gave him a lecture about maintaining professionalism, and being courteous and punctual in his acting career.

Then I switched over to Meet the Press. I was touched by the commentary from Tim Russert’s friends and colleagues. The thing that struck me the most was his passion for what he did. He was singularly dedicated to Meet the Press, commenting on how fortunate he was to be able to prepare Monday through Friday for his show on Sunday. While his guests were sometimes not prepared, Tim always was. He was the consummate professional in his field. He lived and breathed politics, and his intellectual curiousity made him stand head and shoulders above the rest. Meet the Press changed the face of political journalism and made history.

The theme of my morning: intellectual curiosity of two remarkably professional and well-respected men.

Rest in peace, Tim Russert: 1950-2008.