Congratulations to Halo Monitoring (one of our clients) for some great press in the L.A. Times on their appearance at this year’s CES!

http://latimesblogs.latimes.com/technology/2009/01/senior-technolo.html

Very interesting article by Brian Klepper.

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.

Last week I spent some time shadowing an employee of a potential client, to understand what her work day is like, how she uses the technology she has, how it could be better, and what are some of the limits and constraints of her environment, tools, and patience dealing with it all.

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.

Apples decides to drop their NDA. Way to go Apple! Glad you listened to your developers and came to your senses.

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

Great presentation on Lee’s passion and what we do at PointClear! Congratulations, Lee!

Go to article

For copy/paste:

http://tinyurl.com/6gngl4

From this very compelling story: “When we asked them if they see universal healthcare as an unfair burden to certain taxpayers (and would they like a lollipop), almost all children said yes.”

Study: Most Children Strongly Opposed To Children’s Healthcare

I’ve been watching the olympics and enjoying it immensely, although my fingernails are now all bitten off. I’ve been struck by the commentary on the morning news stations, and also after the competition is over, and noticed that the prevailing philosophy is sometimes “gold or bust.” A silver or a bronze doesn’t seem to be something to celebrate, but instead a reason to feel disappointment. It reminds me of a favorite quip in competitive cycling (and probably other competitive sports as well): “Second place is first loser.”

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.

I just finished paying some bills online, but before I could do it, I had to go through a rigorous new security setup with my online bill pay. I had to choose an image (which doesn’t work so well in FF for Mac), name the image, and choose five security questions and answers. It seems to me as though the planning for this new level of security didn’t include any user experience research.

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. :)

I’ve been listening to “30 Days of Coldplay” on XM lately (had to ditch Sirius because of my new car, very sad) and really enjoying it. There are lots of interesting little clips about the band, the production of their latest album Viva La Vida, and their songs (who knew The Scientist had been covered by so many other artists?). One thing that made me perk up my ears the other day was a clip from Chris Martin, describing how he went about writing songs for the new album (quote courtesy of Spin magazine):

“While writing, Martin says, ‘I always think of some regular 16-year-old called Dave who’s on his bus trip to school: Is he going to want to listen to this? Last time we got so worried about who thinks this and who thinks that, and this time I’ve been really focused. On Dave. My 16-year-old imaginary friend. But not in a weird way.’”

Instead of creating something to please themselves, or their producers, Coldplay decided to try to please their fans, personified in this teenager named Dave. Having Dave as an imaginary friend gave Martin someone to think about, maybe even internally dialog with, to decide if a direction was good or needed to be tossed.

Steve Mulder, in his book The User is Always Right notes that:

“Whether you’re designing tax forms, toasters, or retirement accounts, taking time to describe who your users are and what they need can always be helpful for creating a product that will best serve them.”

The method of creating user personas was first documented by Alan Cooper in 1999 [updated edition of About Face]. They are fictitious characters that embody attributes of target users, and are used to give these otherwise abstract users a concrete form. According to Wikipedia, “a user persona is a representation of the goals and behavior of real user group. In most cases, personas are synthesized from data collected from interviews with users. They are captured in 1-2 page descriptions that include behavior patterns, goals, skills, attitudes, and environment, with a few fictional personal details to bring the persona to life. For each product, more than one persona is usually created, but one persona should always be the primary focus for the design.”

Once you create the persona of Dave, a 16-year-old music fan, you can start to talk about the music in terms of what Dave would like, or dislike. Dave helps dispell the notion that the people in the room, planning the album, know everything about what should be in it. What about Dave? What would *he* want?

I’m far from 16 years old but I like the new song. Judging from the reception from fans, Daves across the world do too.

User experience is a term often heard among those who create and use software. Though it is presented as something novel, it’s actually a pretty old concept—something considered explicitly at least since Xerox Parc—and perhaps even before that (for example, consider the obvious beauty of Babbage’s Difference Engine in the figure below). In spite of this, I am struck with what seems to be a growing buzz associated with ideas such as ‘usability’, ‘user-centered software’ and ‘passion for the user’. Microsoft and Google are gobbling up user experience engineers as fast as universities around the country can churn them out. Peers in other software shops are all playing the ‘we do usability too’ game. As things start to reach the frenetic level of ‘movement’, the skeptic looks for the snake-oil salesman hawking his miracle elixir.

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.