Modules and Wholes

transitions

2007-05-14T21:34:00.000+12:00

It has been a long while since posting on this blog. The combination of a very full schedule and a desire to take a break from the blogging routine has created a hiatus far longer than I would have anticipated. Over the past year I have been fortunate to have been involved in a long term project that goes to the very core of what user centered design is about: redesigning companies!

For any friends who have wondered about my recent movements, I can report that I will returning to the Washington DC area after an absence of 7 years. I will be much closer to many friends and professional colleagues in the States and the UK (New Zealand is just too far from everywhere), though obviously this will place me a long distance from friends I have made in New Zealand over the past 3 years.

non-executive dashboards

2006-08-01T09:58:00.000+12:00

Some follow-up to my posting last week on productive dashboards.

Interaction designers need to consider the different needs of traditional "executive" dashboards, which provide a big picture of activity throughout an enterprise, and is typically packed with minute data, and employee-centric dashboards, which reflect information relating to the activities of an individual employee or a small team they belong to.

To see what is happening in enterprise dashboards, one should consult a fantastic resource, The Dashboard Spy. Nearly all the examples posted are executive level views -- generally amalgamating and summarizing unit level data that used to be handled by Excel spreadsheets. Many these dashboards look like Excel spreadsheets. (Happily, some such as SAS/GRAPH have improved on jarring appearance of Excel's default graphics.) One would expect the mountains of data summarized, and capable of being sorted, drilled-through, and otherwise manipulated to be useful in analytical decision making such as business intelligence. If one's role is to make decisions for others, such by-the-numbers visualizations can be a powerful aid. It is still possible to drown in such data, be given so many options to manipulate it that one's never such if one's seen all the views one needs to see to make a sound decision. But executives are paid to make such decisions, and often they worry they aren't able to see things from all angles and link disparate variables. We'll defer to the brilliance of the executive to figure out what he or she needs, and not worry about the UI being too complex. On balance, access to many variables with many "degrees of freedom" to manipulate these variables is useful for executives.

Now let us consider line staff. Their job is more concerned with doing things, rather than thinking about how other entities should be doing things. This distinction is sometimes murky with the rise of self-management. As employees are often responsible for making their own decisions, it may be tempting to think they need a mini-executive dashboard. But the more the UI forces them to think about what they should be doing, the more distracted they can be from doing it.

To illustrate the employee's dilemma, let's look at a demo dashboard created by Visual I/O. Visual I/O is an exciting player in dashboards, creating visual user interfaces with impressive graphical representation and interactivity. The demo on their website concerns baseball; it is a playful illustration of interaction concepts and presentation methods they apply to more mundane subjects. They have designed a dashboard to manipulate variables to assess whether a pitcher should be replaced during a game. It reflects an extreme case of the fetish some baseball fans have for statistics!

Let's play along with the scenario, and imagine someone actually using the dashboard. While I can imagine a manager toying with the dashboard the next day at his desk, trying to figure out patterns for how to best rotate pitchers, I have trouble imagining him doing these tasks in the dugout as the game is being played. At that point, he isn't following the game, he's absorbed in the fantastically data-rich user interface. Now, let's stretch our scenario a bit and imagine that the pitcher also uses the same dashboard, which he had loaded on a PDA in his back pocket. Between pitches, he would toy with the dashboard, trying to figure out if he should ask to be relieved. The likely deterioration to his pitching concentration would present the answer, regardless of what the dashboard data suggested.

What pitchers and others involved in performing tasks need are simple heuristics to make decisions, not mountains of data. Dashboard design could learn from the field of heuristics. A useful volume on this topic, recommended by Don Norman, is Gigerenzer and Todd (eds) Simple heuristics that make us smart (Oxford, 1999.)

long tails need organization to happen

2006-07-27T09:48:00.000+12:00

Okay, I haven't yet read the best seller of the moment, The Long Tail, but I am skeptical. Lee Gomes writes in today's Wall Street Journal (subscription required) that evidence from nearly all quarters shows that the Long Tail isn't real -- people won't buy stuff just because it is there. Whether Amazon, Netflix, or the iTunes Store, most revenue comes from hits, and vast amounts of music, books, and other digital content are never downloaded at all. The same can be seen in the noncommercial world, where thousands of academic articles are never read except by their authors, and presumably, their editors and reviewers.

Like many ideas spawned by Wired magazine, the Long Tail is a vaguely libertarian notion that all anyone wants is unfettered access. Give people access, and the Tail will emerge spontaneously. The concept is argued on the basis of idealized statistical behavior and supposed transaction cost economies of data servers. From the perspective of user centered design, I find the Long Tail concept a bit naive.

Why are hits so powerful, despite the very real phenomenon that consumers have access to an ever broader range of content? The constraining factor has little to do with computers and economics, it has to do with human attention, both cognitive and psychic.

Cognitive attention is challenged the more stuff that is available. Computers have no trouble storing millions of records, but humans have trouble making sense of them. Browsing, scanning and searching are increasingly difficult the more records available. I don't want to discount the impressive progress in information architecture over the past decade, but I feel the solutions developed are still primitive compared with the needs posed by millions of records. Consider the "subject" taxonomy in Amazon's book store: it is simply too broad to be helpful in view of the millions of records. No one has developed any universally meaningful way to describe music genres that reflect the narrow-casted development of styles and approaches.

What I am calling psychic attention is grounded in the many facets of social psychology. We are drawn to things other people are buying for numerous reasons. People feel comfortable buying products that are already accepted. It is "rational" in terms of expected effort expenditure to buy something others have already tried, and presumably found useful or enjoyable. People experience social validation, extend trust, and have a basis for social connection when going for popular options. Information management has addressed the social dimension through behavioral data mining, showing connections between the purchases of different items, and through recommender systems, where people suggest items of interest, rate items, and rate each others ratings. These systems can reinforce the popularity of already strong sellers, working against the Long Tail.

There has been enormous progress in giving form to the mountains of records, but behavior and recommender systems often externalize the contradictions of individuals (especially in the low volume end of the Long Tail). Take someones "my favorite's" list: it may contain list of seemingly random items, books and CDs on unrelated topics or styles. Or people mean vastly different things by common words -- as an experiment type the word "liberal" in Amazon's Listmania. You will find recommendations for books that are far from your personal preferences (whatever they are), because people use the term in so many ways: as a positive term for either Left or Right wing politics, a derisive term for the same, as a theological orientation for various religions, etc. Sales behavior and recommendations are also not logically correlated, pointing to some gaps in behavioral classification. One Amazon reviewer noted that nearly everyone (several hundred reviewers) gave an Anti-virus software package the lowest possible rating, but it showed up as the most popular seller. A conversation with your next door neighbor might explain such a contradiction, but the user interface doesn't.

To navigate through and evaluate the long tail, people must rely on logical organization or social organization (the opinion and behavior of others). If theorists who argue that humans relate to concepts in ways similar to how they relate to people are right, then information organizations need to be smaller. You can't know everyone in a big person organization well, which is one reason organizations divide and splinter. The same may need to happen with the Superstore websites. Narrowcast marketing presumes people have a some intention behind their interest in a product, band, hobby or lifestyle. The superstores try to infer that intention by observing expressed opinions and behavior, but miss the organic aspect of collective intentions. Intentions are consciously formed, and microsites have much greater coherence in their offerings. Meaningful information management is not inherently self-organizing. When "everyone" (either the broader public or a data mining computer) tries to conceptualize and interpret the meaning of something that has resonance to a core group, the meaning gets lost.

productive dashboards

2006-07-18T12:04:00.000+12:00

In the enterprise world, dashboards are gaining prominence, though their value to employees is often more presumed than validated by evidence. Dashboards previously have been concerned mostly with so-called "C" level information (the preoccupation of top executives), things like aggregate sales or the stock price. If worker-bee employees had access to a dashboard, they saw this big picture data, as if they would be exhorted to work harder noticing the stock price fell in the morning.

New generation dashboards are now presenting data more relevant to front-line employees, particularly their KPIs (key performance indicators). The seamless corporation created by enterprise software is allowing a multitude of data indicators to be collected and presented in ways tailored to the work of individual employees. Such dashboards promise to improve measurement and awareness of activity (enabling improvement) and support long-standing goals to de-layer decision making and give more responsibility to front line staff. Dashboards have moved a big step toward relevance to employees, but few dashboards are truly user centered, because they don't address underlying user motivations.

Dashboards have received scant attention from interaction designers, and what attention that has been given tends to view dashboards as just another UI, often likened to data-rich maps. Coping with data richness is certainly an aspect of dashboards, but it can potentially focus attention of the wrong end of the user experience. The question is not necessarily how to cram more information on a dashboard, so that users can successfully discriminate between different levels and layers of information. Rather, the question may well be to make sure that the KPIs presented truly support the employee's performance. Ironically, visually rich cartographic dashboards may be distracting to employee performance, even if they present lots of data people think is relevant and even if they can be understood without difficulty. Unlike a map, where data often represents something as lifeless and impersonal has geological formations, dashboards represent data that is anything but impersonal: it reflects the incentives employees are given and how they are rated.

Dashboards are a good example of the importance of understanding user needs in context, moving beyond static understanding to explore a user's lifeworld. A recent article in the Financial Times discussed recent academic and investment research on the paradox of incentives. It notes: "It seems that incentives work well when the subject is given a repetitive, mindless task to perform, rather like the piece rates that applied in manufacturing plants. But when more thought is involved, incentives may dent performance. Our minds start to worry about the incentives, rather than the task at hand. We choke under pressure."

What research suggests is with complex knowledge work, where there are many factors mentally juggle, the more we think about multiple KPIs displayed on a dashboard, the more we are distracted from completing the task at hand. Here, our cognitive make-up collides with the business imperative to measure and monitor everything. This conflict is can be resolved different ways. Perhaps employees are being overloaded with KPIs, and so they need fewer, and therefore a simpler dashboard. Perhaps they indeed need to measure and monitor a multitude of data factors, but they should not be rated on all these factors. We could have a sophisticated dashboard of enterprise data that are not KPIs for an individual employee.

Dashboards promise to act as a window on performance, but they can influence performance as well as reflect it. Ideally employees shouldn't be thinking too much about the dashboard. Dashboards are tools that should blend into the background to support an employee's work, not be in the foreground, screaming for attention.

usability testing isn't dead, only summative testing is dead

2006-07-17T11:37:00.000+12:00

I'm hearing much about the misuse of usability testing from some big names like Don Norman, who writes in the current interactions magazine that usability testing is no more than minor activity of "catching bugs". While Norman maintains that usability testing is still necessary for clean-up purposes, he argues it shouldn't be used to "determine 'what users need'".

I have enormous respect for Norman, and love his recent contrarian views on User Centered Design, which contain many valuable insights. But on his point about user testing I think Norman is flat wrong, and out of touch with how usability testing has developed in recent years.

Norman, and a few other old-time professionals in the HCI world who I've seen be critical of user testing, reflect a dated understanding of what user testing is. They equate user testing with the bug-tallying process of summative testing, a test often done at the end of the design and development process that gives a report card on how the application works for users. Large groups of test subjects would work through uniform test protocols. In HCI, summative testing used to be holy grail of scientific respectability for the field, giving statistically measurable data on what works and what doesn't.

As a practitioner, I don't know anyone relying on summative testing to any extent-- for the very reasons Norman and others who criticize it as "too late." But there is plenty of room for usability testing to inform design -- just don't do it at the end, or try to make it scientific experiment. There is enormous confusion in the usability community because we sometimes discuss testing without being explicit whether it is old-fashion summative testing (largely a white elephant), or nimble and iterative formative testing. Both are usability testing, but formative testing is not simply about finding bugs and glitches. Formative testing can be a powerful tool for understanding user needs and preferences:

Formative user testing gives users something concrete to react to. While pre-design user research can be valuable to identify abstract user needs, concrete design alternatives provide the bridge to developing optimal solutions. You often can't know all the user requirements through pre-design research. It isn't always a matter giving a design a pass/fail rating, but exploring effectiveness of alternatives that often involve trade-offs for the user (and perhaps the sponsor organization as well.) Such formative testing is becoming increasingly common, but some people doing it seem reluctant to refer to it as usability testing (perhaps because usability testing sounds cumbersome or because formative testing isn't as rigorous as "proper" usability testing is meant to be.) Even fewer people refer to this testing as formative user testing - it is an quasi-informal activity that is never given a proper name or due status.
Users aren't idiots, and often can successfully understand and use different design alternatives, though they might not necessarily like all the alternatives equally well. A small example from my work: do users want initially to see a list of billing items in chronological or reverse-chronological order? I can ask this question orally, but get a much stronger indication of user preferences when I present alternative designs. Note that users could understand and use either one, if they were compelled to use it, but it doesn't follow they will bother to use it simply because it is usable.

It was clear to me at the recent UPA conference that formative testing needs it's own identity. User testing is no longer a topic of active research in university computer and psychology departments, as it was when Norman and other HCI pioneers crafted the academic framework from which the user centered design profession has grown. To the PhDs in HCI, the definition of user testing remains frozen in the 1980s. Even the standard textbooks on user testing date from the early 1990s, before formative testing emerged.

Formative testing has developed in the practitioner world in response to the inability of summative testing to cope with iterative design cycles. But there is no orthodoxy about how formative tests are done or evaluated. In many ways the lack of orthodoxy with formative testing has been a blessing, as it has enabled it to be responsive on projects, and grow creatively outside the straitjacket of scientific method. On the downside, because formative testing has developed on the margins of HCI orthodoxy, it hasn't received the recognition it deserves, and can be misunderstood by even big-name HCI gurus.

Many practicing UCD researchers and interaction designers consider statistical validity irrelevant to the value of testing. Testing is valuable because it offers insight, not because it offers data. User comments and stories about their behavior provide richer insights useful to design than bug-seeking data. Sometimes it is confusing how strong an insight is, or whether we know if we have uncovered all we want to. In these cases it can be useful to find new methods to evaluate robustness and completeness the qualitative data arising from formative testing, and how to work with this in an agile, iterative setting. I was pleased to see the beginning of such a discussion of formative testing at the UPA conference last month. (For example, check out the boundary-pushing work of the team at Alias/Autodesk). There is plenty to improve with current formative testing methods, but let's not throw the baby out with the the bath water.

design for motivation

2006-05-23T10:40:00.000+12:00

Why do some people put up with difficult-to-use products, while others give up quickly? Designers often dodge this question, instead putting the design in the spotlight: it either "works" or it doesn't. A design-oriented approach in effect absolves the individual of responsibility for how they get along with doing something. If users struggle, the design is too complex, or not fun, or somehow otherwise flawed in design.

Differences in user motivation are vastly under-emphasized in design research, as I realized last year when I tried, unsuccessfully, to learn to wear contact lenses at age 43. Millions of other people successfully learn to wear contacts, while I found contacts a ridiculously difficult product to use. To the extent people talk about differences in motivation to learn to use new products, it is typically done through the un-insightful language of marketing, talking about early adopters and laggards. People are "segmented" along a mythical bell curve, but we never know why they end up where they are placed.

It may seem strange to suggest that user motivation is mysterious. Major corporations spend billions of research dollars trying to unlock the secrets of what makes us want to use a product. There are plenty of solid insights on why we buy products, but we still don't really understand our relationship to products, the reasons why we choose use or not use them after purchase.

What is missing in grand approaches that confidently promise to "design compelling user experiences" is consideration of the real the differences in peoples' adoption of and adaptation to a design. The "compelling experiences" approach places the design in the role of hypnotist: an expected behavior is induced automatically and predictably by the suggestion (the design.) But we know that even with the simple behaviors commanded by the hypnotists, only a minority are susceptible to the suggestion.

Psychologists agree there are two basic types of motivation: intrinsic, and extrinsic. Intrinsic motivation relates to doing an activity for itself (no reward is offered, the activity is inherently enjoyable to the person), while extrinsic motivation relates to goals beyond those inherent in an activity, where rewards are offered as an inducement. Psychologists acknowledge that extrinsic rewards are very powerful motivations for inducing a short term behavior. But for people chasing extrinsic rewards, "compliance" worsens over the longer term when compared with intrinsically motivated individuals. Extrinsic rewards can become demotivating, offering decreasing psychic payoff over time, and also can become a distraction to doing the central task (people focus more on getting the reward than on the task itself.)

A classic intrinsically motivating activity is rock climbing. You scale up a rock, you scale down a rock, and you have nothing to show for it, unless cut hands count. Why do people bother, one might ask? And how to make make money selling to rock climbers?

Significantly, when designers look to make something more motivating, they often look to add extrinsic rewards. We can see this in gaming, where the reward is reaching a new level. Gamers often treat what level they have reached as a bragging right. The accomplishment is getting the external validation of a new level. Gamers can even try to cheat the computer with insiders' shortcuts in order to progress faster. Once the treadmill of level advancement stops, interest in game may be over.

Intrinsic motivation, in contrast, is more about enlargement of activities through self-directed choice. The role of the designer in facilitating the user's ability realize a richer, self-directed experience is that much more subtle, and the results less automatic. An example of such self-direction is what Kathy Sierra calls "superpowers": letting users do things they couldn't do before. There is a reward, but it essentially the activity itself. We are assuming users really want to do these things for their own sake, rather than to boast about having the superpower. We see how once exotic software capabilities loose their cool status once everyone can use them. Exclusivity is not an intrinsic motivator, even if makes people feel they are superpowerful. But other tools, like wikis, are truly empowering, and making them simpler and more widely accessible is part of making them more rewarding.

Intrinsic motivation is an important concept because it challenges the assumption that everyone will be interested in doing something, if only given the proper inducements. In an informal and highly motivating presentation to a UPA gathering in here Wellington yesterday, Kathy Sierra talked about the role challenge plays in motivation. Drawing on Csikszentmihalyi's flow concept, the balancing of challenge and capabilities, Kathy spoke about how much she enjoys Sudoku. There are Sudoku puzzles for all levels of ability. One can master one level, and move to the next. But it doesn't follow that everyone loves a challenge. I'm left cold by logic puzzles (reminds me too much of school) even though I can do some and am challenged by many of them. My intrinsic motivation for doing logic puzzles isn't there.

Even intrinsic motivation isn't a single value. We can have stronger or weaker intrinsic motivation, or even, quite commonly, conflicted motivation. Few pursuits are absent of trade-offs, and we often are torn by these, even if sometimes we aren't even consciously aware of what other desires undermine our commitment to a goal we are thinking about.

The table below is an attempt to estimate the effects design can have on various states of intrinsic motivation. In general the possibility that design will deflate our motivation is stronger than its potential to supercharge our motivation. As an example, an old wooden tennis racket might frustrate a novice tennis player, who might do well with a newer design that has a light carbon fiber frame and a bigger racket head. The wooden racket is demotivating, but the new racket is motivating only so far as it facilitates a feeling of minimal competence. But I don't think the improved design is causing more people to become interested in learning to play tennis, even if it is sightly easier today than it was a generation ago.

Many factors involved in a user's intrinsic motivation lie outside the scope of a design, especially where user goals are more diffuse and involve personally constructed meanings. The technique of laddering, successively asking "why?" in response to personal to statements about goals, can reveal that the correspondence between user tasks and broader life goals is rather tangled. A product may contribute to a one goal, but is often not sufficient in itself to achieving that goal. At the same time, the product might even detract from other goals, by consuming time, money or emotional energy. With things so complex, it is small wonder that designers focus on the external rewards of a design -- promising popularity or prestige.

un-compelling

2006-05-16T10:00:00.000+12:00

A certain fatigue sets in when the ear repeatedly hears something artificial, and the brain keeps trying to interpret it.

I'm tired of the phrase "compelling" used to describe interaction. It isn't simply a overworked cliche, it is perversion of reality. I hear so many people in the user research and design space talk about designing "compelling user experiences," but I never hear actual users talk about wanting "compelling" experiences. They talk about finding interfaces as fun, or interesting, or useful, but not "compelling." To speak of something as fun is to speak of it from a natural ego-centric perspective: I have fun. To speak of something as compelling is to speak of it from object-centric perspective: I am compelled, by forces beyond my control.

My wariness is not simply a philosophical quibble. All this hype about compelling user experiences sounds like mindless corporate propaganda. Researchers and designers sound like zombies when talking about compelling experiences, and make users sound like zombies too. Let's strike the word from our speech, please.

customers, users and agile software

2006-05-11T17:32:00.000+12:00

In an effort to become less ignorant of agile software approaches, I recently listened to a podcast with Alistair Cockburn on the topic. What agile seems to do well is get users involved in the shaping of the functionality of a system. It can do this by offering a tangible prototype for users to react to. Too often, functionality is shaped entirely by business requirements documents, which are at a very high level. Specific functional requirements that users might need can be overlooked in less iterative processes that emphasize development of high level functional requirements, and if these needs are uncovered later in the process, they can be hard to "bolt on."

The podcast also sheds light on how agile approaches conceive of customers. Agile is indeed "customer focused", but customers are not entirely the same as what usability professionals refer to as users. Cockburn speaks of customer collaboration over customer negotiation. I wholeheartedly support these sentiments, which are good business practice, as well as good design practice. But usability professionals would never speak about "user collaboration over user negotiation." Customers -- who include people who buy/commission software -- aren't necessarily users, and the terms customer and user cannot be used interchangeably. So talking about customers, who Cockburn sees as being both "sponsors and end users", can sometimes obscure distinctions usability professionals would make between different end user profiles (abilities, attitudes, environments, etc.). Even if all end users have the same basic functional requirements (what the system does), it does not follow they have the same user requirements (the way the system needs to do it to meet user needs.)

The central tenet of usability is to test with a representative user population. Here I think usability testing and agile functional testing have widely different approaches. I have suspected that agile approaches lack the thoroughness of usability in seeking wide participation of users in the process, because the needs of functional testing (find functional limitations) are fundamentally different from usability testing (find interaction limitations.) Usability professionals, even when using lightweight "discount" approaches, might need to test 5 people to get meaningful understanding of interaction issues and problems that need refinement. Cockburn sees a successful "access to a customer" under an agile scenario as being an "hour or two" a week -- considerably shorter than usability approaches, and probably not involving as many individuals either. He also emphasizes the importance of access to "expert users." Experts are indeed useful for functional specifications, but not necessarily ideal for determining user requirements.

For those of us in the usability community, the podcast highlights some of the attitudes of the agile orientation, particularly the aversion to "process heavy" approaches. Notwithstanding the debate and diversity in the agile development community, agile developers generally embrace methodological minimalism and skepticism toward formalism, for example, asking for a justification of the value of non-code related activities such as documentation. Within agile, there is lively discussion over which activities are essential and which ones aren't. It remains to be seen if agile software developers will consider user centered design as another "process heavy" activity.

talking usability in the meeting room

2006-05-04T10:58:00.000+12:00

"We need to get a decision about this -- I'll book a meeting so we can get resolution on it."

In business, meetings are where action happens, where information is disclosed and debated and decisions are made. Meetings allow many parties to be involved in discussion and decisions more efficiently than one-on-one discussions, or (in many cases) group emails. Business culture gripes about the time meetings take (often simply a sign that people are too busy generally), adding to the pressure to make meetings productive. A meeting is not successful unless issues are closed out, and next steps agreed that are substantively different from what had been discussed at the current meeting. Employees are drilled in this culture, taking courses on running meetings, and being effective participants in them. Meeting attendees who don't follow the code of conduct are admonished in front of their colleagues.

The culture of efficient business meetings doesn't transplant well to issues involving design and user needs. Because meetings are so deeply ingrained into the corporate mindset, organizations often view meetings as the best way to make decisions about the usability of designs. Although meetings have their place in a user centered design process, they can equally hinder a user centered solution.

A standard organizational behavior is to call a meeting to get "resolution" about an issue. If we aren't sure how to design something, let's call a meeting to get resolution on it. The assumption is that if you get a cross sample of stakeholders in a room together, they can have a rational discussion and get a decision then and there. What also is assumed, sometimes without full consideration, is that everyone involved in the discussion has adequate knowledge and information to make a good decision.

The more finely-tuned the meeting process, the less obvious that meeting participants may not have sufficient information to decide usability issues. A carefully considered invitation list, a well structured agenda, and PowerPoint slides can give the appearance that decisions can be made. For many business issues this is in fact possible -- participants have top-of-the-head knowledge necessary to respond to topics that arise in the meeting, so decisions can be made then. But for usability-related issues, top-of-the-head knowledge of general business participants is generally inadequate (this would not necessarily be an issue if we are talking about a more specialized group meeting, such as an in-house design team.) The stakeholders at decision-related meetings are generally not the same people who will be using a system, and are not the right people to comment on user needs. And users aren't the right people to make final design decisions. Research and decision making are separate activities.

Some consultants have tried to adapt usability techniques to fit corporate meeting rituals, but I question the quality of information such techniques develop. The temptation is to borrow techniques familiar to corporate employees taken from decision making and training workshops, such as voting or role playing, and use them as the basis for making decisions about designs. One evaluation technique I have seen discussed involves a set of rules for different participants to pretend they were different kinds of users. The participants have to fill out worksheets, follow participation rules, then make decisions based on what they saw in the role play. I can imagine that participants, committed to doing a good job and spending effort to follow the process faithfully, would believe they are accomplishing something valuable at such a meeting. But we can't expect Hal in marketing to know how a customer who lives or works in very different circumstances will behave. People struggle enough trying to recall how they do their own work on computers when they aren't sitting down in front of one. Getting a surrogate to imagine how a mythical user does a task strains credibility even more.

So when are meetings useful in user centered design? In general, meetings are useful in the beginning, at the end, but not in the middle of design research. In the beginning, meetings can be useful to explore issues early. At this point, we aren't making design decisions, we are just trying to get a picture of what issues might need detailed consideration, so top-of-the-head comments are useful. We'll verify this information later through contextual or behavioral research, or user testing. Research needs to be done outside of a meeting setting. Group workshops are fine, since unlike meetings their purpose is simply to elicit user data, not to make decisions. At the end of of a design research phase, we have some results to report at a meeting, which can provide a basis for decisions about next steps.

The pressure will always be on for instant answers to allow quick decisions. The seduction of meetings is that they collapse the answer and decision making processes, which need to be separate activities in usability. Business people are accustomed, once showing up at a meeting, to be rewarded with a decision at the conclusion. It is therefore vital to emphasize the difference between a workshop and a meeting, and not to agree to meetings unless there is sufficient user data to make design decisions.

But in addition to knowing what is not appropriate about meetings in usability, we need to be appreciate why meetings are attractive to business people, and address the underlying needs that make them attractive. By combining discussion (the offering and analysis of information) with decision making, meetings can be fast, and they make clear the connections between the data with decisions. This suggests we need to work to make data gathering and analysis as quick and clear as possible, to make make data responsive to decision making (gathering data to address the agenda of a scheduled meeting) and transparent (decisions reflect data that was widely understood by decision makers.) These aren't new goals, but there's still plenty of room left for improvement.

task oriented information architecture

2006-05-03T11:53:00.000+12:00

Most discussion of information architecture relates to finding information. There are articles people want to read, or catalog items people want to browse. What receives less attention in information architecture is how to organize user interfaces to perform tasks, particularly tasks involving complex, drawn-out processes. After recently working on an enterprise application, I have concluded that task-oriented information architecture involves unique issues.

One thing that makes task oriented information architecture a challenge is that it can be difficult to develop a solid understanding how users do their tasks, particularly if there is a lot of task variety. Consider the diagram below.

In creating an IA, the central question whether to organize screens around "objects" (concrete entities such as customers, or products) and then have screens relating to subordinate processes coming off each object. For example, first locate object 1, then do process 1 for object 1, then process 2, etc. Or, is the best way to organize screens first around processes, then have subordinate screens relating to object available while in the mist of a process?

For a one-off task, the question can be answered fairly easily. One can structure the task so that there is only one object and several process steps. Or less commonly, we force a process, and processing of all objects must be done at the same time. If you have more than one object or more than one process in these cases, you need to repeat the whole cycle.

A task oriented IA becomes much more complicated when you don't know in advance how many objects or processes might be involved. For example, if the IA needed to address the processing of travel-related information, we might need a certain elasticity in the IA to accommodate different scenarios. Some people will travel individually, others in groups (with several customers doing the same thing.) Some people will have accounts involving several trips. Customer representatives may need to process numerous items of unrelated customers at the same time. We don't know how many separate products (tickets, hotels) will be associated with any single travel journey. Groups may start with the same itinerary, so that doing processes together makes sense, but the group may break apart after a conference ends and then have separate itineraries. While my IA experience was not related to travel (I've tried to choose an example that might be easier to understand than what I worked on), I hope these examples give a flavor of some of the kinds of issues that can arise.

My experience suggests that traditional card sorting methods are not ideal for task oriented IA. The reason is that labels are often not meaningful outside a scenario. What makes sense when there is just one customer makes less sense when there is a group of customers. For scenarios to be really useful, one needs to cover off all the likely scenarios, not just the major ones.

When experimenting with task-oriented IA, here are some issues to keep in mind:

Activity structure. Are tasks batched around a group of items, or around a sequence of events? Interestingly, the same mix of objects and processes may be done in different ways, depending on who is doing the work, and what the context is. How a customer representative processes a form will be different depending if the customer dropped in his local branch to deliver it, or whether it was mailed in and is sitting on a stack with other people's forms.
Inputs. How is information received and entered? Does it come in a clump, or in dribbles? Are inputs calendar-driven, so you can predict when you will receive them, or can they arrive at any time?
Time dimension. Are tasks done in parallel on the same timeline, or do they go on divergent timelines? Are sequences of activities fixed or flexible? Sometimes activities start at the same time, and get processes concurrently, though the services themselves involve different durations.

user testing and agile methods

2006-05-02T14:09:00.000+12:00

I'm looking forward to discussion at next month's UPA conference on incorporating usability into agile software development methods (BTW: if you'll be in Denver and would like to meet up, drop me a line.)

One key question that needs a good discussion is how much user testing is needed in an agile development. How much testing is enough? Is testing always necessary?

These questions may seem to be a matter of opinion at the moment, but there is no reason why the usability community can't work to develop some data to answer these questions concretely.

At least one prominent advocate of agile usability believes that traditional user centered design methods involve an over-reliance on user testing.

I am concerned that agile software development can result in an under-reliance on user testing. By under-reliance, I mean that flaws in software design that affect users go undetected because they weren't tested during the development process.

While I am interested in agile methods, I can't claim special expertise. Insofar as I understand agile usability approaches, there is no unified approach people commonly follow. There have been some process-oriented methods that have been developed, as well as numerous improvisational attempts to find a balance that works. From what I have gleaned, these different approaches have not been explicit on how much user testing to conduct, and under what circumstances to conduct it, and at what point to conduct it. Some have suggested that successful results are possible with agile methods with less reliance on less user testing, because the design process is more robust, so problems are resolved before users ever see them. Others don't make this claim, though they admit that agile methods typically involve less user testing simply because the timelines and project structure limit the testing element.

What the usability community needs to know is whether doing a more light-weight version of user testing under an agile process is a net benefit, or simply a sacrifice to accommodate usability to the agile framework. Obviously, if there is no need for extensive usability testing in an agile process, and quality for users is as good as if more extensive testing was done, this is a big positive.

I'd like to see some comparisons of agile processes with limited user testing, compared with more extensive user testing. If agile methods can result in better designs that need little user testing, there will be few changes to the original design as a result of user testing. We would also expect that a very small sample of users would be adequate to catch any issues, so that larger numbers of test subjects would yield no new information. Once changes have been made to the design following the first round of user tests, any subsequent test would yield no further information. After one iteration, making any changes to the design would be superfluous.

Usability has a strong empirical tradition, where we look at and debate topics vital to our effectiveness, such as how many test subjects is optimal. Perhaps we can start developing some data about the effectiveness of testing with agile methods. We need to move beyond talking about over-reliance and under-reliance of user testing without clear definitions of criteria, and concrete data measuring the achievement of these criteria.

what design can learn from health research

2006-04-30T17:37:00.000+12:00

Interdisciplinary teams can offer more perspectives on an issue, and more insights for creating a design. Fortunately the culture wars between "creatives" and usability engineers during the dom.com era are mostly forgotten now. But tensions remain below the surface, and interdisciplinary teams often involve more horse trading than a single collective understanding. The reason for this is that true interdisciplinary research involves acknowledging what one doesn't have an answer to.

I was recently reading a book on health research and recognized some of the same kinds of alternative attitudes that affect the design community. To simplify, there are two camps: the "holists", who see health as a difficult-to-articulate but complex interaction of mental, social and physical processes; and the "hard scientists" who believe only in hard data that is unambiguous. The holists deride the hard scientists for narrow-minded "reductionism," while the hard scientists dismiss the holists as given to woolly-minded New Age thinking.

What seems to be happening in at least some health research is the formation of real interdisciplinary research. Whereas previously anthropologists and immunologists both studied disease, they did so independently, without consulting the other's work. Now it is common for social and behavioral scientists to work together with biological scientists to study the interplay of biological and non-biological factors on a certain health issue. The upshot is that the biologists often find that the reality is more complex than previously thought, that strict genetic and biological factors don't explain certain variations. The non-biologists also find the reality more complex as well, that folk wisdom is only partly accurate, or that their intuitions about the behavioral side of health effects cannot easily be generalized the wider population.

In the design world, creatives worry about the reductionism of usability missing the big picture. Usability engineers worry the loosey-goosey decision making of creatives plays roulette with design. What interdisciplinary design can highlight, and attempt to overcome, are the limitation of both the intuitive and data-driven approaches. Intuitives can recognize many patterns in "soft data" that are difficult for hard data methods to find. Hard data can miss nuances because it is too aggregated, or looking at an irrelevant or lagging variable. But intuitive insights can be wrong as well, either over-generalizing, or even becoming a false dogma because they sound like common sense when the reality is counter-intuitive.

Personally, I look forward to interdisciplinary design opening up thinking for all people involved in interaction design. Too much faith is placed in best practice rules and methods, or data collection and decomposition. Too much hope is placed on inspiration as the divine source of good design.

hotel patrons: users and customers

2006-04-29T10:48:00.000+12:00

I'm back from a week's stay at a "deluxe" hotel in Sydney, right in the financial district. Very nice place, full of smiling staff and polished marble. The hotel even boasted it was voted one of the top 25 hotels in the Asia-Pacific. Clearly, customer experience is a paramount concern for this hotel.

But for all the concern about customer experience, there seemed to be little concern for user experience. On arriving, I looked around for the standard hotel portfolio binder explaining available services, when they were accessible and what the charges were. Unable to find such a binder, I then noticed the serious looking remote control by the television, and thought "this information must be all online." I turned on the television and started surfing. It seemed a struggle to by-pass the pay-for-view movie selections. I couldn't figure how to go back, when while looking for the hotel information I got sucked into various infomercials touting the hotel chain's other hotels in faraway places. After a seemingly random traversal through unrelated screens and meaningless menu option labels, the only piece of hotel-related information I discovered were stern instructions on what to do in case of a fire. Not exactly where I would expect to look for that information, though happily the hotel marble was not ablaze.

We had to ring the concierge to get the information sought, but it wasn't simple either. There are two reasons I'd rather be a "user" dealing with an interactive device, rather than a "customer" dealing with human. First, the human encounter requires certain nice formalities that can be irrelevant to the task at hand, such as when the well-trained hotel staff solicitously enquire how I'm enjoying my stay, even though I've just arrived and am simply trying to get some information. Second, it can sometimes be difficult to articulate what you want; it is easier to scan for and recognize it. The conversation about the folder/binder thing with hotel information (do these things have a name?) did not quickly result in required information. The staff keep asking what information exactly we wanted, while what we wanted was general information we might want to know once we were aware of it. Our ever-attentive hotel staff attempted to satisfy us by giving as the hotel's corporate newsletter, which didn't have any information relevant to us at all. The confusion was finally resolved when the hotel staff realized that we didn't have the mysterious binder of information in our room as it should be. There was a binder, it had the information what we wanted, it just wasn't in our room.

The incident was hardly traumatic, but it was amusing, considering the enormous stock hotels place in addressing the customer experience. While my Sydney hotel focused on the personal touch, it had a klutzy interactive TV that took several minutes to download the balance on one's room charges.

Hotels can ironically misunderstand to the needs of their patrons on account of their people-orientated systems of delivering services. I don't mean to suggest that patrons don't want personal attention for such matters as getting restaurant recommendations and bookings, or theater tickets. But people, apart from the desperately lonely, don't want all encounters to be personal, and hotels don't recognize this.

Labor economist Robert Reich notes he prefers ATMs to bank tellers. He admits what many feel deep down: "I'd prefer to save my scarce social energies for more important encounters." I think some hotel functions fall in the same category. But while ATMs are famous for being simple to use, hotel IT services lack such distinction. Some hotels have embraced wireless technology, but many, including big name outfits in major global business centers, haven't even grasped the importance of having user-friendly information technology available for patrons. Far too many punish patrons for wanting IT access, viewing it as just another way to gouge customers. Hotel business center fees can make the hotel spa services look like a bargain in comparison. My Sydney hotel charged A$36 an hour for internet access. As far as I'm concerned, that's like charging $36 for a newspaper.

monster mash: the opportunity and its problems

2006-04-06T20:30:00.000+12:00

Seems I am reading more and more about "mashed" applications: amalgamations of different applications, wrapped together by a savvy integrator. The concept isn't new, though it has recently become common, and seems posed to explode. Developments in software are allowing easier integration of modules designed by different parties: often parties who would never have imagined their respective children playing together. It can result in marvelous creative fusion, but also poses some unique challenges for the user experience.

Mashed applications bring "hacks" (web APIs, RSS syndication) to the masses. Before recently, integration has been difficult. In a recently completed dissertation, Mika Myller writes: "the challenging usability problem of digital environment of everyday life is that people are forced to act as 'systems integrator'. However, from our point of view the problem is not that people have to integrate products but that they cannot or they have to 'integrate' the products most of the time they are using them because there are not enough possibilities (e.g. open interfaces) for people or third parties easily to compose independent products to systems of systems."

Mashed applications empower individuals by integrating different knowledge, sometimes in ways not imagined. Fantastic. But such a concoction can have a life of its own, and without supervision, cause confusion and disappointment.

Panayiotis Periorellis notes that mash applications, known formally as a "system of systems," can be unstable. Consider the case of the travel website, which brings together hotel, airline and insurance offerings. One can integrate systems from different sources, but the goals of these sources are different, and can potentially change without notice. Something as simple as the length of notice to cancel a reservation can differ. From the users' point of view, they are dealing with a single entity, the travel website, and expect a predictable and uniform experience. But the single entity can be a mirage.

I expect the usability issues arising from systems of systems will become increasingly important in the future. Mashed applications offer a lot, but will need to deliver what they promise.

remote UCD and the offshore factor

2006-04-02T09:44:00.000+12:00

Looking over the latest CHI Interactions on Offshoring, I ask myself: Is usability about people, or data and specifications? That is the perhaps the central question when looking at how global outsourcing might affect usability over the next five or ten years.

Princeton economist Alan Blinder believes the only jobs immune from offshoring are those where hands-on or face-to-face contact is essential. Many standardized jobs can nearly as easily be done offshore by people following detailed predictable procedures. Onshore jobs will be "in the delivery of services where personal presence is either imperative or highly beneficial. Thus, the U.S. workforce of the future will likely have more divorce lawyers and fewer attorneys who write routine contracts." (see, for example, Will Your Job Survive?)

If one sees usability primarily has the collection and analysis of quantifiable data on user behavior, outsourcing these tasks seems possible, given adequate infrastructure. There are numerous firms selling click stream solutions to track user behavior, and VPN technologies are sure to improve to allow better self-administered user tests. There are even a few companies developing remote elicitation tools to collect data on user wants or mental models, to provide some raw data to shape new designs.

For "mature" user interfaces, where a system of specifications has been defined extensively, offshore designers can design variants without problem. Modularity in UIs is good design practice, and makes it easy for third parties to create new UIs consistent with existing ones.

There are inexorable pressures on user interface design to develop practices that yield more predictability, reusability, and speed to the production of user interfaces. These pressures are driving the creation of in-house corporate, and industry-wide standards. And standards are the lifeblood of the outsourcing industry. If a process can be standardized, it can be outsourced.

Despite the pressures to define standards, there are many, many things about UI design that remain, and will likely remain, messy. Usability professions are like divorce lawyers, and UCD practitioners like psychotherapists soothing the traumatized divorcee. People a want to be happy, and formulaic standardized responses will not offer them the satisfaction they seek to embark on a new, happier life with a new technology.

Telecommunications doesn't seem likely to displace the face-to-face communication needed to understand the why of an issue. Self administered questionnaires and remote discussions are hardly a robust source for insight. Innovation is a counterbalance to standardization. Innovation can be augmented by telecommunications, but face-to-face discussion seems vital.

While I fully expect an offshore aspect to UCD to develop, I also believe that context is too crucial for offshore usability to become a full fledged alternative to onsite usability.

help! usability in need of information architecture

2006-03-04T20:23:00.000+13:00

For a number of months I have been involved in a project designing user interfaces for new banking system. A big challenge has been to develop a design language to handle diverse processes, such that patterns can be standardized (and hence learnable), while also being flexible enough to handle very complex, and ad hoc, situations.

I have been mining the Internet for UI examples to leverage from. As I have sought every last permutation of UI design patterns, looking for the best ideas for my project, I have been struck by how inconsistent professionals in the UI design world are in the terms they use to describe widgets.

If anyone should understand the value of consistent, meaningful information architecture, it should be UI designers. But I find little evidence they do, at least when it comes to the terms they use to discuss widgets. You might recognize the widget when you see it, but try to Google it. What term do you use?

We don't even have a standard term for a drop-down list (a pick list? drop box?) What is a list box? Can it include tick boxes (check boxes)?

Some of these terminology issues are legacies of Microsoft verses Apple. The widget terminology wars continue, especially as new widgets are created in the Rich Internet world, and their authors seek to give these subtle variations special names. Is the toggle in a
Windows dialog box the same as an Ajax show/hide toggle? Or the status bar of a web app the same as the task bar of a client application?

I don't want binding advice, but would appreciate some movement to development of a consensus.

having something to format

2006-02-21T21:49:00.000+13:00

Multimedia is the poster child of software development. We seem obsessed with making media "richer": adding interactive graphics, data visualization, video, sound, ticker tape updates and entertainment like controls. Apart from some not terrible useful efforts in "experimental typography," old fashion words seem to get ignored.

Most text-related software seems devoted to navigating text, extracting concepts from text, and perhaps extracting snippets of text into an information manager. However, there seems little attention these days relating to tools to create text documents. I find this situation unsatisfying, as I believe existing text creation tools are wanting.

Microsoft Word does many things, but it does not necessarily do all of them well. Every competitor I've seen simply tries to copy Word, not to better it. Word experienced some genuine innovation in the 1990s, adding features like auto summary, but it has been stagnant since then.

One of the worst features of Word is its outlining capabilities. In the DOS era, there were several outlining programs that were interesting, but they never gained viability with Windows, as Word came to dominate word processing. Word's outlining is a basic hide-and-show hierarchy, a clumsy one at that. There are many other possibilities for outlining.

I like the some features of the Mac-based OmniOutliner program, particularly adding columns such as tick boxes and numeric fields, as exist with a spreadsheet. But OmniOutliner remains a hide-and-show program.

The most interesting outlining program I have found is designed for lawyers. Developed by CaseSoft, NoteMap has several nifty features. It allows gathering non-contiguous items, and putting them in another branch of the outline. This is very useful for connecting thoughts that have not thus far been related to each other. NoteMap has better annotation and formatting capabilities than many outliners, plus a basic sort facility (though more could be done with the sort.) But more important than its features, it offers smooth performance, where Word feels shaky.

It seems strange to me that something as basic as outlining receives so little attention in word processors. Too much attention in word processors is placed on formatting, and not enough on how users draft their thoughts.

the shrinking world of customized software

2006-02-13T17:54:00.000+13:00

What has become of customized software -- software designed to an organization's or group's unique needs? I have previously argued that the shift from custom built to off-the-shelf software has largely sidelined traditional user centered design approaches premised on bottom-up design. I am coming to realize bottom-up design is under more pressure than ever, thanks to the rise of "on demand" web applications.

Businesses have largely given up on customized software, because they deem it too expensive. They switched to homogeneous off-the-shelf software, with ready-made interchangeable components. Much of this software was sold as kits, which would get a modest customization done by a systems integration house. The integrators made far more money than the kit vendors. Various forms of software customization and service could represent $7 for every $1 spent on the actual software license. Add to that the aggravating "plumbing" problems that the systems integrators seemed to find, and often never completely manage, corporate customers have sought greater simplicity from their software spending.

Vendors have responded with "on-demand" software solutions delivered over the web. No need to hire a systems integrator, we'll give you a complete package that meets all your needs, vendors promise. A good example is Salesforce.com, which offers a "customer relationship management" (CRM) system remotely delivered via the web. The solution is cheaper for the customer, and simpler too. Who could complain about that?

The drive to reduce costs and complexity is understandable. But businesses are often suckered by the myopic logic of software vendors, especially the new web application vendors. They speak of "cost of ownership", but restrict their definition of costs to only those items that appear in the IT budget. Now, IT budgets are considerable, but they generally aren't the predominant expense in service companies: employees are. How IT costs affect labor productivity are never addressed.

On-demand software pretends that business processes are so uniform and standard that you don't need to customize anything. Unfortunately, things are a bit more complicated than that.

If any business process could be successfully supported by uncustomized software it ought to be CRM. Sales is hardly a intellectually complex activity. But CRM has been a big failure, even after three generations of trying to get it right. I recently read a roundtable discussion by CRM vendors and IT analysts , and all admitted usability is still a massive problem. Sales people don't feel CRM supports their needs -- it is just a monitoring tool for the benefit of management.

Selling involves personal style, something one-size-fits-all software doesn't accommodate well. Forcing users to follow a set of rigid procedures doesn't translate into helping them make more sales.

What companies need is the ability to customize -- in a meaningful way. Yes customization was expensive and fraught with technical glitches. But the problem wasn't the concept of customization, but rather what was required to achieve customization. Too much focus and energy went into solving plumbing problems, not user problems.

On-demand vendors need to offer easy to use tools to allow customization of their offering. This customization needs to be fundamental, not cosmetic. Real customization isn't just about the UI, it is about the process of using the application in conjunction with one's daily work. Understanding real uses processes is gained through contextual research across a range of potential users. One size doesn't work. The task is to learn just how many different sizes are needed.

innate and learned interactive behaviors

2006-02-07T18:30:00.000+13:00

The gold standard for social science is research that is non-trivial, non-obvious, and widely repeatable. User research sometimes yields seismic discoveries, but small discoveries -- or even ambiguous ones -- are more the norm. But it would be wrong to conclude that because everyday user research yields only mundane discoveries, we know the major things we need to know, or that pedestrian user research simply isn't worth the effort.

Okay, few people are so bold as to argue user research is counterproductive. But the concept of user research as a routine aspect of usable design is being questioned from many quarters, with alternative concepts sometimes promoted as being more time- or cost- effective. I see three often mooted ideas that can imply routine, classic empirical user research isn't necessary. One is that smart consultants already know the answers -- only dumb ones don't. Another is that there are newer, better theories that deliver the answers. The third is that there are better methods to deliver the answers.

The first skepticism toward user research I will call "charismatic usability."Advisors and consultants can take so much satisfaction in what they know, they can loose sight of what they don't know. With usability charismatics, attention shifts from the credibility of the conclusion to the "credibility" of the messenger. Perhaps the consultant has secret knowledge, gained through previous work with very select clients, that is not known in the wider usability community. We also see this fantasy played out in scenarios imaging that "user experience" evangelism will storm the board room and become the pet interest of the CEO. Charismatic messages appeal to individuals and organizations in crisis, and charismatic seekers admit a desperation, as well analyzed by Harvard business professor Rakesh Khurana in Searching for a Corporate Savior: the Irrational Quest for Charismatic CEOs. The lovefest is often disappointing, with the charismatic expert over-promising, and under-delivering, a solution to a problem that is bigger than any single personality can solve. Because you can convenience a client she has a problem doesn't necessarily endow you with the capability to solve it.

Other people doubt user centered design, which dates from the 1980s, is still a viable theory and believe needs to be replaced with something newer. Some would believe a more complex theory is what is needed, perhaps activity theory. As a theory, UCD has never been coherent, and traditional cognitive science approaches don't offer many answers sought. . While activity theory involves user research, it seems to have priorities reversed: in AT, theory drives user research, instead of user research driving development of theory. Like most Marxist-derived "theory", AT is not really a theory that can be proven, but a simply framework that guides one's focus of attention, for better or worse. How much value can be found by deciphering impenetrable jargon about the "zone of proximical development" or Hegelian dialectics, is open to question. Researchers get excited by the phenomenology of artifact-mediated activities -- say, how office workers use a magnetic white board -- while in offices across the globe, artifacts themselves are disappearing into the ether. There is less and less physical manipulation to watch and theorize about. Theory isn't always in sync with is happening on the ground.

Another approach might be called the "re-engineering" of usability: obliterate all the unnecessary steps. Some imagine that definitive answers can be found "agilely" through quick polling techniques: just ask a few people, and your problem dissolves. So-called "discount usability" -- a concept that has merit when used judiciously -- is rapidly degenerating into a wholesale dumping-down of usability. The technique of testing five people -- plausible only under highly understood circumstances -- has collapsed into testing "3-5" people, soon to be "1-5" people, promising answers to all questions, irrespective of how facets are associated with the problem.

If user research, which for me includes old-fashioned usability testing, is losing its mojo, how far we can rely on our pre-existing knowledge of users? To simplify, I propose we consider user behaviors of two kinds: innate behaviors, and learned behaviors. Both are valuable, but both are limited, for different reasons.

Innate behaviors are essentially biological in character. Classical ergonomics, focused on the physical dimension of activity, looks at innate behavior: how easily people can grip a knob, or point a mouse. Innate behavior exists in the mental realm as well: the psychology of perception describes innate behaviors. Memory and attention functions are often innate, more a function of intrinsic capabilities than previous experiences. Generally speaking, people vary in their innate behavior by degree of ability, rather than by kind of ability (the obvious exception is for persons with a disability -- lacking an ability that exists in the general population. ) If there are wide differences in a behavior, such that some people can be successful accomplishing a task while other cannot, it seems unlikely the behavior is innate (an exception being if the performance required, or the person involved, is at one or the other end of a bell curve distribution.)

Ergonomics and empirical cognitive science focus extensively on innate behavior. It is important to recognize that the numbers of behaviors that are innate is small in comparison to all observable human behavior. Still, these behaviors are often fundamental, and there is plenty to be learned about them. What is most interesting about innate behaviors is understanding the range of performance, especially the upper limits of what people can do. I am very excited by recent work in the field of "cognitive systems engineering" looking at information overload. This research is greatly extending, and qualifying, research from half a century ago on short term memory. Information overload is one of the most vital issues confronting design today, but we are only just starting to understand its complex dynamics, outside simple lab experiments.

Designers can utilize findings on innate user behaviors knowing that if they were to do their own user tests, it would yield no new information. Unfortunately, the findings are sometimes not as useful as needed. The general finding may be valid, but the data does not address one's user group in adequate detail. Even basic anthropometric data is sometimes not available for certain population subgroups. Other times the finding does not fit the design problem appropriately: it is too general to predict how people would behave in a given circumstance, or the finding, while appearing robust (it has been repeated), has not be demonstrated with sufficiently diverse user groups and contexts to merit being considered a universal, innate behavior (the problem of how innate are behaviors of university psychology students). Truth is, studies on innate behavior are only of limited use to designers. Most design questions are not answered by data on innate human performance.

Other user behavior is not biological but learned. This distinction is not clear cut, because one can learn to improve one's performance of an innate behavior. The general population is able to remember facts (an innate ability), though it may be possible to improve one's recall of facts through training or techniques (a learned ability.) Learning effects exist for both physical and mental performance. But a more serious problem is to act as if a learned behavior as innate one.

Most HCI research addresses learned behaviors, even though it generally fails to stipulate that limitation. HCI research tends to report its results categorically, as in "subjects behaved" in such and such a manner, with very limited discussion of historical, contextual and conditional factors relating to the subjects. (We may simply learn that subjects were heavy Internet users and average 22 years of age. Sometimes we learn more about the computer equipment used in the experiment, which is often thoroughly dissected.) Sometimes we find cryptic findings in the HCI literature, stating some tentative finding about a highly particular, even artificial, activity, with recommendations that further study be considered (and sometimes only the investigator is sufficiently interested in the problem to do the further investigation.) Practitioners -- people who need to design things -- often can't use such information to any extent. Even with these limitations, HCI research is valuable, not least because it tracks what we don't know, and nudges us to learn more about it. Much HCI research consciously focuses on novel technologies we know little about. There are benefits of knowledge for knowledge's sake, and all practitioners owe their academic colleagues our appreciation for investigating areas that don't have an obvious payoff. But exploratory research, especially involving bespoke and idiosyncratic design configurations, is difficult to generalize from.

Two things are vexing about learned behaviors. First, the practicality of applying any finding about learned behavior is difficult, since the finding is highly susceptible to what user population you have studied. Just because you found a strong user behavior among American college students doesn't mean you will find the same behavior with middle age Americans, or Egyptian college students, or some other user group. Second, learned behaviors change. People learn new behaviors, and old ones fall in disfavor. What is take as gospel about the Web today will become idiosyncratic once Web 2.0 (or whatever is ultimately becomes known as) gains currency.

Much of our knowledge about users is highly perishable. It might be correct today, but we can't be sure how much longer it will remain valid. I am skeptical of many finding done in the 1990s, simply because technology and user behavior has moved on since then. There are few eternal truths in an out-of-date HCI textbook. What remains useful are the methods of HCI (e.g, task analysis), not the specific findings of user trials.

We have a human tendency to want to think through of the implications of a finding, to generalize from it. This tendency may be even stronger among commercial researchers than academic ones. Commercial researchers can be less cautious in their generalization. If we encounter research data on something not previously studied, we want to treat it as the foundation of something of wide and lasting consequence, not as data limited to a particular group or a particular time.

Over the past quarter century, starting with seminal research by Tversky and Kahneman, cognitive science has developed a clearer understanding of expert judgment. Humans have a strong and consistent tendency to be over-confident about their understanding of a situation, and their ability to predict outcomes. In HCI, we see these findings confirmed when competitions of different expert usability teams arrive at widely different conclusions about what needs fixing. Indeed, one "strong" conclusion of HCI research, according to strength of evidence index in the National Cancer Institute's usability research summary, is to avoid relying heavily on expert reviews and cognitive walkthroughs, the very kinds of activities that dispense with user research.

At least we have the routine feedback of user research to curb our temptation toward overconfidence. Let's hope.

formulas and confusion

2006-01-28T07:26:00.000+13:00

Earlier this week Don Norman picked up on a comment I made on a discussion list and said I was confused about some fundamental things. Indeed I can get confused, and believe the confusion arises from our field's quest for universal solutions. The tidy advice of HCI that is out there glosses over a big variable on projects: what level of knowledge about user behavior is required to design a user interface.

Let's arbitrarily divide user centered designs into two types: formulaic designs, and non-formulaic ones. Formulaic designs are the stock and trade of web agencies designing for the public -- things like news sites and online catalogs. They are ubiquitous, and generally all look and work the same, regardless of whose site it is. Generally people involved in such projects have a good idea about user needs even prior to starting: they are folks just like us, after all, and we have already talked to countless people like them for other similar projects. When we design for formulaic projects, we already have a good grasp of the solutions available to us. Designing an online shopping cart is not rocket science, it has been done countless times, users have expectations how they operate, and the work is mostly a matter of polishing the details.

If you work exclusively on formulaic projects, the tidy advice of usability will serve you well. You can find rules on common issues such as how to display error messages, and find plug-and-play models for how to incorporate usability into the development cycle. I don't want to suggest that formulaic projects are trivial and unimportant, and certainly do not consider all consumer web projects as formulaic. My point is that if project is addressing well tilled ground, you have tools to deal with it. Confusion avoided.

Now the rest of the interactive design universe is less than formulaic. The interaction domain might be novel, or complex, or highly specialized. Here the generic advice often falls short. HCI claims a scientific heritage based in cognitive psychology and computer science, and presumes there are universal truths that will be uncovered and will guide software development. And while I am happy to grasp and use any universal finding about human interactive behavior, the number of such findings is far fewer than the range of issues that confronts us. The reality is that for many issues, there is no universal user response, so there is no generic advice available.

The inadequacy of usability "best practice" is illustrated by a simple example: what is best practice for using disabled buttons? A consultant posed this question on a discussion list recently, and I smiled with recognition at the problem. I have also struggled with the issue, and dutifully consulted my vast HCI library as well as my Google bookmarks, but found concrete advice on the issue wanting. Sure, there were a few references to how to do things very badly, some very abstract principles about not causing users grief, but not much on what to do so as to assure no one gets confused. Replies to the question on the discussion list yielded as many different, contradictory answers as there were respondents. All the answers were thoughtful, and plausible, but no one seemed able to give a definitive answer that could be applied by designer to another context without worry. Users just don't have a common understanding and set of expectations about disabled buttons. One of the most common, plain-vanilla issues eludes development of best practice guidance.

The collective body of usability evidence -- published test results demonstrating what is effective -- is often murky. Sometimes it resembles seesaw headlines about diet and nutrition benefits. This week tofu makes you smarter, last week tofu was ineffective in preventing cancer, next week tofu will heighten cholesterol [I jest]. What to do?

If you are Don Norman, you tell UI designers to "Have faith in our ability to design well-crafted, understandable interfaces and procedures without continual testing." I don't understand why user testing is falling out of favor, because it seems more relevant than ever. True, for formulaic designs, usability testing is not the eye opener it once was, which is exactly how it should be. But I sense the IT industry, broadly defined, may be creating diversity in interactive design faster than we are bringing interactive behavior into the fold of formulaic design. We extend online applications to a greater range of activities where no precedent exists, to smaller subsegments of users about whose behavior we know little, and to growing range of platforms, mobile especially. And diversity is a re-enforcing loop -- the more diverse systems become, the more variety users are exposed to, and the more their expectations of how systems behave diverge. Diversity is leading to a fragmentation of user expectations. It is a challenge to finding hard-and-fast rules to guide our designs. Usability testing seems more needed than ever.

In Norman's view, usability testing should be for debugging a design only. "UI and Beta testing are simply to find bugs, not to redesign." I think I understand his point -- that if a problem could have been avoided before testing, it should have been designed properly to begin with. But I am concerned that Norman offers an overly restrictive view of the role usability testing can play. The debugging view of usability testing implies that the design tested is formulaic. As I have argued, that is often not the case. Even if we are designing the ubiquitous shopping cart, there is no reason why we have to follow the standard formula that is out there. We can experiment, and breath a bit of innovation into the design. Testing allows experimentation. Rather than grasp for certainty by sticking only to formulaic designs, which may work but might not be the best that can be offered, we can explore alternatives. For example, the addition of instant messaging help to online checkouts is an innovation that didn't happen without a few redesigns arising from usability tests. AJAX promises great innovations for UIs, but there is no knowing how users will respond to a concept until the testing is done; bold experiments will often entail a series of redesigns until it is right.

Several years ago Nico Macdonald raised the concern that usability, by enforcing consistency, might stifle innovation in interaction design. That concern is valid if we believe there is only one way to design something. By enabling experimentation, usability testing actually fosters innovation. But more importantly, we need testing to explore our understanding of users, who can vary considerably in their expectations of how a system should behave.

Projects obviously don't fall into a simple category of formulaic or otherwise. Projects might be mostly formulaic (dealing with domain issues largely understood) but still present significant unknown issues for designers (perhaps an AJAX widget.) Novel, complex and highly specialized projects will of course build on formulas where available and useful, but will need to explore more about user behavior. Whatever the mix, I think we need to get explicit about the borders between what we can safely assume about user behavior, and what we are assuming unsafely.

Perhaps we need a central repository about what we as a discipline don't know, an issue tracker. A document on usability evidence produced by the US National Institute of Health a few years ago included the concept of "strength of evidence." Contradictory evidence is not a bad thing, even if it is sometimes maddening. For some of these issues we may eventually be able to separate factors that explain these differences (user profile, intervening contextual factors, etc.) Results can be change over time as well, as users learn new behaviors, and potentially even lose familiarity or patience with old ones. A central tracking system would require wide participation and a history before it would be useful, and for these reasons it might not be a viable solution. But even on a case-by-case basis, we need to let each other know what is unresolved in our field. For the sake of developing useful formula, let's externalize our confusion.

up the business value chain

2006-01-12T19:44:00.000+13:00

Restructuring business processes have been one of the most important -- if problematic -- activities in business strategy over the past decade. Reducing waste can cut costs and even enhance revenue, through increased responsiveness to market conditions. But poorly considered restructuring can be a nightmare.

I don't pretend that usability holds all the answers to how business should structure their process -- business is too complex for any one "formula" to work magic. That said, I would modestly suggest that usability can be an important resource to developing an effective implemenation of the restructuring of business processes.

Usability often is focused on the micro, rather than the macro. It might look at what individuals do, their specific tasks. Through task decomposition and task analysis, it seeks to develop an optimization of how the task can be done by people.

Usability also looks at how groups of people coordinate tasks, that is, how they perform activities. Originally, these group tasks were focused on teams, who needed a common view and shared understanding of what they were trying to accomplish. But as the world has become more joined-up through the Internet, the team has become a more amorphous concept, less of a cohesive social unit. Groupware has given way to portals that anyone with a password can access. Even the distinction between employees and customers is getting blurred. When customers access a portal to track their package shipments, they see the same data as employees. Questions now arise: should they see the same view, or a custom view?

Just as tasks can be simplified to reduce the time and number of steps need for an individual, entire activities involving numerous people can be simplified. But usability is commonly associated only with optimizing tasks done by individuals or small groups. As a result, it is sometimes dismissed as irrelevant to restructuring larger processes. Sometimes user research is criticized as merely tweeking an existing process, rather than as enabling a radical new process that is much more efficient. I believe such an attitude is shortsighted.

Most work on business process restructuring looks askance at people. Indeed, much process reengineering is aimed at reducing the numbers of people involved in a process in order to gain greater efficiencies. But too often a focus on process automation can lull strategists into ignoring the reality that people never disappear, they are sometimes simply marginalized.

One of the most common ways businesses reengineer their processes is by outsourcing their activities to their own customers. This is more commonly referred to as "self service." Businesses get to reduce staff, and trumpet the fact they have automated, even if they have mostly shifted the annoying data entry responsiblities on to their customers. Customers, whether businesses or individuals, agree to this provided they are given sufficient incentive. The incentives vary, but at a minumim the burden can't be too complicated. In other words, it must be usable.

Even when businesses don't outsource functions, usability places a critical role in the effective implementation of a reengineered process. Consider a common target of process reengineering: eliminating "unnecessary" internal approvals. One approach is to streamline the process, to simplify. It can yield a faster process cycle, and make the process more transparent to employees, who understand the simplified process more easily. Many businesses have found that streamlining processes have reduced costs enough to offset any benefits associated with the prior process.

The other approach to internal approvals is to automate them. The danger of eliminating them is that it can led to looser standards, and more risks. Many businesses choose to continue to collect all the data, but to feed it to an automated decision program. Because a computer program acts on the data, it might be no slower than if the approval had been removed, but it elminates risk and improves decision making precision. Only one small downside: it can make things cognitively complex, as employees need to decipher the meanings of computer decision agent. Usability can potentially help untangle this problem, looking at how this is presented to users. Perhaps analyzing messages or visualization solutions can increase employee comprehension.

However businesses choose to reduce procedural complexity, they must make their processes understandable to their employees -- and their customers. Employees need to be able to tell customers, who might be anyone outside the immediate process, what is going on. (Don't limit the concept of customer to individual consumers. Many companies have internal units that competitively bid for business from their own parent. It's an unforgiving world in business these days.) Companies look incompetent if employees have to say "it's somewhere in the computer system" or "the system rejected the request." The entire process must be comprehensible, that is, usable. Anything else is false economy: cost effective in a spreadsheet model, but not sustainably effective.

is usability a functional or non-functional requirement?

2006-01-02T16:00:00.000+13:00

Outside of projects involving consumer gadgets or consumer websites, usability professionals often feel they work on the margins of software projects. True, there is growing recognition that usability is important in principle, but in practice, many project plans simply don't reflect a realistic role for UCD, in terms of budget (do many of us get 10% of the project?), timelines, or process. Unfortunately, other than to groan, most fixes focus on highly variable soft solutions such as improving communication between team members, and sharing one's perspective. Such approaches are laudable, but inadequate. Except for the the smallest projects, improved communication will not accomplish much when the structure of the project has been cast by the project plan and room for addressing changes in scope has been eliminated.

I believe a major reason UCD is on the outside looking in is because of simple phrase most of us hardly even notice. The phase is "functional requirement." Nearly all our colleagues --business analysts, programmers, project managers, and business stakeholders -- are under the impression that usability is a nonfunctional requirement. They are both right and wrong. And while usability professionals did not create this confusion -- we don't even use the terms functional and nonfunctional -- we are least partly responsible for confusing others about what is essential in what we do.

Functional requirements are important for people involved with developing systems in many ways. In larger projects, functional requirements are articulated in a written specification. Once a specification is written, the scope to make changes has been reduced considerably. But what constitutes a functional requirement -- something so essential is must be done or else -- is open to considerable debate.

I am not a professional programmer, so I can only offer a flavor of how programmers view functional requirements. Here are some distinctions others make between functional and non-functional requirements:

Functional: quantatative tasks a system performs. Non-functional: how system fits into its context.
Functional: actions system must perform, input-out behavior. Non-functional: system properties and constraints.
Functional: system behavior expressed in Noun-Verb form. Non-functional: Adverbial qualifier what what system does.
Functional: what system must perform, what a system does. Non-functional: how a system does it.

Although the above distinctions differ, one element is clear: functional stuff looks important, while non-functional stuff looks a bit less so.

So what do our colleagues think about where usability fits? Generally, people concerned with functional requirements don't even address usability: it is not part of the functional requirements process. The closest explicit statement to that effect I can find comes from Leffingwell and Widrig in Managing Software Requirements (edited by the famous Booch/Jacobson/Rumbaugh) who give 2 pages to usability as non-functional requirement. They complain about usability being a "fuzzy" notion that hard to judge a system by. Given existing usability specifications, how do we know the system is performing the functions it needs to do? In some respects, I think that is a fair criticism. Too many usability requirements are fuzzy, and hard for others to respond to predictably.

Software requirements don't often specify UI behavior, which creates a host of problems. Agile methods, about which I wrote recently, offer a work-around by trying to remove documentation of requirements so that decisions about the UI aren't choked off by pre-existing functional requirements. Lucy Lockwood, codeveloper of usage centered design, argues that UI design is intrinistically associated with system behavior. "The best user interface design will offer little to users if crucial details are lost in implementation." She comes close to viewing usability as a functional requirement. While I agree that UI is deeply affected by what the system can offer the user, I balk at her belief that programmers need to drive the UI. She says: "most detail decisions affecting product usability are made by the people writing the code." Moreover, "good interface design is closely tied to the programming that supports it. Usability is a function of both appearance and behavior, and behavior implies programming." She believes a week's training in UI for programmers is sufficient for most the develop usable, if not excellent, designs. I can't speak for her experiences offering such training, but my experience has been that most programmers are not that interested in UI design and would prefer for someone else to make these decisions. Lockwood cites a shortage of usability professionals as limiting their involvement in UI design, but I think a bigger problem is the lack of explicit requirements processes for UIs, especially how these requirements are formalized, reviewed and communicated to coders.

Part of the confusion about the role of usability in the requirements process stems from its elastic meaning. Sometimes people refer to usability as user needs, sometimes as UI design. User needs in turn can be needs that relate to specific functions of a system (such as specific scenarios of use that are discovered from contextual inquiry), and needs that apply to the system as a whole (will users rely on mice or keyboards, will users need to conduct wildcard searches or sort results)? These user requirements can feed into both the functional requirements (via the business requirements) and the UI design. When usability is viewed solely as a non-functional requirement (screen layout issues that are independent of the system behavior), then major problems can arise in assuring that the system does what it must do to satisfy user goals.

Getting usability considered as a functional requirement is an essential step to getting it built into the project plan, getting time and resources for front-end activities essential to the success of project from the user's perspective. Sometimes even seeming trivial requests, such as wanting a summary screen drawing together different pieces of information, will precipitate a functional change request, and be viewed with reluctance. In these cases, usability is viewed as a project spoiler, and is further marginalized.

Unfortunately, the more UCD professionals talk about "user experience", the more others view usability as mostly a matter of presentation, and as a non-functional requirement. This aspect of usability does exist, and is both important and non-trivial, even if non-functional. There is much that usability can do to improve things for users without tinkering with the underlying behavior of the system. But such surface usability has limits. We need to get wiser about communicating the specific impacts of UCD, how they impact other non-UCD activities, and how project plans need to be constructed to assure that UCD addresses important functional aspects of the system.

agile usability by committee

2005-12-30T09:44:00.000+13:00

You know something is brewing when the end-of-year issues of both SIGCHI's Interactions and the UPA's User Experience have articles on so-called "agile usability." I welcome the exploration of new approaches, especially hearing about real world experiences with these. Agile usability is an attempt to incorporate usability (sometimes loosely defined) with agile software development methods. It addresses a screaming problem in software development: the complete lack of an explicit role for UCD input in the standard frameworks of software development methods, particularly the "Rational Unified Process" that has such a stranglehold on development these days. IBM should be taken to court for promoting RUP as good practice when UCD at most is considered an optional bolt-on accessory (supply your own bolts and hope you can find the right size.)

First the good news: agile software development methods are generally better than RUP in reflecting user needs. The bad news: agile is not that much better. Can fusing usability into agile programming make the product truly reflect user needs? The jury is still out, the experiment is still unfolding. But I am wary. Agile usability seems like a band-aid solution to a trauma wound.

Agile programmers seem like cool people. They experiment, listen to others, and dislike stuffy paperwork. Not only are they cool, they even use a few words used by the UCD community, notably "iteration." (Alas, what agile programmers consider an iteration and what UCD folks consider an iteration differ widely, a faux ami. )

While discussion is an endearing quality of agile methods, an important party seems to be missing from the discussion: those anonymous folks known as users. Agile advocates will protest that I exaggerate here: they invite a person variously called a "customer representative" or a "user surrogate" to chat with the programmers. But it is important not to let the conversation get too big, otherwise stealthy character of agileness is lost.

At the heart of agile methods is meetings, generally very small meetings (we want to be agile, after all), but meetings all the same. At these meetings, programmers try to model what should be happening with the program. The two or three people meeting decide what to do next with the program. What do they base their decisions on? I see two major sources of feedback for agile programmers: how the code is performing in meeting perceived needs, and conceptual models that the programmers create to think through what users need from the program.

There are some significant risks associated with using functional prototypes as a foundation for the final end product. You get invested in your solution when you choose not to throw away alternatives, which is the beauty of paper prototyping. Your UI can get enmeshed in your functional domain model, making it difficult to change. You are prisoner to the fundamental problem associated with any form of incremental design, namely that you invariably develop a solution that "satisfies" (is the first solution to minimally meet needs at hand), rather than a solution that looks at broader and longer term issues, and seeks to find the best alternative given the wider trade-offs. Sometimes you end up a blind alley, as your evolving solution fails to scale to the growing complexity of needs.

I find troubling the notion that conceptual models can serve as adequate proxy of user needs. Programmers are smart people, and love models, especially high level abstract ones. It should be no surprise that techniques that promise to model user needs are the techniques of choice embraced by agile programmers. The models favored are variants of either scenario-based models, or usage-based models. What are these user models based on? Sometimes they are just based on a conversation between a pair of programmers. If more elaborate, the programmer pair might call a meeting to get input from some other stakeholders, such as the customer representative. But what these models aren't based upon is proper user research. The scenarios and "usage" reflects what a bunch of people sitting around a conference table said, and no more. All kinds of assumptions are made, and never verified, in such scenario and usage modeling. Models reflect the tunnel vision of their creators. They lack the peripheral vision gained by widespread consultation with users before design and during development.

What is most lacking from agile usability is a formal role for user testing. There may be a grudging acknowledgement that user testing is useful is limited circumstances, and a few UCD consultants have managed to sneak-in testing on an agile development project. But generally agile programmers see usability testing as a time waster, and unless and until that attitude changes, agile usability will be only be agile without the usability. Some agile advocates, particularly Larry Constantine, claim you really don't need to test to attain usability. "Our view [of usability testing] is not uncritically positive," he writes:

Our own view of usability testing is that it can be an important and useful tool in service of enhanced usability so long as it is recognized as only one specialized tool among many. Particularly in the absence of good models or methods of design, usability testing is indispensable. Testing, however, is never sufficient in itself to
deliver highly usable software. [my emphasis]

That quote might even sound reasonable out of context, until you see that Constantine devotes only a few pages to usability testing in his 500 page book (Software for Use) that is supposedly about usability. Constantine is a critic of usability testing, considering it too expensive and inefficient (if it weren't for the fact that usability testing "plays such a prominent role in the business of software development", I wonder if he would even acknowledge the limited benefits he concedes it offers). He proposes to "upgrade usability" through is own methodology of usage centered design, which which in his mind effectively eliminates the need for testing. Somehow Constantine fashions himself as a usability expert, but he dismisses what 99% of other usability experts consider the foundation of usability: usability testing. How Constantine can call usability testing "a specialized tool", as though it was on the fringes of common use, escapes me.

I happen to think Constantine's usage centered design (to quote his own phrasing) "can be an important and useful tool in service of enhanced usability so long as it is recognized as only one specialized tool among many." But Constantine would have you believe his approach is the only one that matters (the book's list of references contain mainly his own writings). We are back to the old days, when checking real world usability is an afterthought, merely tidying up a few minor details. If only things were that simple.

The hubris of usage centered design is the conceit that a select few can know the needs of many through enlightened processes. Constantine does briefly speak about the need to get information from real users, but he devotes most of this discussion to how to get information about users at arm's length (from surveys, for example, rather from realistic settings.) Whenever users are mentioned, the discussion is short (not enough to act on), perfunctory (by acknowledging that true, some people do direct user research, which in limited circumstances might be useful for some people, if interested look elsewhere for details) and ambivalent (dealing with users involves "chaos"; a lack of enthusiasm for UCD abounds.)

Constantine wants to "move away from purely user centered approaches to software design." I'm all in favor of improving design methods, and reducing the amount of testing needed, even iterative testing. There is too much software to test properly, so testing needs to be prioritized. But while Constantine has identified a valid problem, and even offered some additional tools to deal with the problem (mostly task modeling), it is highly grandiose to imagine he has solved the problem. In Constantine's view, modeling will produce mostly usable software (what he calls "built-in usability"). Any remaining problems can be addressed through "collaborative usability inspections", in other words, more people chatting while sitting around a conference table.

I may be entirely wrong: perhaps one can design completely usable software without doing either user research or user testing. One can simply rely on design methods and usability rules, and presto, a usable software system emerges. But even though I respect the power of methods and rules to improve products for users, I am unaware of any combination of methods/rules that would guarantee fully usable software. Best practice is useful, but insufficient. There are too many variations for best practice to address, too many unknowns about users, too much innovation happening, too little certainty about how all these factors interact. Perhaps years from now, when user research has uncovered its last discovery and when technology has evolved to a point of standing still, we will have a science that won't require users to offer their inputs into requirement and show their performance during testing. Until then, modeling and inspections seem like a recipe for missed requirements, unforeseen interaction problems, and confused people.

I focus on Constantine's views in particular because for many people in the agile programming world, he is the face of usability. [Disclosure: I've never met Constantine or even know anyone who has. My criticisms of are the methods he advocates, not of him as a person.] Constantine is a major writer on the Yahoo agile usability list, a list more dominated by programmers than usability professionals. The people-free "usability solution" offered by usage centered design is no doubt appealing to some programmers. But if agile programmers are going to learn what usability is about, they need to get a representative presentation of usability, especially the importance of user testing.

However broken existing software development processes may be, with its inability to reflect user needs, I hope we can develop a meaningful solution to the problem, and not a lesser of two evils solution. For the moment, agile usability is just somewhat better than RUP. Let's hope we can get a real UCD solution embedded in the software development process, before agile usability gets entrenched, with everyone believing the problem has been solved.

switching costs and usability

2005-12-29T19:41:00.000+13:00

I recently groaned about how supposedly "open source" Firefox didn't really offer a vendor-neutral solution for storing bookmarks. Firefox forces users to rely on its own implementation of bookmarks, which is a usability negative. Firefox imposes a penalty for switching to another browser, making it difficult to export one's bookmarks, and try to hold their user base captive.

Firefox is using a "lock-in" ploy used by many vendors (Microsoft, Abobe, Macromedia, etc, etc). Economists refer to lock-in as a "switching cost." Switching costs are directed at two parties: at rival vendors, to make it more difficult for them to sell to your clients, and at one's own customers, to prevent them from defecting to a rival vendor. From a user perspective, switching costs diminish user choice and sovereignty and consequently the usability to perform activities independently of a specific vendor's solution.

Switching costs are a concrete example of how complete usability is not necessarily in the short term interests of a specific firm. Consider the broader issue of standards. On balance, standards benefit users, who can interact with data (numbers, images, whatever) without worrying about implementation idiosyncrasies. But market leaders or insurgents with a following consider standards a threat, since it has the potential to deflate their market share or market momentum. Standards market is easier for users to hop around between competing products, instead of being invested in one. While standards are good usability overall, they can have negative consequences for specific firms. Generally, dominant firms embrace standards only when their rivals have enough market share that it makes sense to say "We are the market leaders, but we pay well with any minnows you might also deal with."

Dominant firms are often half interested in the usability aspects of standards. If they are truly dominant, they would like user-recognized standards not to exist, but they can never be sure how complacent they can be. Often, firms are in limbo, using a half-standard, perhaps shared with other firms, but not truly universal, authoritatively endorsed by a leading standards body. In this case, they are concerned with user perceptions about the importance of standards. Do they stand to gain more market share by opening up the standards, or lose market share by doing so? If a small player in competitive market, a firm will be interested in promoting standards, which will reduce the costs of acquiring new customers.

Firms may abhor standards because they would appear to reduce one's own differentiation. The question is, does this differentiation matter to users, or is it just narcissism by the firm? Embracing standards generally reduces costs for a firm's product development, and so promotes cost leadership. Lower costs benefit firms and users alike.

When it comes to reporting how users experience switching costs, usability professionals are simply messengers. Companies may see danger or opportunity in the message, but that is for them to interpret.

data quality for enterprise usability

2005-12-23T17:34:00.000+13:00

IT productivity is a tricky subject. Many commentators focus on transactions and data and associated software and hardware costs, rather than employee activities and labor costs. A data centric view of IT productivity can led one to under value the role of people in creating and utilizing the data. On the other hand, an emphasis on employee satisfaction, such as advocated by HR departments, can led one to under value the business importance of data. Data may not be as warm and fuzzy as people are, but it is important all the same.

Data management has always been a massive topic in IT, and that shows no sign of abating. Companies often proclaim that data is the key to being customer-centric. Sometimes they mean having data available about a specific customer transaction while speaking to a customer. Other times customer-centric means mining data to predict what customers will do in the future. A good example of both these dimensions is insurance. Data collected from current policies and claims are important for the resolution of issues to the customer's satisfaction. And historical data on past policies and claims can be used to predict customer behavior.

The problem for companies is that while they collect volumes of data, it is not always useful. One study claims that data quality problems cost businesses $600 billion annually. While that figure sounds exaggerated, one reasonably can assume data quality is costly to business.

Usability can play many roles in improving data quality. It can improve data labeling and taxonomies to enable better sharing and aggregation of data. It can explore how to streamline the collection of data by employees and from customers. It can map touchpoints where data can be verified from customers easily, to allow data such as addresses to be updated and corrected. It can improve retrieval and analysis of data, for example through drill down techniques, so it more often sees the light of day. Most data collected by companies is never used again a week after it was collected.

In short, usability can help with the accuracy, completeness and relevance of data. A fair amount of data collection and analysis is automated, and usability has little to offer those processes. But if the automation worked as well as it is supposed to, data quality wouldn't be a problem. It always comes back to people.

design patterns and mental models

2005-12-22T19:03:00.000+13:00

For those of us who design UIs, a few books are appearing that speak to "design patterns." I have just received Jennifer Tidwell's Design Interfaces, a welcome addition to other design pattern books, such as Susan Folwer's excellent Web Applications Design Handbook and Douglas K. van Duyne's The Design of Sites: Patterns, Principles, and Processes. I like all these books, and don't consider any duplicate the others. Still, I hunger for even more examples. "Design patterns" approach interaction at a very high level. I want a catalog of every variation done for ideas for the exact solution needed. I want a UI equivalent of the Owen Jones' Victorian design "pattern book", The Grammar of Ornament.

There are activity patterns-- the sequencing of tasks, and widget patterns -- how tasks are done within a screen. But patterns are a designer-centric approach. If they are familiar to users it is because designers use them frequently.

Mental models are slightly different. A mental model may be strong in a user's mind, but not often used by designers. It only takes one application to use an approach to develop a new mental model for users. Users develop expectations how something should work based on what they are familiar with. Consider something as ordinary as email. Users have a mental model of email based on what they use regularly. If you use Gmail, you expect email should offer the archiving abilities Gmail offers. If you use Lotus Notes, you see email functionality as incorporating unstructured databases. Outlook might be the most common of its genre, but irrelevant to the mental model of a given user.

What is becoming difficult for UI designers is the proliferation of user mental models. There are many variants of application in use, and one can never be sure what experiences have shaped a user's mental model. What we need is a catalog of interaction behaviors of widely used software applications. We need to be able to easily look up what mental models are being formed, when we ourselves might not be using the applications ourselves.

icing or cake?

2005-12-22T18:02:00.000+13:00

People who know me know I have misgivings about the phrase "user experience". Sometimes the phrase is appropriate (e.g., when discussing a purely recreational interaction), but oftentimes it is used in a lazy way to describe a raft of benefits of UCD. Today I encountered a good example how the phrase "user experience" can pollute the minds of people.

I was talking with someone who had previously engaged a well known "user experience" consultancy for advice. The consultancy has a fine, international reputation, and I have seen some of their work, which is good. I'm not slagging their ability in the least. But what I do object to is how they cast the benefits of UCD. They talked the standard talk about improving user experience. The message came through clearly. Yes, user experience is good, but face it, it really isn't our highest priority. Sure, it is nice to offer a good user experience, I'm sure our employees would be grateful, but the really important issues are functionality, how we can value from our databases.

Most people in UCD can't speak the language of business, so they talk user experience. They can't tie benefits to existing business goals, so they rely on the feel good factor, with vague suggestions that unhappy people make mistakes or leave in frustration (not only a insufficiently substantiated suggestion, but a negative one to boot.)

But businesses aren't intrinsically empathic. Quite the opposite: business organizations don't care about happiness unless there is a monetary consequence involved. Until we develop a physics of happiness, with certain, immutable laws resulting, appealing to happiness won't effect any impersonal outcome produced by an organization.

We need to stop looking for admiration by acting like nice guys, and win respect by solving organizational problems.

design for the unknown

2005-12-01T18:58:00.000+13:00

My koan (riddle) for today is how to design for the unknown. I can't seem to nail down what the user requirements are. Asking other people what they need doesn't bring any more clarity. I don't have the luxury to try out different alternatives, and test them. No, I simply have to make an poorly informed guess about what users need, and live with it. I am unfamiliar enough with the subject domain that I have learned not to trust my instincts -- they aren't a reliable indicator of what is required. A very frustrating situation to be in, though a common one, especially where new product or process in involved.

performance and usability

2005-11-28T18:05:00.000+13:00

User Acceptance Testing -- determining how well a system performs functionally -- should not be confused with Usability Testing -- determining how well a system meets user needs. Geeks fixate on technical performance, while usability advocates focus on human performance in the context of technical systems. But now that usability specialists have established what's important is not the system, it's the user, it seems this distinction is getting blurred again.

Enter Ajax. I've been slogging through some detailed writings on Ajax technology recently in a effort to catch up with the buzz. While only half understanding it all, I see indications that technical implementation is the difference between a positive or negative user experience. Paper prototyping is useless for Ajax. Forget how Ajax works in theory, worry about how it works in practice. Getting a browser to steal a moment to request data from a server takes some programming finesse, dealing with subtle timings on both client and server ends. JavaScript would seem especially unruly, given that it lacks the disciplinary structure of other programming languages and is prone to memory leaks. There seems ample possibilities for conflicts and hang-ups, which can grind user sessions to a slow march. I wonder if and when we will start seeing bad Ajax apps appearing on the net.

The more invasive web technologies become, downloading themselves onto a user's PC and affecting a user's memory resources, the more important live tests will become.

give me network computing that's flexible

2005-11-27T19:23:00.000+13:00

Computers are more cheaper than ever, and more capable to boot. There is a strong temptation to put one in every room. A temptation tempered by the hassle of keeping these beasts up-to-date with patches for bugs and Trojan doors, security programs, latest plugs-in, extensions, compatibility problems, upgrades to new standards, etc.

Our household has three "active" computers, plus two moth-balled ones with valuable info that need occasional access. But I have become tired of being the in-house help desk. I want to outsource that function. Isn't outsourcing supposed to be the future?

Ten years ago Sun Microsystems talked up the idea of the network being the computer. It hasn't happened, really. Bandwidth has improved, Web apps are more capable, but the experience isn't the same as having programs on one's own PC. Even Ajax, valuable as it is, is just a workaround for the chasm between people wanting immediate interaction from quick devices and the cumbersome protocols of speaking to remote server farms.

Before I can ditch my computer for a dumb terminal that doesn't require my attention, several things need to happen. Connectivity needs to be fast - several orders of magnitude faster than current broadband. We seem to make content more memory-intensive as we improve connection speed. It is much like the phenomenon that the average speed of traffic in London is 10 km an hour in 1905 and 2005 -- nothing changes. We need things faster in the future to handle what the future will bring. I don't want to download anything -- applications or content.

Second, we need to let users choose what they want, not just have a standard package of software choices forced on them. Many of my personal dramas involve hiccups between minor applications, not the major ones. I want choice -- the grand promise of our market system -- and I want service too -- the other promise. I don't want to be stuck trying to figure what combination of configurations is causing the problem. I don't even want to buy a program to do these task automatically (the responsibility for fixing them is still mine.) I want a company to offer everything I might ever want, who guarantees it will make it work together. But the current model of the system administrator couldn't be further from my ideal. I don't want to be punished for expecting things to work well together, being told I have to use software that is five years out of date. I want the newest innovations, screened and patched for compatibility.

The first obstacle, speed, is at least partially technical (though there is a political element -- where there is a will, there is often a way.)

The second obstacle requires a radical rethinking of how the software industry works. I would like to see someone take responsibility to certify software for robustness. The "leave it to the market to decide" approach doesn't work well enough. Currently, if vendors offer incompatible software, they simply declare the birth of a new standard, and expect that others will follow it. If something doesn't work, it is someone else's fault, or vendors claim it a minor annoyance for the privileged of getting a preview of something innovative. Microsoft enforces some level of compliance, but since it is not a neutral party, it can both both act unfairly, or be ignored even if it is not throwing its weight around. Voluntary committees aren't fast, and don't produce consensus. What is needed are commercial, independent organizations that have credibility to disclose what applications don't cooperate with what. If companies knew there sales depending on it, they wouldn't be so eager to pass the time drain of compatibility on to consumers.

I don't want to buy (oops, rent) software directly from a vendor. I want, as a consumer, to have a "software maintenance organization" [SMO] do that for me, and supply what I need as I need it. Using a "dumb terminal" (today more likely just a screen), I don't care what server an application comes from. Different servers may speak different languages, but they can all speak to my dumb screen -- compatibility problems disappear. SMO's will bear the costs of dealing with upgrades and compatibility. When the real cost of incompatibility is accounted for -- SMOs will bargain hard with vendors to clean up their act. If consumers value the extra cost a disruptive change in software standards creates, then they will pay more their service. But otherwise, vendors will need to contain the disruption they typically unleash, by adhering to standards, and testing their software in real situations. Even the biggest names in software rarely do in situ user testing -- seeing how well their products work on the home PCs of average families loaded up with heaven knows what.

It seems a long way off, but maybe the network will someday be the computer.

is tabbed browsing changing the structure of content?

2005-11-20T17:59:00.000+13:00

Tabbed browsing has been hailed as a revolution, though Ben Goodger at Firefox cites Microsoft research that says having lots of windows open -- a problem tabs is meant to solve -- is not that big a problem for most users. I'll admit I have been slow to understand why users need multiple Webpages open at once, though I'm starting to see more possibilities. Without doing testing myself (probably only browser developers would commission such research), I see the following possibilities for ordinary users:

One might want to have two tabs open, one for a set of Google search results, the other for a specific page from that list of results. This saves using the back button after reading through a multi page document.
One might have several pages open if doing say, serious comparison shopping, toggling between tabs to different pages.
One opens a secondary page tab to follow up a link embedded in an article, so one can return to the article without loosing one's place.

The last possibility, new tab opened when clicking on an embedded link, breaks a paradigm for web content. Web content developers have been told not to use embedded links within the body of an article, because users will leave the site and probably never return. Associated links are supposed to be placed on the side, or at the bottom of an article, to avoid the possibility of users being sucked away.

Among sites I routinely read, I notice that the New York Times now has embedded links within the body of articles, whereas previously they put links at the end of articles. I don't know if this change in practice is because of the rise of tabbed browsing, or because the Times is trying to sell their premium service, and tempting people at every opportunity.

drama therapy

2005-11-19T17:25:00.000+13:00

Ideo are moving ever more into Oprah territory. Their mission is to rid company employees of their negativity. If the brand of the moment is innovation, then employees don't dare be off brand. Ideo's answer to negativity is personas, happy personas.

You can read the "exclusive" excerpt of Tom Kelley's new book published in Fast Company. If I were to give Fast Company a persona, it would be a business version of Hello! magazine, fawning over profiled business personalities.

With a judgmental attitude not generally associated with the "California persona," Tom is very harsh on people who play "devil's advocate." He calls them toxic. Rather than allow employees to question ideas, better to trust Tom to tell you what employees should be thinking.

Buried in the article are some worthwhile ideas, but the presentation is so buzz word laden and gratuitous it is hard to take it seriously. Why is the "Hurdler" a necessary persona and not someone let's call the "Magician" or the "Fairy"? Sorry to play devil's advocate, but my intuitive side detects a lot of bullshit, and my logical side isn't persuaded either. There is a Tony Robbins quality when Tom says "the personas are about 'being innovation' rather than merely 'doing innovation.'" Why not "be innovation" by trying fire walking? Is the goal to feel good, or achieve something? Innovation is more toil, and less happy talk, than Tom admits.

Good ideas need articulate champions, not thought police. Kelley's innovation personas liberally borrow from Edward de Bono's Six Thinking Hats. The difference is that Edward de Bono recognizes a role for the devil's advocate (the black hat), while Kelley just wants -- and expects -- everyone to buy in to an new idea. That is not only not realistic (outside a sheltered environment such as beginning art school classes), but it is counter-productive. Even hard-nosed experimentation doesn't necessarily produce clear answers where facts speak for themselves. Facts need to be interpreted, and interpretations will need to be argued over to achieve clarity.

the quiet revolution in information architecture

2005-11-17T21:35:00.000+13:00

While I can't escape "doing" information architecture, I don't consider myself an information architect -- someone who truly focuses on the discipline. When I first encountered information architecture maybe 5 years ago, it seemed like common sense to me. I worked for many years as a technical information specialist, so working with classification schemes for text databases over Internet delivery seemed old hat.

How times have changed. Information architecture is a now discipline with great depth. It is no longer just common sense. There has been a quiet revolution in the past two years, exploring new standards and web technology, and experimenting with new conceptual approaches. Information architecture has gone from a field that seemed overly concerned with defining itself, to being a field that innovates, being experimental and empirical. I notice the gap between what I have a good knowledge of in IA, and what is good practice, is widening.

What hasn't changed is the capacity of IAs to be modest and practical. I found a posting on IA slash lamenting how boring information architects can be. IAs need to give themselves more credit.

games people (and interfaces) play

2005-11-15T17:45:00.000+13:00

Computers are complex. People are complex too. Who gets the last laugh?

I've identified at least three games that people and computer interfaces play with each other.

1) "Make a wish (but be careful what you wish for.)" In this game, people tell the computer exactly what they want, the computer happily obliges. We assume here that people are very clever, and computers are rather less so. This game has a "feel good" factor to it: we are superior to computers.

Now, imagine you could get your computer to cook for you. You might see an interface a bit like one of those "design your own" noodle menus. You choose ramen (noodle type) + chicken (meat) + black sauce (sauce). You get back an assemblage of gunk that tastes tasteless. You realize that cooking something tasty isn't that simple.

2) "Spot the difference (that makes a difference)." In this game, the computer has done all the hard work of gathering the details about different options. Every conceivable option under the sun is available. You just need to choose what you want.

Imagine the computer does your grocery shopping. You want to get some potato chips, and are offered 400 choices. Which one do you want? You feel a bit overwhelmed, trying to figure which one would be best (the extensive listing of ingredients doesn't seem to help either.) You decide that other people must know the answer, so you look at user reviews. All of the options have 80% of feedback comments giving 5 stars, with a disgruntled 20% minority giving 1 star. Doesn't seem to matter what chip, always the same distribution of star ratings.

3) "Guess what I want." In this game, the computer keeps guessing what you want for dinner. Finally, the perfect servant!

The computer finally figures out that you want tofu, after an hour of wrong guesses that assumed you were a carnivore. It cooks the tofu, serves it to you, and you pout. "No, no, no, this isn't what I want at all!" The computer asks what is wrong, and you comment the tofu needs more salt. After adding more salt, the computer is again told it isn't right. It needs more pepper. And so, and so on. The next meal you are offered a decent tofu dish, only you are so tired of thinking about tofu you now want a cheese sandwich. More guessing for the computer.

Computer interfaces play their strongest game with fussy eaters. If you hope to avoid being humilated by your computer, try eating brown rice only.

open source blues

2005-11-10T18:57:00.000+13:00

Open source is a lovely idea -- kind of like world peace, or a pollution free world. Sadly, ideals don't translate into reality without a bit of disappointment.

I want to give Firefox the opportunity to shine. Heaven knows browsers can stand improvement. But whenever I invest a bit of time to enhance Firefox, I get burned.

I spent the weekend adding various extensions -- things that actually make Firefox qualitatively different -- which required me to download a newer version than I had loaded previously on one of our home PCs and deal with annoying questions from the Firefox development team. Firefox is annoyingly preachy by the way. Note to developers: you are making software, not saving the world. You won't be getting a Nobel peace prize for your efforts.

A few days later, something has blewn up, and now nothing is there, apart from a reloaded, completely clueless version of Firefox that doesn't even know my bookmarks.

Yes I am getting this for free, but I'd rather pay someone, even Microsoft, a few bucks to assure some kinks are worked out ahead of time. My time is more valuable than the retail cost of the software. What problem does open source solve? Companies aren't the evil, payment isn't the evil, the evil is how monopoly can stiffle innovation. When open source encourages innovation, great. But what problems does open source unleash? Often crappy beta software, enough to make even an experienced computer user into a cynic. What a tedious waste of time for users to try to choke-proof software, creating back-up files, because there are no robust systems in place to verify compatiability of add ins. The wild west of software can be exciting, but is dangerous. Trouble is, you don't know that you are bleeding edge until something innocent looking fails. I am not a sucker for the taunts saying "hey you don't have our latest build!" Even supposedly stable builds can be too flakey.

UPDATE

If we are going to live in a multi-browser world, we should have a common file for bookmarks. I am hoping to find a way to synchronize bookmarks saved in either Firefox or IE. IE has a clumsy utility to import and export bookmarks (I have had no success figuring it out). Firefox only lets you import bookmarks from IE, but doesn't let you export them to a common file folder. Who is playing fair? If users are being offered a real choice, and your product is supposed to be better than everyone else's, why try to prevent them from defecting to a competing product?

If I can never get bookmarks saved in Firefox into IE, but can do the reverse, I only want to save bookmarks in IE, which encourages me to use IE more. What is obnoxious is the entire notion of a "default" browser, where everything is supposed to live.

issues in enterprise usability

2005-11-09T18:00:00.000+13:00

Jakob Nielsen has posted a "Alert box" column on enterprise usability, a topic that has become a keen interest of mine over the past year. It isn't terribly informative, especially given the magnitude of issues involved. He does admit that "group-level usability and enterprise usability are less well defined: they've been researched less and are more variable" than consumer usability.

A couple points of disagreement:

JN: "Total cost of ownership (TCO) is often one of the most important usability metrics at the enterprise level. "

Michael: TCO is a vendor metric used to sell replacement systems. It really isn't about usability at all. The real metric is ROI, which involves the very elusive concept of measuring the productivity for workers of a software application. Developing methods to assess human productivity in enterprise systems is just beginning. It is very difficult, but most anything is better than the total neglect it receives currently.

JN: "for enterprise usability, we need to study the people who run the organization and who know the pain points at levels above an individual contributor's job. Customer roundtables are a good supplement to field studies: they bring together a small group of sysadmins or managers to discuss their own experiences with larger issues of the product's use."

Michael: Talking to managers is important, but customer roundtables is the wrong way to do it. Customer roundtables are no different from inviting managers as stakeholders to a requirements roundtable. In my experience you get a few anecdotes that seem interesting, but have no way to know how big the problem might be, or what else you are missing. Research with managers needs to be grounded in the same contextual research approaches used for endusers, combining observation and discussion around artifacts.

how much can we rely on user testing alone?

2005-11-08T17:47:00.000+13:00

For many projects, user testing is the only proper user research conducted -- research with real people who offer concrete insights into user needs. User testing is certainly valuable, but is it enough?

I believe the usability community has become distracted by the question "how many test subjects are enough?" Champions of "discount usability" developed a mathematical formula that supposedly proves that adding more test subjects after 5 or 6 yields little new information. The formula works if you don't care about the underlying assumptions, but if you are curious about them, you find the formula only works in ideal situations, where you are doing a "health check" on something you expect mostly will work, with a homogeneous group of test subjects. If either of these conditions aren't true, all bets are off about now many users you need.

User testing is an opportunity to test hypothesis about what users need, within the context of other design constraints. Despite the obvious annoyance of having to run tests with users who offer no further enlightenment, and the extra cost of such superfluous testing, one needs to also acknowledge one never knows in a preliminary test what will test poorly, and can't prejudge the scope and scale of issues. Doing proper iterative testing, where every design requirement is subjected to multiple tests, will throw up issues everywhere. Because the scope of testing is fluid in iterative testing, one can't say how a result will necessarily settle. You play with alternatives to get reactions as long as there is diversity in reaction, and project time and budget to explore this diversity.

Another complication arises when a single design is meant to serve diverse users. One client I have worked with on many projects segments users into various age categories, and also whether they are consumers or business customers. All these segments need to be covered in testing because the client's stakeholders organize their products and processes around these segments. But prior to testing, one is never sure how these segments might differ in reaction to prototype designs. They might all react the same way, in which case checking all their reactions seems like overkill in retrospect. What often happens is that one or two subjects differ from the overall test subject population. Is this an expression of their segment preferences, or is it noise? Because the groups have been subdivided so finely, it can be hard to tell.

User testing is wonderful data, but it can be difficult to draw over-arching conclusions from it. I therefore encourage clients to do pre-design user research, so user preferences and needs can be at least partly established before actually tested. Such user research also allows one to learn if a design is bombing because of a design compromise due to an external requirement -- you guessed users wouldn't be keen on the compromise, and indeed they weren't.

user research is about data

2005-11-07T21:27:00.000+13:00

I am worried how methods are dictating design outcomes, without the involvement of user research. The signs of method-itis are often hard to detect, because many methods purport to infer what users want, without doing the donkey work of actually consulting users themselves.

User centered design is about looking at what users need and want, which comes from extensive research. No extensive research, no user centered design. But some people imagine because they want to help users, and because they are ever so empathic toward users, they are therefore user centric. They simply "know" what users want, through their own experiences, dissecting hypothetical issues, or walking in the shoes of users, imaging what the user would do. Somehow they forget the central issue: you can't know what users want except by actually looking at their behavior and preferences from all perspectives. People who think they know what users want without doing research have either worked on a very narrow issue too long, or are not very competent. The road to hell is paved with good intentions. The road to user centered design is paved with facts.

Data may seem lifeless, and a sideshow to the main story. Market researchers are often criticized for generating confusing data that doesn't point the way forward. Market researchers are frequently guilty of developing shallow data: surveys that don't answer why users behave as they do, and focus groups that don't answer what users actually do and truly need apart from a random collection of impressionistic feedback.

Useful user research, whether quantitative or qualitative, involves structure in collection and analysis. Unfortunately such research structure is often lacking in design approaches that take the end as the beginning (i.e., design to fit users to a preconceived activity, scenario, or use.) Frequently these approaches are based on a fictional person: an imagined typical user, or an imagined extreme user (an outlier case). Users weren't identified according to how representative they were, they weren't studied over enough time, or across enough variant circumstances to determine what themes are genuinely common and which are unique.

I am a big fan of possibilities of qualitative research, but I find that math phobes make the worst qualitative researchers, because they don't understand the notion of sampling and significance. One can be qualitative by doing a detailed structured sample of small group of people to probe inter-relationships, or light observation of a wide group of people to find common themes. But whatever the approach, it needs to be robust, ideally drawing on multiple perspectives. I highly recommend the books of DVL Smith and JH Fletcher on the relationship between qualitative and quantative research.

The major question any method needs to answer is: how do you know your conclusions are right? Unacceptable answers are that people say it sounds right when I tell them, or that other people who follow the same method I used reach the same conclusion. Acceptable answers are that you used multiple research techniques to search for disconfirming evidence, and that you tested design implications of your research conclusions through user testing.

whiteboard politics

2005-11-06T21:26:00.000+13:00

The humble whiteboard is perhaps the best example of an "external representation." External representation is about the power of a physical representation of a concept to facilitate discussion among people. A fair body of theory and evidence has developed to support what many would consider common sense: being able to look at some while discussing it is helpful. The question is: helpful for whom?

I have a tendency to grab a marker during a discussion, and write on a whiteboard. I idealistically imagine everyone is benefiting. I benefit by getting my thoughts down in front of me, where I can see them, and critique them, if I have too many to sort through mentally. Others can following more easily what it is I am talking about, especially the connections between the concepts.

While whiteboards are a cognitive facilitator, they are not necessarily a social facilitator. I notice a different dynamic around whiteboards than around conference tables generally.

People who talk a lot don't necessarily like to walk up to a whiteboard.
The person with the pen is sometimes assumed to own the floor, even if they aren't writing.
Writing something on a whiteboard can be presumed more authoritative than something said orally, especially if the end result is printed.
People often treat diagrams as important, regardless of what they are. People seem incapable of critiquing diagrammatic logic (or lack thereof). Diagrams are often simply ways to associate information, rather than show cause and effect.

While whiteboards should ideally be treated as scratch paper, they often are treated as powerpoint slides. Blame it on years of cutting arts funding in public schools.

user agency

2005-11-06T20:48:00.000+13:00

The longer I ponder the question of how the motivation of users affect their behavior, the more I ponder the question of agency. Agency is very related to motivation, but at the same time different. People are motivated based on their perception of how much in control they are, and how that shapes their expectations of what will happen. Agency is a psychological construct, defining how much people believe outcomes are the result of what they do. Agency is defined by the individual, but shaped also by society, and human computer interaction is being shaped by both ends.

Garden variety psychologists -- the kind who write advice columns, rather than study rats and undergraduates -- often talk about attribution. Is the consequence of my action the result of my skill, or some external factor? Some people are very "me" focused, others see wider circumstances as determining outcomes. We can see parallels in the wider contemporary debate about human and social nature. Some commentators talk about our (often genetic) drives, others talk about chaos, connections and non-linear determined external events.

In the computer realm, agency has been most clearly articulated in gaming. Their are games of skill, and games of chance. Agency in gaming is often a function of the amount of feedback a game offers, or the lack of it or lag in it.

What I sense is that interaction design is starting to shift away from the notion that users define outcomes. Compared with a decade or two ago, users may be more willing to give up control to their computer. Live is too complex to be a control freak.

The organizational psychologist Yiannis Gabriel has talked about the increasing tendency for workers to desire to "be discovered." Previously, hard steady work was the recipe for advancement. Now, "luck, self promotion, image and find[ing] oneself in the right place at the right time" are the formula.

We can see the shift from self-agency to reliance on externals reflected in computer applications. The old ideas of user control -- WIMPs, for example -- seems a bit old fashion now. Software, especially web applications, promise the benefits of luck and opportunity over user control. We roll the die awaiting "personalized" recommendations based on impersonal data mining techniques. We sign up for networking schemes online, hoping to make useful connections. A raft of social software and ambient computing solutions is being developed to fulfill our desire that the wider world will know what we want, and respond accordingly.

Will our hopes be gratified, or will we be disappointed? If the later, we will demand more control again, and focus on how we should be telling computers what we want, instead of the reverse.

methods without facts

2005-10-31T21:29:00.000+13:00

User research takes time and costs money. Small wonder designers are always seeking ways to cut corners, and by-pass research altogether.

The range of theory-heavy, fact-lite techniques that claim to be user-focused multiples all the time. We have scenario-based design, usage-based design, activity-based design; all are abstractions, looking at what users might or ought to be doing, more than what they actually do and want. Some might find this characterization unfair. Activity centered design is supposed to look at the users' context, and what the user does. But AT does so by looking at the user in a passive role, not as an agent controlling technology. Scenario-centered design and usage centered design similarly look at users as cogs in a system, fulfilling their role of conforming to the expectations of the system. The goal is to make sure users don't slow the system down, not to make the system respond to the pace of the user.

What these approaches do offer is an alternative to totally user-driven design. Users are vitally important, but users are not always the only -- or even the most broadminded -- definer of needs for an information ecosystem. We need research to provide credibility to the interests of users. But designers need to advocate user interests in the context of other stakeholders. Stakeholder trade-offs are political decisions involving people, not abstract equations comparing marginal efficiencies of inanimate pieces.

the two cultures of usability

2005-10-29T16:01:00.000+13:00

From time to time I have seen passing references to the existence of two tribes in usability: those who make interfaces, and those who critique them. It is a strange cohabitation of roles: ultimately striving toward the same ideal, but involving different skill sets, different temperaments, and an uneasy combination of synergy and contradiction.

One's understanding of usability is often colored by which tribe one is most involved with. In the largest companies, their may be dedicated usability testers, who are separate from UI designers and IAs. Usability consultancies often dominated by non-designers (testers and other user researchers), while agencies tend to hire designers and IAs. Many of us get involved in all aspects, researching, designing, testing, though we find ourselves doing some things more often than others.

In my experience, it is rare for someone to be equally talented at user research and UI design. Still, there are good reasons to have experience with both roles, though it can be problematic to do both roles on the same project. The tester who also has experience with design can overcome some of the limitations of the testing mentality. Testers tend to focus on what's wrong and not working, and offer didactic advice frequently containing the word "should." UI designers can get caught up in the rigidities of style guides and uniformity, which can get abstracted from the realities of what users want and need. A tester who has experience with UI design is more able to offer useful suggestions to designers on how to fix a usability problem that has emerged during testing. A UI designer with testing experience might be more sensitive to contextual peculiarities.

While the two cultures use complementary approaches, their basic temperaments are different enough to limit a fluid change in perspective. UI designers are focused on constructing an interface, while testers are focused on de-constructing it. Testers are more focused on what is not possible, rather than what is possible. They often are reluctant to offer any "solution" at all to a problem, out of fear their solution will test poorly. Some usability engineers shun offering any design advice at all.

UI designers can get invested in their solution, and can lack emotional and mental detachment to let go of it. It is no fun seeing a technical UI solution that has been developed over weeks get dinged by users. Unlike their more artistic web designer brethren, UI designers are presumed to be experts utilizing empirically developed principles and good practice. Clients are very happy to believe that a solid body of best practice exists that can be drawn upon to design a flawless UI from the start. Experts can be reluctant to take risks, and play with options, when prior experiences suggest a possibility of user hesitation, or implementation problems.

If one attempts to do design and testing on the same project, the potential for inner conflict escalates. Extraordinary self-discipline is needed to remain open to user suggestions in the UI design phase, despite one's fears that the design is getting too complex and won't test well. In testing, one needs to push one's elegant solution to the breaking point to assure that it isn't just you who is in love with the concept. Testing one's own UIs means turning off any hint of enthusiasm, to avoid getting a "want to please" reaction from users.

Playing both roles involves maintaining enthusiasm for nascent ideas, while ditching ones that don't work without a loss of pride when the client seems confused why you were so keen on one approach only to drop it cold. To bridge these paradoxical demands, one needs to be able and willing to criticize one's own ideas, to undermine one's own self-confidence that you have figured it out.

why personas don't gell

2005-10-16T21:59:00.000+13:00

Personas can potentially address many aspects of users. Each of these facets may be important to how users relate to an interactive design. But often, these facets just don't cluster around common themes, despite our desire to group everyone into a few easily digested categories. The essential problem with the persona concept is that attributes of users don't predictably co-vary with each other.

There is no common definition of what comprises a persona. Here is my own, non-exhaustive list of persona attributes that occurred to me today. You may dismiss some, or more likely, have more of your own to add. Users can be different in many ways:

Experience

with technology (existing or analogous, from virgin to novice learner to uncomfortable straggler to power user)
with a subject domain (what they know about investing, or airfare prices, or whatever);
life experiences (stage of life, encounters with significant events or circumstances)

Personality

socialability (e.g., willingness to ask for help, independence);
anxiety (toward technology, concept of self efficacy);
cognitive style (e.g., detailed oriented or not);

Motivation

career ambition;
social competitiveness;
expectations (e.g., about ease of technology, complexity of a subject);
playfulness;
curiosity
helpfulness (willingness to collaborate or share information)

Roles

job roles (e.g., functional speciality, multifunctional responsibilities);
social roles (may be context dependent);
family roles;
authority/discretion in various situations;

Goals

first-order goals (amount of time willing to spend, immediate demands of the situation);
second-order goals (instrumental accomplishments, KPIs, psychic/hedonic rewards, financial payoffs)

Even this short list highlights how many variables can exist within a user. These variables may be interrelated. Experience can affect motivation, and vice versa. Motivation can affect goals, and so on. But just because factors can be interrelated doesn't mean they occur together in predictable ways. Sometimes they do: teenagers are likely to have little experience with investing and also have a low motivation to worry about retirement. But my experience has been that opportunities for such stereotyping is limited, and is often not even interesting.

People are complex, and becoming more complex all the time. Imagine a persona for an employee in an organization. Perhaps twenty years ago one could safely make stereotypes about certain employees. Worker responsibilities were clearly defined, workers were recruited from homogeneous pool of applicants, and people's experience was safely defined by the number of years they had at a company. Today, workers may be doing any number of tasks (roles?), have had few or many jobs previously (which could affect motivation or experience any number of ways), be on short term contract (motivation?), be of an indeterminate age (experience?), and not really be molded by the company culture they operate in (personality?). A similar blurring of identity is evident in personal lives as well.

There are simply too many variables to consider in personas to allow them to cluster around five or six personas in a tidy fashion. (Most people consider five or six the maximum number of personas that can be comprehended easily -- unless you are into Dostoyevsky.) Another problem: two personas may be nearly identical, except for a key difference on one variable. By discussing the persona as a "whole person" (even if fictional), it becomes difficult to see the one difference between two people when the discussion is about the person instead of the attribute. The temptation exists to try to make the two people different in other ways, to exaggerate their difference.

I can see uses for personas, and I have been told by others they have had success using them. But I urge restraint. The technique can gained popularity without much critical examination.

too fuzzy: personas and scenarios

2005-10-12T20:43:00.000+13:00

Personas and scenarios are meant to make an abstract, intangible interaction process more concrete. But more often than not, they fail miserably: offering a simplictic, waffly caricature of something that is complex and nuanced. I am beginning to think that both tools are more dangerous than useful, and give user centered design a bad name by pretending to be user centered when in reality these techniques rely on assumptions, distortions and conjectures.

I have written previously about how confused the concept of personas is. I know that personas can be useful when one is clueless about your market. You may be a designer who is making something totally new, and need to get a feeling for who might use it. Or you are a high level executive who can't deal with details in a short briefing, and needs a mental picture of who the customer is. But designers are a bit arrogant to assume that clients are generally clueless about their customers and users. Generally the client knows far more than the designer. Developing the persona is less for the benefit of the client than it is for the designer.

Another problem of personas is that they very rarely are based on rigorous research. The detail they contain may sound impressive, but it is often invented. To be credible, every aspect of a persona should reflect real details of the lives of multiple people. If your persona reads Cosmo, it is because you have met more than one real user who actually reads Cosmo. Anything less is just fiction, not user research.

But if someone has done real user research, meeting with numerous people who share certain characteristics, a persona is a poor representation of that research. Personas suck the nuanced details out of research, and present a bland stereotype, who might as well be a cartoon character. As a cast of "characters", personas are simply stage actors. Few persona developers can answer what proportion of all users a given persona represents. Simply saying "there are some people like Grandma Jane" is fairly meaningless. Design research can highlight many things that clients aren't aware of. Unfortunately, personas are too crude to deliver these details.

A close relation to personas, scenarios, also proves imprecise. It is true that people relate to stories. But is it also true that stories are gross simplifications of reality. Again, we find literary invention masquerading as research. Very often, scenarios are a substitute for user research. It is far faster (and cheaper) to brainstorm some stories about what users might want to do, than to actually do the research to find out. As a starting point, scenarios are fine, as long as one recognizes that it is just speculation. What tends to happen is that the brainstorming is codified into requirements. Proponents of scenarios like John Carroll have caused the abstract concept of "use" to become confused with the concrete concept of "used".

Scenarios suffer from several problems. As stories, they only address the big themes, and not the minor details. The devil is in the details, and scenarios don't help there. Scenarios can indeed led to a false sense of accomplishment: the user wants to X, we offer X, so we are on target.

Another problem with scenarios is that they are based on speculations. "Suppose the user...", "the user may want to...", etc. As with other pseudo-user centered techniques such as "expert reviews", scenarios create two distortions: false issues, and missed issues. Scenarios can cause designers to worry about issues that in reality aren't a concern to users. Being based on the imagination of designers, instead of the reality of users, scenarios also miss important issues users may be concerned about.

Design researchers need to be honest about the purposes and limitations of personas and scenarios. Everyone may have a novel inside them waiting to be written, but don't use personas and scenarios as a pretext to write it.

the flexibility of paper

2005-10-09T20:48:00.000+13:00

I am working on a project at the moment that involves computerizing some processes that are currently done on paper forms. Surely everyone knows that paper forms are passe, and that great economies are gained by capturing this information electronically. Indeed there are benefits to the computerization -- the information can be accessed more easily by a wider group of people, and the data can be reused in other situations. But what is interesting is how robust paper forms can be. Rather than being a static receptacle for information, the forms I am dealing with are actually dynamic frameworks for collecting classes of information, instead of fixed data fields. If a customer has requirements that don't fit the architecture of the form exactly, the form can be amended through crossing things out, adding things on, and making margin comments. Humans can understand these complexities, but computer programs gag on them. Trying to figure out a computer form that can handle all the potential variations of customer information is proving quite a challenge.

bus system design

2005-10-08T20:19:00.000+13:00

I have always used public transport. Until I moved to New Zealand, I never even owned a car. Even with a car, I ride the bus daily. Wellington is a small city (a town really), but there is little parking, and I hate driving.

I like the idea of traveling by bus (in the absence of an underground train), but I don't like the Wellington bus system, which suffers from a couple of design flaws. A couple of events this week have highlighted that money won't fix a flawed design.

Problem one: incomprehensible fare system. Wellington uses a strange system of charging fares based on "sections." Other cities around the world charge a flat rate for a ride, or use a zoning system where it is obvious if you are in the inner zone or an other geographic zone, based on commonly understood geographic boundaries. Wellington's sections are mysterious invisible lines that cut across bus routes, slicing them into segments. You pay according to how many sections you cross, if you can figure that out. Each route would seem to have a different arrangement of sections, as far as I can determine. It is with great difficulty that one can find a map showing how sections are divided on a bus route. The Byzantine system requires a dedicated employee to get on buses to inspect tickets to make sure passengers haven't entered a section they haven't paid for. I was encouraged this week to see an expensive new signing system for bus schedules introduced. But still no information on where the sections change, and how much it costs to go from one destination to another.

Problem two: trolley buses. Wellington is one of few towns that decided to replace railed-based trams with tram-like buses, locally called trolley buses. They look like buses, they jerk around like buses (unlike the smooth ride trams), but they don't have the freedom of movement of buses. They are tethered to unsightly electric cables overhead, which means that each trolley bus must follow the one in front of it. If one trolley bus is delayed, or broken, all trolley buses behind it must wait. There is one set of cables, so none can pass. It has the disadvantages of a subway train system, except that it adds to traffic congestion at the same time. Yesterday, a rain shower knocked out the electricity for the trolley buses, though the rest of the town was unaffected. Dozens of trolley buses were clogging the streets, stranded like beached whales. Older trolley buses have a regular tendency to become disconnected from the overhead power cables while in operation, which stops the bus and requires the driver to get out and reconnect the cables, dodging oncoming traffic. Wellington is buying new trolley buses, which will hopefully stay better connected to the cables, but the essential problem of the trolley queue remains.

the three design mindsets

2005-10-02T18:39:00.000+13:00

All this talk in recent years of "design strategy" has left me cold. Companies adopt a strategy to achieve an outcome. A plan is a list of buttons to push to make something happen favorable to the company. What are the components of design strategy?

branding (how do we look?)
experience design, especially as it relates to retail (make buying fun!)
buzz and viral marketing (get people to talk about your product)
innovation, specifically shortening the product lifecycle (planned obsolescence)
being theatrical (keep moving and people won't focus)

What is pernicious about design strategy is that it attempts to confuse what the company wants from consumers, with what consumers want for themselves. I believe companies have legitimate self-interests, and indeed can have a tough existence meeting competitive pressures. But they need to address their needs in an honest way, and sometimes they don't always come clean about the boundaries of who they are and what the customer wants.

To put it crudely, design strategy is about colonizing the mind of consumers. The essential concept is to make consumers feel they are asserting their individuality by buying a product. The strategy is to conflate the thoughts of a company's marketing department with the thoughts of an individual. At its worst, it gives credence to the notion of "No Logo" (a book, by the way, I haven't read, because I imagine it as too unfair on companies, and too naive on the realities of making a living.)

Before our current infatuation with design strategy, people used to talk about "design management." Design management was a humble concept, almost boring in its intention. Basically, design management was about developing consistency in communication. Corporate identity and product design were meant to be consistent across product lines - a uniform look. Design management had its origins in the German electrics conglomerate AEG. It reached its apogee in Ulm-school followers, such mittelstadt (middle sized, family owned) firms as Braun and Gardena. Outside Germany, deign management was enthusiastically embraced by Philips, and the most Germanic US corporation, IBM. It was boring, perhaps (in retrospect), but it was honest, and people understood who they were buying from and what that company was promising. It was corporate -- indeed not flashy -- but what it sacrificed in consumer choice was offset by being direct and forthright.

Between the poles of design strategy (phony choice) and design management (corporate-level choice) is a third alternative. It doesn't have an official name, but call it craft-creative entrepreneurship. While it can be found in many places, it is most readily found in Italy. There are several distinguishing features. First, the entrepreneurial company is family-owned. There is a blood history to what the company does, it doesn't change knee-jerk with fashions. Second, the company's products are based on craft. They aren't produced in millions. The designer and maker are very near each other, not tens of thousands of kilometers away. The fusion of design and production in craft means the product has a soul. It expresses the creativity of the designer, but is not a vanity piece. Like all craft, it references a common historical language, and plays with the boundaries of what has been done previously. People can enjoy these products as the creative output of their creator, without feeling their personal identity needs to be involved. They can admire the creativity of a product, but respect that creativity for what it is. Unlike design strategy-derived products, people are celebrating the designer and maker, not making a statement about themselves, their tastes or their lifestyle. This is because the hallmarks of the designer/maker are readily evident, instead of being anonymous, being diluted by a mass production line somewhere in China.

There is growing discussion about authenticity in life and commerce. Design needs to join that discussion.

the loss of precision

2005-09-29T21:25:00.000+12:00

Few people are capable of mental arithmetic anymore. Calculators have deskilled us. That would hardly seem to matter, except that many people can't even understand what the approximate answer to a numeric problem should be, to know if they have done the calculation properly. I can't count (without the aid of a calculator) the number of times a store clerk has produced a ridiculous calculation, and has had no awareness of how absurd the answer is. If you suggest that the calculation is wrong, they simply re-key the same incorrect sequence of numbers and operations, to produce the same wrong answer. They act as though you are stupid for doubting a calculator. For example, a constant problem is when a store advertises an extra 10% off already marked down prices. It seems no one who is paid a store clerk wage is able to figure the math for that.

A similar phenomenon is happening with spelling. For people who rarely write with pen and paper, spelling becomes more difficult. I have never been a good speller myself, but I realize that very few people really are. Few people know spelling rules anymore. Spell checkers have saved us much effort, but have become a crutch. We have stopped thinking about how words are composed, and speech has become disconnected from writing. I am not a linguist, but I suspect our pronunciation is gradually becoming less grounded in how a word is spelled. We are dropping syllables as we say words we long longer need to think about spelling.

The next big shift will happen as voice recognition matures to allow speaker-independent input in noisy environments. With that, we may finally stop writing altogether, expect for formal pieces. Dictation will change how we relate to words. If voice recognition is accurate enough that we don't need to watch a screen as we talk, we may end up rambling, just as we do in ordinary speech. But we won't have a companion who asks questions to check the meaning of the rambling. If our relationship to words become more oral, then we run the risks that accompany slang. People mimic words and phrases without a proper understanding of what the phrase is intended to mean. I notice people often use slang phrases in the exact opposite way they were intended.

enterprise automation and human productivity

2005-09-27T20:39:00.000+12:00

Nearly everyone's job is increasingly defined by software, whether you work in a call center, as a currency trader, or a graphic designer in an ad agency managing a job workflow. If you use computers to work, sooner or later you will be drawn into a system to manage workflows, and these systems will be "rationalized" to improve productivity. Don't believe that because you use your brain for a living, or need to exercise creativity to do your work, that you are exempt for the march of enterprise automation.

Our inability to understand and measure the productivity of computer workflows is one of the most pressing issues facing modern society. Most of us use computers in some way to produce services of some sort. The logic of business to reduce costs means that corporations are always seeking ways to do more with less. Automation is the holy grail of cost reduction, and new applications to automate tasks involving computers are appearing all the time. What nearly all these applications promise is that work can be done faster, with fewer people. Often these applications do increase throughput, but it is not always the case that they improve productivity.

Enterprise automation -- using software to automate services across an enterprise -- very often repeats the same problems that accompanied industrial mass production automation. Before the development of lean production, manufacturers focused on almost exclusively on increasing throughput (output per work and/or per hour). They looked for ways to increase how many autos would be produced in an hour, and how to reduce the number of workers needed to produce those autos. The solution was to standardize production of common products based on interchangeable parts. This is exactly the approach currently used by enterprise applications.

In the case of auto production, the mass production system collapsed in the late 1970s. It proved unable to cope with the increasingly diverse demands of consumers (users). And the relentless automation caused workers to stretch beyond the limits of human capabilities. Harried workers did not notice quality problems when they were focused entirely on meeting production quotas. They saw the demands of the production system as dumbing down their work. They burned out.

As the case of auto production automation illustrates, productivity is about more than just getting faster, and using fewer people. Unless and until an enterprise can eliminate using people altogether -- more often a fantasy than a reality that will ever happen -- it needs to keep the cognitive and emotional needs of workers in central perspective when attempting to automate. People need to be engaged mentally in their work, and in control of the pacing and decisions. Without these, quality suffers, and productivity is elusive. The example of lean production in manufacturing, which uses workers to perform flexible tasks, and lets workers define tasks themselves, points to how the future of enterprise software needs to evolve.

behavior verses preferences

2005-09-24T21:25:00.000+12:00

Is the future of user centered design watching people, or probing people? When selecting an approach, a key question is: how reliable is behavior, and how reliable is preference?

Traditional usability engineering admonishes researchers to "watch what people do; don't listen to what they say." Ethnography also can stress the need to watch what people do in naturalistic settings, and to discount verbal introspection from users. It can deviate from straight behaviorism by asking users questions about why they do what they do -- it tries to overcome the black box approach. Emotional design research borrows far more from traditional market research by exploring preferences instead of behavior. It may be wary of the validity of verbal declarations of preference, but it nonetheless seeks to develop a model of the user's inner mind, and his or her wants. Many designers of new products argue that past behavior with mature products is a poor guide to understanding what people really want from future products.

I think the variability of people is well illustrated by how they behave on the job. I just finished listening to a BBC Radio 4 program on psychometric job testing. When I lived in the UK, I always thought the extensive use of psychometric testing to screen job candidates rather odd. If you visit a UK bookshop, you will find shelves of books on how to take, and "pass," psychometric tests. The whole exercise degenerates into a guessing game of finding and providing the socially acceptable answer. The flaw in psychometric job testing is the notion that one's stated personal preferences somehow reflect one's future job behavior. The first problem is that what people say they prefer may not be what really prefer. This is a well known problem with any probe. The second problem is that people's preferences may have little bearing on people's behavior. Whether someone says they prefer mercy or justice does not predict if they will fire an incompetent employee. There are many other factors that come into play (perhaps feelings toward potential lawsuits.) And it also confuses the idea of global personal preferences with role behavior. We have all seen examples of the kind grandfather/ruthless executive.

Probes may work in the absence of social influence and role associations. Some products have fewer social and role associations than others, but all products have some (unless intended for hermits.) People may be less able to manipulate their nonverbal responses than verbal responses to probes, but I would doubt their responses are entirely involuntary and thus "objective."

Ethnography is potentially powerful for accounting for the influence of social factors. But by subjecting observation to context, it is not possible to develop a global perspective on people, finding their core life motivations and preferences. Only traditional usability can pretend to offer a global perspective on users. It does this by ignoring preferences, and looking only at a narrow range of user behaviors that are consistent across contexts.

election usability: is it about close elections?

2005-09-24T17:32:00.000+12:00

I doubt many people outside New Zealand are aware of the recent elections here, given that they fell on the same weekend as the headline-grabbing German and Afghan elections. To catch you up: New Zealand has divided election outcome, with both major parties gaining nearly identical share of votes, and neither in a obvious position to form a majority coalition. It is not so dramatic (yet) as Germany, but nearly so. Incidentally, while I'm no expert, I understand New Zealand borrowed extensively from Germany's electoral system when devising its sometimes confusing Mixed Member Proportional (MMP) system NZ implemented a decade ago.

As the election outcome remains unresolved, all parties are awaiting the results of overseas votes. This is no small matter, as at least 10% of New Zealanders live overseas (in Australia mainly.)

On the surface of things, New Zealand's elections would not seem the material of usability problems. New Zealand uses quaintly old-fashioned paper ballots, with simple tick boxes to indicate one's choices. It is so low tech it makes Afghanistan's multi-page lists with photo mug shots of candidates look high tech.

Paper is great, until it meets the web. Now, all those expat New Zealanders were given an opportunity to submit their paper ballot as well, but they had to use my least favorite software program to do so. I read in the Dominion Post today that some expats are complaining that they couldn't read the election form in Acrobat reader, which rendered the names of the candidates as blank. The Green Party in particular is complaining about Acrobat, as it stands to gain a seat in parliament is it gets a few more votes, or alternatively, lose all its seats if it loses a few votes and falls below 5% of total party votes. (Some commentators assert that the Greens get a disproportional share of votes from expats -- I have no way of knowing.) Acrobat Reader might just have the power to throw the outcome of the New Zealand elections one way or another.

What to me is even more strange is how the overseas votes are received. After printing out the ballots in Acrobat reader, voters are expected to fax them in. I can see at least two usability problems with voting by fax. First is fraud. In an age where identity theft seems easier than ever, how on earth do the election officials verify that the ballot is cast by the real person entitled to cast the ballot. I don't know what arrangements where made -- there must have been some -- but it would seem far short of the purple thumbs used in the Afghan election. The second usability problem concerns knowing that one's ballot has been received. Ballot by mail is not foolproof to be sure, but it is probably more reliable than sending a fax. The rule of thumb for any important fax is to phone to verify that is was received, and got into the right hands. How frustrating it must be to fax a ballot, only to wonder if it went to the right fax machine.

what does this sign mean?

2005-09-15T10:01:00.000+12:00

Here is an actual question from the New Zealand driving theory test.

What does this sign mean?

A) Children's playground ahead

B) Railway station ahead

C) Railway crossing ahead

D) Railway museum ahead

I am inclined to want to choose a non-existent "E": all choices seem plausible. Since the train does bear a striking resemblance to Thomas the Tank Engine, "A" might be a good choice. Since it a rather old looking train, "D" might work. The train seems like it is going some place (notice the smoke blowing in the direction that train has come from) so maybe I should follow the train to the railway station. Since the sign is yellow, maybe it is warning me about something, so "A" or "C" might be the right answer.

For the curious, I haven't yet seen a train that looks like the one pictured operating in New Zealand.

does 'best practice' make us zealots?

2005-09-12T10:25:00.000+12:00

Most any successful businessperson or politician will tell you that the art of getting your way is to bend. Ultimatums along the lines of "my way or the highway" don't win friends or influence people. But unfortunately, UCD has developed a puritanical zealotry that is inhibiting its adoption in the business world.

A practical problem for most any religion dealing with a changing world is the presumption that a single truth exists, and that the truth is eternal. UCD practitioners may hesitate at the notion that they follow a faith, rather than represent the deepest enlightened reasoning that can be applied to a topic. But while reason does dominate the surface of discussion, deep philosophical assumptions shape the pattern of dialogue UCD practitioners engage in with others. These assumptions are rarely questioned, they are articles of faith, which (strangely!) aren't accepted wholesale by people outside the UCD flock.

One of the biggest sacred cows in the UCD world is that user centered research and iterative design must begin from the inception of an application. This idea reached the status of canon law by the early 1990s. The logic of the law seems unassailable: by involving users from the start, you get the application on the right path immediately, and you save time and money in the process. Indeed, early and constant user involvement does exactly those things in certain circumstances: when you build an application from scratch, and create it to fit the specific needs of target group. Unfortunately, those circumstances are getting less and less common.

When the law of "UCD should drive application development" came into being, the software development world was radically different than it is today. At that time, applications were developed one by one, often using procedural programming. Then modular software, object oriented programming, off-the-shelf enterprise applications, and a raft of other software development innovations burst on the scene in the 1990s. Software vendors discovered the key to reducing software costs was standardization and re-use. Vendors figured they could maximize return if they could re-use code they had already created from another application. If it wasn't exactly what they user needed, so be it: at least it was cheaper.

Once standardization and re-use dominated the software development world, UCD lost the argument that it is most cost-effective to start with user requirements before writing any code. Paradoxically, because of the rise of the Web, UCD practitioners were largely unaware that the UCD development cycle was becoming marginalized in application development. The Web demanded comparatively little input from application developers, giving usability a freer reign. Involving users from the start of the Web project worked easily. Until recently, Web sites have been shallow, involving a fairly dumb interface attached to some fairly basic databases at the back-end. Because the amount of code in Web sites was not overwhelming, modifications based on user research and iterative design could be accommodated without too much a kerfuffle.

The transition to Web applications has given application developers much more power. UCD is marginal when it comes to influencing many of the key decisions that affect usability, such as what CRM system will be used to handle customer data. These decisions are made by IT systems people and business analysts, generally with little involvement from UCD practitioners. But it is these key back-end elements that are shaping the user experience, because they define what the user can and cannot do with a Web app.

When we step back a step, we find even less UCD involvement in the development of enterprise applications that power Web apps. These applications involve off-the-shelf components that drive almost any conceivable aspect of an organization, from personnel to scheduling to customer service. Despite the enormous impact of enterprise applications on users both inside and outside of organizations, UCD practitioners generally have not been involved with shaping what these applications do, or how they do it. By and large, enterprise applications are created in the imaginations of business operations specialists, with hardly any user input. As an afterthought, users are brought in to test the development of the interface. The consequences of the situation are astounding: UCD has no involvement in the development of software representing billions of dollars of spending by corporations.

The usability profession to a large extent doesn't even understand how marginal it has become. I hear some usability people talk about working on their company Intranet, as though it where just another Web site. Their involvement is limited to rearranging chairs: a bit of information architecture work, and figuring where to put links, based on the specifications presented to them. But UCD did not drive the development of the application, in violation of the sacred laws of UCD. The application already existed. It was bought from SAP or Oracle or IBM, specified by an in-house BA and modified by systems people from a implementation partner.

I am not convinced many usability practitioners are necessarily interested in the mysterious working of the applications. They are happy to stick to the interface, where the issues are far easier to notice and deal with. Applications also involve dealing with an alien culture, people who complain about changes and don't seem excited when talking about user experience.

Some UCD practitioners do realize that users aren't going to gain proper value from an application unless the application reflects their prorities accurately. Many enterprise applications fail users and need extensive change. But UCD orthodoxy hardly equips us with a road map on how to fix the problem. If you follow the UCD script, you end up saying: "Well, see, the problem is that you did this all wrong from the start. Before you did anything, you should have called me in to do user research, then we could have designed a special application to meet the unique needs of the user population." Anyone hearing that would assume you were arrogant and obstructionist.

It is time to reality-check notions that application development must start with UCD. I empathize with these sentiments completely, but I question their practicality in today's business world. UCD has increasingly advocated as best practice the development of bespoke solutions for users. Meanwhile, in the hard-nosed world where money talks, businesses have embraced off-the-shelf solutions for a variety of reasons related to purchase cost and maintainability. The philosophical differences between the approaches couldn't be wider. The question is, are there practical solutions to provide a way for both sides to work constructively toward common goals without compromising their priorities?

I have been developing a framework I am calling "context-driven application re-engineering" to assess the costs to businesses of poorly functioning enterprise applications, while providing a pathway to making those application work better for users. To get the needs of users represented in the reality of off-the-shelf enterprise applications today, I commit heresy by dropping the "do it right from the start" attitude of the UCD profession. We need to recognize how marginal we are becoming, and face this reality if we hope to change it.

person-to-person human computer interaction

2005-09-09T08:43:00.000+12:00

Mobile communication is fast moving from being exclusively aural to being visual as well. With camera and video phones, we don't just talk about a situation to someone far away, we can show it remotely. I predict mobile visual communication will introduce radical new work patterns that could require establishing a new interaction paradigm in HCI: person-to-person human interaction with computers. Sorry if that sounds confusing, bear with me.

Visual cell phone communication allows managers to diagnose and instruct field staff on how to solve problems involving visual analysis. The highly paid expert doesn't have to burn precious time traveling to field locations. He can see the problem remotely, and have a lower paid novice carry out his instructions. Suppose the problem involves fixing an interactive device, say a vending machine, then two sets of eyes are looking the problem, one at the location of the device, who can touch the parts, another remote, who can only see the parts. There are two levels of interaction happening: the service technician's interaction with the machine, and the expert's interaction (via verbal instruction to the technician) with the machine. A problem arises if the two parties describe or see things in different ways.

Although corporations have focused extensively on remote diagnostics, most of this activity involves machine to remote machine, or machine to remote human, communication. To the extent no one needs to be physically present to carry out the diagnosis and repair, such a solution is wonderful. But in many situations, having someone actually handle something physically is necessary.

Everyone has the maddening experience of waiting for a service technician show up to deal with an installation or to make an adjustment. Consumers hate the waiting, and corporations find house calls expensive. I envision that soon we will use picture and video phones to get instructions from companies on how to adjust our broadband setup or our digital television wiring or satellite dish.

Currently, calling customer service or a help desk about a technical problem, without the ability to provide visual materials to orient the remote helper, is a frustrating experience. Much time is wasted just finding common understanding of what is happening and how to do trivial actions. Visual feedback will reduce that gulf, and may encourage greater use of remote advice.

While the issue of remote instruction to other people on interaction is now new, I am not aware of literature dealing with the topic. Traditional HCI assumes one person is doing both the thinking and the interacting. Computer mediated communication is generally focused on the process of communication, rather than interacting with a device. Some contextual research has looked at group problem solving and interaction with a device, but generally with people who are collocated. What I am calling person-to-person HCI involves split cognition, mediated communication, but only one party interacting with the device. If you are aware of work in this area, I'd be interested to learn of it.

cognitive-emotional complexity and customer value

2005-09-01T13:54:00.000+12:00

The relationship between simplicity or complexity of a product or service, and value a customer derives from the choice they are offered, has never been less clear cut.

Complex products/services can command a premium. People want choice/customization, and are willing to pay extra for it. (Compare a design-your-own holiday with a cheaper "package" holiday.)
Complex products/services are deemed a turn off. People feel overwhelmed by choices they have to make, and choose the first thing that seems like it minimally meets requirements (satisficing) or they simply ignore options. (Everything from investment plans to cameras fall here.)
Simple products/services are deemed low value (for example, open seating tickets at a concert.)
Simple products/services command a premium (more rare than we would like to believe, but Bang & Olfusen or Apple present the illusion of simplicity while charging a premium. For many people the illusion of simplicity doesn't detract from the underlying sophistication of the products, though both brands have encountered charges of being toy products.)

Making products and services simple is not the answer. People are often interested in possibilities offered by complexity, they just don't want to be overwhelmed by it. The limits of people's interest in choice is a major blindspot of free market liberals who believe unlimited choices make people happier. True, people want choices, but they also wince at choices that don't seem personally meaningful. In addition, when too many choices are available, people can feel emotionally drained, fearing they will make the wrong choice, and cognitively exhausted, when they have to compare too many options.

The challenge for designers is to offer products and services that demonstrate extra value, and are meaningful. Generally, people are willing pay more for products and services that reflect more differentiation or customization. As a consequence, businesses offer consumers an unparalleled array of choices in the market, with many possibilities to customize a purchase on the Internet. But choice for choices sake runs the risk of creating a "why bother?" backlash.

The corporate rush to higher value products and services is forcing greater complexity on consumers. ATMs dispense cash, but maybe banks would make more money if they dispensed theater tickets as well. And Lottery tickets. Why not dispense lottery winnings at the ATM too? Soon someone decides there is a market for machines that only dispense cash -- people will pay extra not to stand in line behind someone buying lottery tickets.

Some hotels offer a choice of pillow types for guests. Lovely touch perhaps, if that were the only decision the guest needs to make. But in the self-serviced economy, people are asked preferences about many minor details, only a couple of which matter personally to an individual. Like vampires, some corporations collect personal information for impersonal reasons -- faux customization serves as cheap market research.

The alternative to asking people to provide preferences each time they order is to capture these preferences in a profile. Even creating and maintaining a profile is too much work. I avoid registering for web sites and frequent buyer programs where ever possible. So far at least, helping computers develop some intelligence about our preferences is still a net investment of effort by users. Perhaps in the long run this will change, but I can not overly optimistic about the next ten years at least.

Although cognitive complexity is a symptom most prevalent among interactive products, other more humble products are seeking to become more complex, higher value, and more scary to purchase. Once simple white goods like stoves/cookers are now industrial machines with idiosyncratic design languages that match other similar looking white goods to form a cohesive kitchen "system." Woe the poor person who learns through use she hates the brand she has spent thousands of dollars or Euros on. The opportunities for buyers remorse keep escalating.

The future for user centered design never looked brighter. People's time is always limited, the total emotional capital they have available to invest in consumer decisions is limited as well. Our cognitive capacity to process information and juggle decisions is perhaps growing modestly, but is still outstripped by the growth in choices demanded of us. Meanwhile, corporations are addicted to the notion that offering consumers more choice is the best and only strategy to gaining market differentiation and achieving success.

services as commodities

2005-08-31T17:43:00.000+12:00

What do people want from services? We live in an increasingly post-material age, where services are the dominant "stuff" we consume (if we look at our spending). There is a lot of money to be made for companies that offer services they way people want them. The questions is, what matters most to people? Do we want services to be special, satisfying, cheap, reliable, flexible...?

Designers are beginning to look at "service design" as a design discipline, focusing on making services special (experiential), user-responsive, and coherent. The logic of service as a design discipline holds that if people spend a lot on services, they surely must want to obtain a unique experience for their spending.

Business, it would seem, have little enthusiasm for considering service a delicate object, to be dressed up into something special. In the view of business, service is an economic liability that needs to be tamed.

IBM is leading the charge. Paul Horn, SVP for research at IBM: "The next big thing is in the general area of something called services science. It's the componentisation of business."

Note the metaphor: Service should be a science (not a craft, a discipline or an art.)

Horn notes: "Services science would merge technology with an understanding of business processes and organization, a combination of recognizing a company's pain points and the tools that can be applied to correct them. To thrive in this environment, an IT-services expert will need to understand how that capability can be delivered in an efficient and profitable way, how the services should be designed, and how to measure their effectiveness."

IBM's website notes: "industrial and academic research facilities need to apply more scientific rigor to the practices of services, such as finding better ways to use mathematical optimization to increase productivity and efficiency on demand."

IBM is enlisting academic collaborators to unlock an understanding of how to achieve efficiency in services. One IBM collaborator, Arizona State University, proudly boosts that services aren't about "platitudes", its about now about science.

Two visions of services. Both addressing a concern of people. Is the notion of service as experience enhancement in opposition to the notion of service cost reduction? Possibly, but not necessarily. Both designers and business people need to work the the ambiguity of services. People are contradictory: they spend great sums on services, and want value, but still want to be treated like a king. Some creative thinking is necessary to make that possible, but I imagine it is possible.

PDFpod

2005-08-30T16:21:00.000+12:00

I have been searching for a system to handle my massive PDF collection, and may have found a solution that works. A couple months ago I bought a Mac mini, intrigued by the ability of "Spotlight" search engine to chew through PDFs. I have loaded over a thousand PDFs on the Mac mini, and am pleased to be able to locate files I haven't seen in a while.

Apple's Preview is far better than Acrobat Reader. It loads faster, and avoids several annoyances of Reader, such when Reader disables text copying because someone set the file that way. Someone needs to develop an open source PDF reader for the PC. It is a scandal what garbage Adobe is allowed to inflict on us.
I can annotate PDFs within Preview, with no extra software required.
Spotlight does decent job searching, but learning what it can do was a pain, since most of its functionality is undocumented. Spotlight can do very basic Boolean searches (AND, OR, NOT) and search a single phrase, but cannot do any combination of the above (unlike Google). The search syntax is a bit wonky, Unix-like, but I can live with that.
I wish Spotlight could do more, perhaps the functionality the venerable program AskSam. Proximity searching, fuzzy search, nested searching would all be nice. I would also like to create sets of results to join or filter.
I can search on the annotations of my PDFs, which is cool.
I would like to preview my search results automatically when I open the document.
I can apply tags to my files, though this took me ages to figure out how to do (another undocumented feature). Someone has kindly created a widget to give an overview of tags used and number of documents associated with each, which allows deep linking to a document. Very Nice. I wish tags could be phrases -- instead one needs to create computerish tags such as userTesting.
Much fuss is made of "smartfolders" associated a search profile, whose contents change dynamically as documents are added or subtracted. For my purposes, it don't see any use for smartfolders -- I don't particularly want to look at folders at all. Also, the search complexity of Spotlight is too limited to create intelligent automated indexes. I would like something that worked like the amazing program 1980s program Lotus Agenda, which parsed and categorized content automatically based on wonderful profiling hierarchies. With such a feature, I could zero in on the level of detail I sought, choosing a broader or narrower term.

Overall, Tiger offers some valuable capabilities. At the same time, I sometimes feel like I am trying to buy a necklace but instead have been given a needle, thread, and bowl of popcorn and told to make my own.

daft downloading

2005-08-29T12:28:00.000+12:00

Seems I am forever having to visit websites for "updates" of software. Even though some software will download updates automatically (assuming my spyware and virus software allow even that), there still seems no escaping the laborious visits to a website to get updates necessarily to keep things from crashing. Two things that really annoy me:

Item One: You download the "latest" version of the software, and install it, and reboot your computer, only to be told, as you boot up the lastest version of the software, that there are updates available. You think: I was just on the site, spent 10 minutes going through countless screens clicking "next" and "accept", and I still don't have an up-to-date version of the software. Guilty: Adobe Acrobat Reader.

Item Two: Your software crashes, and you are sent to the website for an "update" (really just a patch for the buggy software). You download the update, and install it. The vendor has the bad manners to ask you to read and agree to an "End User license Agreement" for the patch, as though it represented some big favor for which the user must offer thanks and humility. Guilty: Microsoft. Why some updates can be downloaded automatically, but others require an EULA, is something only lawyers can understand.

"no touch" service: there is no escaping context

2005-08-25T17:01:00.000+12:00

Software is increasingly making some of the most important decisions affecting your life: how you receive medical treatment, if you get a mortgage, or if you qualify for insurance. According to IT guru Thomas Davenport in the current issue of the MIT Sloan Management Review, "decision making automation" is no longer a pipe dream, it is "coming of age."

Automated decision making capabilities "are embedded into the normal flow of work and they are typically triggered without human intervention." Davenport writes that the goal of businesses is to have processes executed with "no touch" treatment -- no human intervention required. Currently, some "exceptions" to automated rules require human attention, but businesses are working to eliminate these altogether.

One can understand the motivation of businesses to reduce costs through automation, but there is a cost to users/customers that isn't pleasant. For example, while generally positive about the possibilities of automated decision making, Davenport concedes that hospital managers punish doctors and nurses for "overriding" automated decisions.

Automated decision making can run roughshod over users and customers. Corporate managers need to think carefully about the stakes involved. Davenport mentions managers need to define the context and limitations for automated decision making, but he doesn't specify how that is done, other than to caution firms not to create an application that will get one sued for malfeasance.

Too often, automated decision systems are implemented without enough thought to context and limitations. Decisions involving people, by definition, involve many variables, because people are endlessly complex. If you design a mortgage decision application, you can probably get a good approximation of who qualifies for a loan into a software program. But it is only an approximation. We have all heard funny stories about qualified people turned down for something because they didn't meet a rigid rule, even though common sense told you the rules shouldn't be a constraint in their case.

Automated software can't cope with unanticipated or uncommon exceptions. Common sense can cope with such exceptions, often easily. But it is difficult to capture common sense in "knowledge management" software. It involves too much tacit knowledge, often from outside the immediate work domain.

Today, knowledge engineers are draining the brains of people, trying to codify how they think. The result, even if credible, are often brittle. Circumstances are always changing, but software decision engines can't necessarily adapt to these changes. Davenport notes:

As the ranks of employees in lower-level jobs gets thinner, companies might find it increasingly difficult to find people with the right kinds of skill and experience to maintain the next wave of automated decision systems.

Imagine how unresponsive industrialized service may become. Suppose someone with an emergency is stranded in an airport, due to a plane delay. Software reassigns people to alternate flights, using tested rules of fare paid for the ticket, and loyalty evidenced by frequent flyer miles. The software makes no allowance for the person in an emergency, and the person may not even be able to talk to someone about his situation.

When automation of decisions affecting peoples lives goes too far, it will create some nonsensical situations. The aggrieved people whose situations where not considered by the requirements engineers will be very, very mad. Compared to common sense, software will never look so stupid. Companies will never look so uncaring.

Companies that don't want to be humiliated, or sued, need to do some deep contextual research if they are implementing automated decision systems that have the potential to be more than a mere annoyance to customers.

warren buffet on usability

2005-08-23T13:39:00.000+12:00

"Start out with failure then engineer its removal."
Warren Buffet, speech at Emory Business School, 1991

convergence and requisite variety

2005-08-22T11:38:00.000+12:00

What do you do when a video call interrupts your viewing of a streaming news clip that you are watching on your mobile phone? I faced this situation recently while trying out a 3G handset. I learned that the connection for the news clip stream got broken.

As network operators and handset makers cram more functionality into a device, users face a new kind of challenge. While device complexification is almost an iron-clad law of electronics, recent developments in mobile devices up the stakes. Unlike with standalone devices, mobile users don't have the option to ignore the stuff they don't understand how to use. Network connectivity forces users to deal with interruptions from others who want to communicate in an increasing range of ways.

Multifunctional mobile devices, and embedded pervasive computing, point to a world where users will have interaction foist upon them, ready or not. The "law of requisite variety" suggested by cybernetic theorist Ross Ashby in the early 1950s is highly relevant. The law states that users need at least as many kinds of controllers available to them as variety of situtations they need to control. For some reason requisite variety has received scant attention in usability and HCI literature. One reason may be that traditional HCI has viewed the user as initiating interaction with a machine, rather than having situations thrust on him or her.

One of the earliest thinkers on the topic of convergence was the late NEC chairman Koji Kobayashi. Twenty years ago he wrote a book called Computers and Communications where he argued users would someday use phones tell computers to act on their behalf, doing smart work like translating conversations in real time. Kobayashi's answer to requisite variety was to hide it from users and have computers deal with the complexity presented by convergence.

Kobayashi penned his vision during the expansive 1980s, when Japan was funding 5th generation computing research aimed at creating rational AI machines. We are still far from realizing that vision.

For now, the chore of managing the complexity associated with convergence falls on the user. Requisite variety tells us there is no escaping the need to give the user ways to manage the complexity. Previously, rich functionality was something power users discovered, and mainstream users ignored. Now, power users, when contacting mainstream users, will force the mainstream to confront functionality they may have had no intrinsic interest in discovering. The need for good usability has never been greater.

democracy is hard work

2005-08-20T15:34:00.000+12:00

Ever since the infamous "butterfly ballot" in the US 2000 presidential election, usability professionals have taken a keen interest in elections.

New Zealand will hold parliamentary elections next month, and I have been interested to read a number of people mention that many voters are "confused" about how the NZ voting system works in practice. The confusion rests not with a ballot per se, but how the ballots are counted and what consequences result.

About a decade ago, New Zealand adopted a voting system known as MMP, which gives people two votes, one for a member of parliament, another for a political party. After the last election, a government commissioned survey (2003) found that only half of voters understood that the party vote determines the composition of parliament.

A Recent survey shows understanding is improving, but still falling short of what is ideal.

for every two people who say they find MMP easy to understand, one says they find it difficult to understand
25% of people incorrectly believe that their electorate vote determines the share of seats parties have in parliament.
70% don't understand what "threshold" a political party needs to be included in parliament.
less than 20% understand all the major components of the MMP system: they either cannot correctly identify the party vote as the one that determines the share for each party in Parliament and/or both parts of the threshold.

From the perspective of usability, MMP can be considered according the following criteria found in ISO 9241:

Task adequacy: are there any unnecessary steps in the MMP election formula?
Self-descriptiveness: is it transparent to voters how the government is formed? MMP has some distinctive features such as "list" candidates who can become members of parliament without standing for electorate seat.
Controllability: do voters fell they are in control of the outcome?
Conformity to user expectations: does MMP correspond to how voters imagine elections work?
Error tolerance: What happens when a voter votes for someone who switches coalition alliances?
Flexibility: MMP is a new system. Will it ever be modified, or is it set?
Learnability: as NZ voters gain more experience with MMP, will they understand it better?

I'm not sure any voting system would satisfy all the above criteria, which were never meant to evaluate voting systems, but it is interesting to ask the questions. Democracy is hard work.

mobile applications: just-in-time, not simply anytime

2005-08-20T13:55:00.000+12:00

As of last week New Zealand has two 3G networks now running, so in theory we may see development of nifty applications that will make life richer and more productive while on the go. But I am cautious this will happen. The applications and content I have seen so far for 3G looks like it is designed to kill time, rather than make time more productive.

Mobile applications promise to deliver "anytime, anywhere." But people don't just want anything available at anytime at any random place they happen to be. What they want is specific content relevant to specific needs in specific circumstances.

One big 3G offering is video clips of movie trailers. I can see scenarios where that could be useful to have on a phone. Say you were with a group of people in a restaurant, deciding what movie to see. One person speaks enthusiastically about a film she saw a preview for, but others don't know about it. Download the trailer, and everyone can see it and decide if they want to go. So far, so good. But the decision is only half made. The group needs to find a cinema showing the film, get the schedule, and most importantly get tickets, which might be sold out. The entire process is wasted if after making a decision, and finding a nearby cinema showing at a convenient time, the film is sold out.

I'm a last minute planner, and get frustrated when trying to do seemingly simple things like eat a meal or watch a film on short notice. In Wellington at least, I can get an odd stare when I ask if there are tables available at an ordinary restaurant. Did I make a booking? Not me, I think about food when I'm hungry. I want to call up a list of restaurants near where I am, and see which of them have tables available. Why can't 3G help me avoid being a hungry nomad wandering from restaurant to restaurant looking for one with a vacant table? Such an application would tap into the power of "presence": showing one's availability to interact with others. A restaurant could indicate it has tables available, if it could dare to disclose the fact that some nights it is not fully booked. Generally businesses like to hide information about the availability of supply, and create the illusion that supply is scarce. But eBay, Travelocity and other online markets show that consumers want to know availability.

So far, even "location-based services" around the world are few in number; New Zealand has none at all. Location-based services are fine for finding a 24 hour ATM/cash point, but generally don't go far enough. What is needed is time-based, location-based services. People want to know what they can do nearby, at this very time.

Time-killing mobile phone applications like games and music are fine for teens fleeing their parents' house. Time-enhancing applications are what the rest of us will need to embrace 3G.

is work boredom an existential inevitability?

2005-08-11T09:37:00.000+12:00

Today's Washington Post contains an article entitled Boredom Numbs the Work World. A cynic might comment, so what else is new? Isn't this just filler for a slow news day, as those living in the northern hemisphere are preoccupied with thoughts of summer holidays? But I would encourage the cynics to think a bit more about something so endemic it escapes serious discussion. The Post article notes:

boredom is a condition that can be more stressful and damaging than overwork, according to those who have studied the issue...a lack of autonomy and a job that has very specific instructions -- hits workers from the highest to lowest echelons of the working world

I don't have good statistics to cite, but I would argue that work-related boredom is increasing, as sociological and business trends move in opposite directions. Shoshana Zuboff and James Maxmim note in The Support Economy that the global rise of "psychological self-determination" is clashing with the relentless industrial logic of resource reduction, which seeks to control the scope of employee work with greater precision. As people become increasingly educated and socially independent they want more mental stimulation and latitude in their working lives. At the same time companies of all kinds want to make jobs more efficient and predictable, reducing work to a formula. Even though some companies have attempted to introduce "quality of work life" programs, these have failed for a multitude of reasons, mostly because they implicitly or explicitly undermine the authority of management.

In America at least, the corporate response to boredom has been to treat it as an attitude problem of employees. Zuboff and Maxmim cite a skills survey showing 80% of US employers "emphasized the importance of workers' attitudes and work ethic, while only 5% emphasized the cognitive abilities and growing skill demands." The message seems to be: leave the thinking to us, just smile and do as told. True, employees make decisions and are accountable, but they often have no real authority to make creative choices outside of established procedures.

While attitude can play a role in coping with job boredom, it is not a reliable strategy for addressing the sense of powerlessness many feel. Even the most devoted Medieval monks, who strived to be pious employees, suffered from a condition known as acedia, or spiritual burnout. Attitude approaches often led to burnout and more stress, as the cognitive dissonance of the boring reality one experiences clashes with how one is supposed to imagine that reality.

Rather than try to redesign people to fit a job, what is needed is to redesign jobs to fit the psychological needs of people. Human centered design needs to be applied to all kinds of work.

The Post article mentioned how airport x-ray scanning personnel are rotated every 30 minutes so they can maintain concentration when watching for dangerous articles. Such an approach is a small example of how human factors approaches can be applied to reduce boredom. For safety-critical work, removing boredom is not just something nice to do for the sake of workers, it is essential. But these approaches can be applied to all kinds of work, not just safety-critical ones.

An obscure discipline called macroergonomics is looking at how job boredom is a serious productivity issue. (Macroergonomics is the study of the design of work systems to fit the physical and socio-cognitive needs of individuals. Organizational psychology, in contrast, typically looks at more fuzzy issues such as organizational climate.)

Mitsuo Nagamachi at Hiroshima International University, for example, has done creative work on how jobs can be redesigned to improve employee satisfaction and productivity. The effects of monotony are not just subjective: a brain's EEG frequency differs when doing monotonous tasks compared with complex ones. In one example, Nagamachi describes how the employee union at a Japanese department store volunteered, and fought hard, to be allowed to increase the complexity and discretion of employee work, with a net effect that productivity increased. The transformation required the store to train everyone in merchandise ordering, when the function had previously be done by management. According to the logic of resource reduction, a centralized ordering function is more efficient. But devolving responsibility had spill-over effects not predicted by traditional efficiency analysis.

Much of the work looking at job redesign and productivity is done in places like Japan and Scandinavia, where employment relationships are longer-lasting than in much of the rest of the world. When employees work for the same employer for many years, it makes more sense for employers to be concerned with employee welfare, and to take risks to invest in new approaches with long term payoffs. But overall, the trend worldwide is for job relationships to be shorter. This shortening of employment is a consequence of the "psychological self-determination" mentioned by Zuboff and Maxmin (employees want the freedom to change jobs), and of the business logic of resource reduction, whereby companies want to minimize costs by keeping staffing flexible.

The needs of individual workers and the companies that hire them are moving in opposite directions, with dim consequences for both. Workers change jobs often, partly to flee boring work. Companies strive to make jobs as simple as possible, so they can reduce the expensive knowledge and training necessary to do the work. The more employee turnover a company experiences, the more it tries to simplify the work, so it can make new hires instantly productive. But at the same time, the simpler the job, the more boring it is, and more likely people will leave. From the employee perspective, the more inclined he or she is to "vote" with her feet and seek new thrills in new jobs, the less likely employers want to invest in employees to make their work more stimulating. Even at the highest levels of organizations, job turnover can be high (just look at the six-month tenures of many CEOs.) Employee turnover forces organizations to worry about job continuity, which encourages rigid work systems.

How to resolve the conundrum of job boredom is not obvious. But it must be addressed, and I am optimistic can be. When one asks business people what keeps them up at night, it often is the worry they lack the creative nous to survive the crushing pressure of competition. Let's hope the need of organizations to reinvent themselves will force them to confront how to make work interesting. Doing so will stimulate the mental energy of employees to develop creative solutions to competitive challenges.

trend to watch: usage studies

2005-08-10T08:27:00.000+12:00

A very interesting recent development has been the marriage of device-use logging data with qualitative methods to develop a more complete and rich view of situated data. Earlier this year CHI held a panel, "Usage Analysis: Combining Logging and Qualitative Methods." Think of it as updating the unobtrusive measures approach pioneered by Eugene Webb some 40 years ago.

The approach brings grounding to observational methods. Observational methods are resource intensive, which means that "exploratory" observational research is often not efficient. Rather than looking at everything, suppose one could focus observation on specific issues that you know seem peculiar, and you would like to know more? Log data might offer guidance for focusing research.

Analyzing log data has become standard practice for web sites, but the possibilities are far broader. Server logs exist not just for web sites, but other server-hosted applications as well, which can be an interesting window into the behavior of remote users, especially mobile ones. Client-side logging would seem to generate too much data for sustained exploratory analysis. But one can choose to automatically log only certain events, if one is interested in looking at a particular behavior or application. Something as simple as a cell phone call registry contains potentially valuable information. In addition to server and client based information, the telecommunication network captures interesting usage information, such as who was called, duration of call, or data file sizes. Such billing information can be easily mined for patterns. The information from all these sources can reveal screen interaction data, user activity data (What applications does the person use? At what locations was the person?), and social interaction data (With whom does the user communicate?).

One powerful benefit of log data is that it is time-stamped. One gains insight into how people spend their time. One can also correlate different events, to examine how people juggle tasks, deal with interruptions, or work with colleagues. I can even imagine tying log data to other time-stamped information. Suppose you had a networked self-service kiosk in a public space. You notice from server logs unusually heavy usage at a certain time. You might be able to review closed circuit video of that same time to see how customers were dealing with situation.

As devices continue to gain functionality (GPS, video, etc.) the potential for log data will expand even more. Such data can provide a "big picture" view of behavior, and also provide a springboard for follow-up contextual research.

we've noticed that customers who...

2005-08-08T16:04:00.000+12:00

I am starting to get too much spam from Amazon. Typically, the email says "we've notice that customers who have bought X have also bought Y." Lovely for them. What the hell does that have to do with me? Very little, it turns out.

Last week I get a herd-mentality recommendation for a new jazz album. Amazon thoughtfully notice I bought a 1962-issue jazz album some three years ago, and assumes I am interested in some contemporary jazz performer I have never heard of who has just issued an album. Problem is, I generally hate contemporary jazz. Out of curiosity I previewed the album but could find no stylistic relationship with my earlier purchase. Frankly, I doubt that a data correspondence even exists. The page for the newly released album listed 18 other "similar" albums, none remotely in the 1960s jazz vintage.

Today, another email from my faithful correspondents at Amazon. They have "noticed" that people who bought a certain book are pre-ordering a new book by the same author. This time the new book's web page does list the previous book as "similar". How similar? They are the same book: the soon-to-be-released simply has a different title and publisher, and will be in paperback instead of hardback. Are scores of people so stupid not to guess they are the same book, or is the data matching so primitive that it assumes people will buy anything from the same author?

"what adapts? technology or people?"

2005-08-04T16:44:00.000+12:00

Don Norman asks a very important question: do people adapt to technology, or does technology adapt to people? He points out that people can and do adapt to klutzy (unnatural) technology. He cites three examples of unnatural technology people happily use: the clock, writing systems, and musical instruments.

While Norman chose his examples because they are ordinary, they are also very old technologies. All of them developed before anyone thought to use a human-centered approach to design. And all of them involved many centuries of effort by humankind to master them. While successful, these unnatural technologies were hardly instantly successful.

Let's take musical instruments. Norman notes that repetitive stress is a common problem associated with playing many instruments such as violins. Despite this, people play violins. Therefore people have adapted to the violin. Well, not quite. They still get repetitive stress. If they had fully adapted, then repetitive stress would be a non-issue. If humans could adapt fully, people might need to do some special time-consuming exercises to conquer repetitive stress, but the inefficient work would prevent injury. But there is no fool-proof way to avoid repetitive stress injury.

The violin is also hard to play (I know from childhood experience.) If people could adapt easily to the demands of the violin, then there would be no need for Suzuki schools and similar punishments inflicted on children.

The design of the violin remains unchanged because people choose to suffer. Suffering is part of the prestige of playing a violin (prestige I am happy to forego.) If the violin were easy, would anyone bother?

The guitar is supposed to be easy (relative to the violin at least.) People interested in taking up the guitar are not generally masochistic, at least in the beginning. Not surprisingly, the guitar development has benefited from human centered design. Kim Vincente tells a wonderful story about how the Flender Stratocaster guitar was constantly redesigned based on feedback from musicians. Leo Fender made it easier to handle, more comfortable, and easier to play. The electric guitar was developed using human centered design principles. Vincente argues that without those improvements, rock music (Beatles, Stones, Who...) may have never taken off like it did.

So I agree with Norman that people can adapt to technology, but it hardly follows they want to adapt. Hundreds of millions use computer keyboards, but millions of people suffer repetitive stress from keyboarding. PCs are 25 year old, but we haven't adapted to the keyboard successfully.

branding and government: a pointless combination

2005-08-02T12:22:00.000+12:00

I'm not one of those "anti-government" people who whines about there being too much government, or complains that all government is incompetent. Actually, I think the concept of government gets a bad rap. I accept government as necessary for a well-functioning society. It may not always work as well as we would like, it can often be improved, but one needs to accept government for what it is, and not pretend it is a corporation.

While I accept the value of government, I also tend to limit my interaction with it where possible. I don't, for example, surf government websites for the pleasure of it. I consult a government website only when I have some unavoidable need, like getting my car registered, or paying taxes. But somehow these simple certainties of life has become more uncertain, thanks to the pernicious influence of corporate branding.

I recently had to do my UK taxes, and found I needed a certain form. I googled "Inland Revenue" and UK, but only got a slew of websites belonging to tax preparers and accountants. To where had Inland Revenue disappeared? They had sent me mail only a few weeks ago. Further hunting revealed something called HM Revenue and Customs. I discovered that HM Revenue and Customs is the new, re-branded Inland Revenue. To my ears, the new organization sounds like its main mission is to collect fines from people bringing too much booze into Heathrow.

A similar frustrating experience happened when I needed to get my car registration updated. The responsible government department in New Zealand had decided to rebrand, a process that would take several months. In the interim, I get mail with the both the old and new name on it, depending on what stationery is being used. Being recently arrived to New Zealand, I am confused which is the old name and which the new one, and don't know what name will be listed in the phone book (when did the name change happen, and when was the phone book printed?)

However trendy discussion of "lovemarks" may be in the business world, I don't think they are appropriate for government. A wise person, maybe it was Steve Krug, said nearly a decade ago that users don't want to know your organization chart. In the early days of the web, many companies structured their websites around their internal functional department, instead of structuring information from a customer-centric perspective.

The last thing I want to do when paying my taxes or registering my car is to spend time figuring out what part of government is responsible for it. Perhaps well-meaning government officials believe that sending me announcements of an impending name change will help me learn who to contact. But it would be far simpler if governments did not change their names, ever, even when they do a bureaucratic merger or shuffle. And if you collect taxes, call yourself the tax department, not some euphemism like "revenue." Revenue from what? Sales of lottery tickets?

I am encouraged by the approach in the UK of Directgov, which offers a customer-centric view of government services. People don't care what the name of a department is that processes a form, they simply want to complete the form and have it acted on.

fact or opinion? the mass market ethnography

2005-07-30T15:26:00.000+12:00

I've finished Kate Fox's Watching the English: the hidden rules of English behaviour. I discovered this GBP 7.99 "popular science" paperback at a local bookshop, and was excited to see discussion of "participant observation" already on page 3. Fox is a social anthropologist writing about the most ordinary of topics, English life. I felt hopeful I would pick up some tips both on techniques to obtain ethnographic data, and ways to present it to a general audience.

Generally, the book was disappointing as ethnography. Fox works for an organization called "the Social Issues Research Centre in Oxford," which describes itself as a non-profit think tank. In contrast to most ethnographies, which are published by academics, Fox was able to write a breezy book unencumbered by methodological discussions. But I also felt the book lacked credibility. Far too many assertions were made without any backing information. Very often I was left with the impression that Fox was giving top-of-the-head opinions, instead of doing detached observation to arrive at her conclusions. Much of the book seemed like a running debate with the TV presenter Jeremy Paxman, who has written on the English character. But it was a case of one opinion countering another. Fox never says "look at his evidence..."

The only useful data tip was if you want to interview DIY enthusiasts in the parking lot of a DIY store, offer them tea and donuts, since that is in keeping with the spirit of their DIY mindset.

I was also disappointed that Fox never contradicted any stereotype of the English. She said she wanted to "get inside the stereotype", that is, to explain it. But she was adamant that all the stereotypes of the English are true, even when others say the culture is changing. (Is the queue a vibrant tradition or a fading one?) I found this insistence of the immutability of English culture silly. I think good anthropologists today believe that all cultures are changing as a consequence of technology, exposure to other cultures (travel, multiculturalism), and other forces of adaptation.

In general, I would have expected a 400 page ethnography written over a period of three years to contain something that would surprise me. A good ethnography should ring true, but also provoke at least a few thoughts along the lines of "I hadn't thought of it that way before." One expects a detached observer to pick up on something that generally escapes everyday notice. The book is valuable to me in illustrating how important it is to demonstrate one has done research, if one is reporting that common perceptions are indeed true. And if you say something novel (for me, that coasters are considered lower class), also show that your assertion is based on fact, not just stereotype.

the "value" of self-help

2005-07-29T19:53:00.000+12:00

Here is a brilliant observation from John Maeda:

I do admit that I read a whole bunch of these sort of self-help books. Is there anything inside them worth reading? Certainly. Although the number of nuggets you can get from these books is definitely not proportional to how many pages there are.

Self-help is a classic taboo topic. Admitting to reading self-help can potentially call into question

Your intelligence. Many self-help books are thin on big ideas, so what does it say about you that you read them?
Your social skills. Indeed, the more successful (or the more presumed successful) one is, the more perfect one is imagined, so any admission one needs "help" is potentially brand-busting.
Your class, if you live in a country that believes people are bred like horses instead of aspire to realize their own ambition.

I admit to data mining self-help literature. I wish there was a more efficient way to transfer the knowledge. But repetition of theme is at least a partial substitute for the more difficult act of doing, which is where the benefit is realized.

is activity theory growing up?

2005-07-29T17:00:00.000+12:00

Don Norman has a much discussed article in the current SIGCHI interactions on "activity centered design." I haven't seen the actual article, as I am still waiting for my copy of interactions to arrive. Typically, my copy is sent from the States via an Arctic detour to Sweden before heading south toward Antarctica to reach me in New Zealand. In the interim I have to read Norman's bootleg copy of the article he posted on his website.

I'll avoid commenting on the obvious polemic of the article (that UCD can be harmful), and instead focus on Norman's mention of activity theory (AT). I happened to study HCI at one of those woolly-minded universities that have been enthusiastic about AT. If you don't know much about AT, I can't explain it suscintly, other than to say involves a lot of triangles. There are these triangle-within-triangle diagrams that look like some sort of esoteric mapping of astral planes. Indeed, AT has been so theoretical, metaphysical even, that the rumor was that SIGCHI routinely rejected papers about AT, considering them too impractical. Now Don Norman is writing in the SIGCHI flagship publication mentioning his "own brand of 'Activity Theory,' heavily motivated by early Russian and Scandinavian research."

I am very interested to learn more about Norman's personal brand of AT. I'd enjoy a discussion shorn of triangles and Marx.

There has been some recent interesting AT-grounded work done that appears modestly practical. I've seen AT applied by several people to work-flow processes. Let's hope AT emerges from the fog of theory into the light of application.

acrobat sucks

2005-07-28T09:19:00.000+12:00

Different computers, different versions of Acrobat. Same week. This happens all the time.

Don Norman: "Boycott unusable designs."
Me: "I wish I could."

swedish rounding: world-famous in new zealand

2005-07-27T12:46:00.000+12:00

For many months I have been mildly confused about what I am charged for goods in New Zealand. Since 1990 New Zealand has had no one or two cent coins, but many items have 99 cent price tags. I am generally charged a dollar for these, but sometimes I am charged only 95 cents.

One day I found a sign on the counter of check out explaining something called "swedish rounding". The explanation said something like they "round down prices ending in 1,2 to 0 and 6,7 to 5 and round up prices ending in 3,4 to 5 and 8,9 to 0." My head was spinning trying to figure out how that worked. I have since see the explanation more simply as 0,1,2 are rounded to zero, 3,4,5,6,7 are rounded to 5, and 8, 9 are rounded to 10.

Even if you can do the math, it doesn't mean you can guess the price. Retailers can use alternative rounding systems, as long as they are consistent. The consumer affairs department notes that for "an item marked $1.99, traders can charge either $1.95 or $2.00."

I was curious about where this swedish rounding concept came from, but nearly every reference to it referred to New Zealand rather than Sweden. Even searching Swedish sites seemed to yield only a merger reference to "Nya Zeeland."

Just as I am figuring this out, New Zealand is in the mist of phasing out the five cent coin. This change is sparking a new round of rounding methods. According to a survey of retailers, rounding practices will vary greatly. Some will round five cent items up, some down, and some will simply round everything up.

As New Zealand abandons its famous swedish rounding, it is left to Germany and other Euro zone countries to keep the tradition alive. Even though a cent in Europe is worth more than a cent in New Zealand, the one and two cent coins are reportedly unpopular with some Europeans. If Sweden ever joins the Euro, perhaps it will reclaim its legacy.

more on the culture of roundabouts

2005-07-24T18:47:00.000+12:00

I wrote recently of my feeling, based on personal experience, that roundabouts were cognitively complex. Since writing those views, I discovered the distinguished Canadian human factors engineer Kim Vincente describe roundabouts as "complex and demand attention and mental agility." Clearly, roundabouts, as a technology, are not user-friendly.

Yet Vincente also notes that a particularly complex roundabout, called the "Magic Roundabout" in Swindon England, does not have a particularly high accident rate, despite its complexity. Are roundabouts intrinsically safe despite their complexity, or does something else account for the the safe record of the Magic Roundabout?

At the moment I happen to be reading a book by social anthropologist Kate Fox called Watching the English: the hidden rules of English behaviour. Fox argues that English drivers may be more polite when compared with drivers in other countries. "English drivers are quite rightly renowned for their orderly, sensible courteous conduct....You don't have to wait long until someone lets you out of a sideroad...all drivers keep a respectful distance....people are remarkably considerate about pulling in to let each other pass".... etc.

So perhaps roundabouts can work only in England, land of the gentle driver.

But as a pointed out earlier, roundabouts can result in knots of traffic, where everyone is waiting to give way to the person on their right. This leads to impatience and confusion. Fox doesn't address roundabouts, but she talks at length about queues. Fox argues the English, unlike many cultures, is a "fair play" culture, rather than an opportunistic one. She observes English people having near arguments over who is supposed to go first, each side insisting the other goes first. In an opportunistic culture, people might jockey for position to get their chance to go next.

I am not always convenced by Fox's sweeping generalizations, even though they contain many insights. But I do believe cultural norms of turn-taking affect the success of any system that relies on interpretation to decide how people behave in cars. Unfortunately, when a system relies on cultural norms (instead of unambiguous rules), it can get messy. It is often not clear whose turn it is. When two people arrive at the same place at near the same time, they both have to have seen the same event (one may be daydreaming), and have interpreted it in the same way. If the two people not only have different understanding of what happened, but different expectations about who should go next, it doubles the problem. The use of roundabouts relies heavily on user interpretation, which is why is it problematic. Roundabouts offer two problems: potential differences about who should give way to whom (based on estimations of position and driving speed), and differences in who has the "right" to more next once both parties realize the ambiguity of the situation.

sewing for geeks

2005-07-23T11:56:00.000+12:00

a gift for grandma?

I saw this sewing machine in the window of a shop in Christchurch. I find it intimidating, but I don't sew either. I would be curious to know who buys these, and how they relate to the technology. If it weren't a sewing machine I would assume it was meant for blokes, given the screen and all the buttons.

I'm no genius

2005-07-23T11:24:00.000+12:00

spot the problem

I admit to being bored by keyboards. I've used dozens, maybe hundreds over the years, and have rarely encountered anything too troubling with any of them. Sure, some feel a bit better, and they all have subtle differences in layout, but so what? I have never been troubled by repetitive stress, and have therefore never been that curious about premium keyboards.

For complicated and annoying reasons I was forced to replace a perfectly fine keyboard with a USB one for one of my computer set ups. This was not a gratification purchase, so I went for cheap. I located the cheapest USB keyboard sold in New Zealand, made by a company ironically called "Genius."

I noticed that the keyboard had a rather small "shift" key on the right. No big deal, I'll get used to it. I overestimated how plastic my brain is. The keyboard proved to be the most annoying peripheral I have ever used. I kept jumping around on the screen. No matter how much I tried to hit the shift key, I kept failing. I slowly realized (duh) that the shift key was located next to the up arrow, and that both these keys had up arrows on them. What Genius laid this out? And what silly usability person bought it? I now approach keyboards with a new humility.

out of context

2005-07-23T11:14:00.000+12:00

out of context

This container of foil-sealed water was acquired on a recent plane ride. My wife held on to it thinking she might want to drink it while laying over at the airport, waiting for her next flight. Instead, it found its way home, to our kitchen, where it has been now for several days.

The fact that the container remains in limbo highlights the fact we don't know what to do with it. The water is at once perfectly good and perfectly useless. In the context of our kitchen we don't need the water. How to put it to good use now that we aren't on a plane? Add it to the earthquake emergency reserves? Sadly, the "natural spring water" is set to "expire" in a couple of weeks. That would be a terrible waste.

interface longevity

2005-07-16T12:17:00.000+12:00

Designers, like most people, aspire to leave a legacy. Who wouldn't want to believe that something done well should serve people for a long time. But technology-based designs don't generally last long. Technology advances, raises our collective expectations of what is a good design, and once popular designs are put to pasture as more updated ones replace them.

It is rare for an interface to last too long. Even Apple's Mac OS, which seemed to get so much right, has been through radical updating over the years. Websites are finally settling down after years of monthly reskinnings, but there are still subtle changes happening all the time that cumulatively change the look.

Look at screen shots of most any interface from 10 years ago and it will look dated. There is one exception that is so retro it defines dating. The BBC's Ceefax teletype news service seems to have more lives than cats do. I discovered the service when I got Freeview digital box for my TV while living in London. But the service is 30 years old, largely unchanged since the launch. My British friends will no doubt have nostalgic memories of using Ceefax on their BBC micros. Now I see that someone has created a Ceefax "widget" for OSX/Tiger. Who would guess that a service designed for the hearing impaired would have such legs.

participant video studies

2005-07-15T13:13:00.000+12:00

Disposable camera studies have been around ten or more years. Participants in a study are asked to document something about what they do, or perceive. The outputs can be interesting, can offer a great stimulus material for participants to discuss with researchers.

Now we have the ability to do video studies in the same way. Rather than lend expensive digital video cameras to participants, one can now give them a video camera for under $30. USATODAY.com - $29.95 one-time-use video cameras ready

This development could be an exciting new chapter in ethnography. I have expected that video diaries would soon emerge, but I expected they would come from video phones, not disposable video cameras. One advantage of video phones is that they are always on the person, so always ready for use.

People can now film how they do an activity, or something they notice. The only danger I see is the potential for junk. Photo taking requires more thought than shooting video. I have seen people forget to take pictures and rush to shoot the roll to have something to bring in. The temptation could be larger for videos: just stream through 20 minutes of random stuff. So video is probably better for self-documenting activity, rather than recording perceptions.

the myth of multi-tasking

2005-07-15T09:52:00.000+12:00

Evidence continues to show that people can not safely drive and chat on a mobile phone at the same time (I've seen two studies reported just this week). The reason is not dexterity -- the problem exists with hands-free sets as well. The reason is cognitive: we can't concentrate on two important unrelated activities at once.

The implications of these findings go beyond cell phones. What the cell phone studies show is that multitasking is a myth. The myth of multitasking, spun by techno journalists and trend gurus, asserts humans have rewired their brains as a consequence of increased exposure to technology. The "rewired brain" enthusiasts speak with gushing romantic faith that echoes Maoist ideas of the arrival of a "New Man" unshackled from his biological limitations. They claim people are different from how they were in the past: smarter, faster, and omnipresent, thanks to technology. Those hours whittled away in front of Playstation or Xbox have made you able to perform mental feats previously impossible. Well, not quite. Being quick with the game controller does not mean you can also carry on a meaningful conversation at the same time.

I would like to see talking on mobile phones in moving cars made illegal for the sake of public safety. But I also hope the growing research on cognitive overload will cause us to reassess the stress we create, and are subjected to, that results from technology disrupting our context. "Always on, always available" or "Anytime, anywhere" may sound like freedom, but it also entails a cost. I would like to see the concept of Intrusion addressed more systematically. We all know Intrusion is disruptive, it can break our concentration, but do we really know what it costs us in concrete terms? Is anyone doing real field studies of Intrusion, quantifying its prevalence and documenting its effects? If you know of such work, please let me know.

has microsoft no pride?

2005-07-10T20:14:00.000+12:00

I use a Hotmail (Microsoft) email account for impersonal mail, such as mailing lists and such. While it has never been elegant, I haven't expected too much, given that it is free for basic service. But in past months it has grown increasingly unreliable, to the point where I am now only able to sign on about 50% of the time that I try. This is a "level of service" is bordering absurd. Even for non-urgent email it is too inconvenient.

Redmond is damaging their brand even further by offering such shoddy quality on something so uncomplicated.

UPDATE. The problem seems to be related to deep linking logged on account. This has always be mysterious to me, as sometimes I am taken to New Zealand branded site, and sometimes a UK branded one. Whatever has changed, I am not aware of being notified of it.

rules of the road

2005-07-09T22:10:00.000+12:00

Some rules are logical, some rules are convention -- they make sense if you accept the starting premise -- and some rules are cultural, it is just how things are done. I am starting to think that New Zealand's "give way" system of traffic management is cultural.

After a number of months driving in New Zealand, I realize something very odd: there are few traffic lights here. Perhaps in the past there wasn't that much traffic to justify traffic lights, but New Zealand today has one of the highest per capita car ownership rates in the world, and traffic can be congested. But it isn't just traffic lights: there are few stop signs either. In fact, nearly every intersection is governed by a system of "give way" (yield) rules. New Zealand is gaga for roundabouts (traffic circles), even in the middle of highways. One can even encounter strange hybrid roundabouts, involving three or five spokes instead of four, odd contortions that look anything but round.

The give way system offers the illusion that one doesn't need to stop, but the reality is quite different. I have heard that roundabouts are supposed to offer more efficient way to get cars through intersections than traffic lights. But in my experience, the system collapses when there is traffic congestion, which is often. People queue waiting for the person on their right to go. But that person also is waiting for a person on their right. And so on. What is described in the official Road Rules as a simple give way to the person on the right, in practice is a quagmire of confusion, as everyone is waiting, feeling it is their turn, but unsure if they really have the right of way.

I am also reminded of the failure of the give way system when I watch the television. Every day public service adverts are broadcast admonishing one to watch carefully in all directions when pulling out in a busy intersection. The unfortunate person in the ad get crushed by an oncoming car because she thought she had the right of way. By like a game of chess, she had to think several moves ahead to anticipate how someone else turning on the busy street perceived their right of way.

From a cognitive perspective, I think the give way system is deeply flawed. If one only needed to follow one variable it might work. Instead, yielding is conditional on a chain of prior claims. It is similar to trying to understand a compound, complex sentence while brush your teeth.

Traffic lights are much easier. You just need to be okay with being told to stop.

your attention, please!

2005-07-05T21:12:00.000+12:00

I once saw a funny skit by the British comedian Lenny Henry, that highlighted the various "audio signatures" of different versions of Windows as they booted. Henry added a Rastafarian version.

But it is interesting to question what noise we notice, what we simply enjoy, and what escapes attention all together. For audio feedback in machines, Stephen Wilcox advocates using "semi-musical" chords that don't sound too musical (we don't pay attention to these) and don't sound too harsh (we focus too much on the sound, rather than what it is meant to cue). Wilcox suggests chords from Bartok and Stravinsky. I guess this approach doesn't work so well for people who consider Bartok's and Stravinsky's music lyrical.

worst software award

2005-07-04T11:00:00.000+12:00

I am really pissed off with Abode Acrobat. Every version seems to be worse than the previous one. I own version 4, but it is increasing rendered useless by documents created in newer versions, which have "enhanced features" that version 4 can't understand.

I hate the idiotic digital rights management of newer versions of Adobe. They often force the user to print out a document, instead of allowing him to save it to his disk. We are sliding backwards here people: my office is getting more cluttered by paper now, not less cluttered.

I hate how buggy Acrobat is, even Acrobat reader. The more crappy features Adobe tries to force on me, the more crappy code that results. Acrobat doesn't play well with Explorer, Firefox or Active X.

Acrobat is a corporate centric solution. The user be damned. It is time for users to stand up and voice their discontent.

business as iterative design

2005-07-01T13:32:00.000+12:00

I believe passionately in the power of iterative design, making changes to get feedback, so as to learn how to arrive at a better solution. Iterative design is not simply testing if something works, it is finding information within the feedback, information that can be acted upon. Iterative design is a form on continuous learning.

What iterative design is not is planning. Many people comfortable with notions of project planning and business planning cast a wary eye on iterative design. But no less a business authority than Peter Drucker notes the power of iterative design in the evolution of firms. He notes:

"When a new venture does succeed, more often than not it is in a market other than the one it was originally intended to serve, with products or services not quite those with which it had set out, bought in large part by customers it did not even think of when it started."

Try writing a business plan around that scenario.

jargon decipherment

2005-06-29T10:03:00.000+12:00

We hear constantly that jargon is "bad" because outsiders don't understand it. But jargon is also good because it represents a highly developed and meaningful vocabulary among a social network.

I admit to feeling uncomfortable when hearing jargon I don't understand. I sometimes wonder, "Am I supposed to know what this means?" Sometimes I hang back and can figure it out, but other times I have to profess my ignorance. The interesting revelation comes when I discover whose jargon I am hearing. Is it industry-wide jargon, or particular to a company? I am perhaps less embarrassed by company-specific jargon, unless of course they have made a public virtue of their branded way of describing something.

Jargon is interesting because people often are not even aware they are saying something that might not be understood to outsiders. It represents the enormous power that context has on shaping behavior.

simplicity and the simplistic

2005-06-26T16:53:00.000+12:00

Simplicity is not a way of life, it is a sales benefit of Philips products. I find a heavy, "special advertising insert" from Philips in the New Yorker announcing their "Simplicity Advisory Board." Note to Philips: I volunteer to join the board, to give you a bit of contrarian perspective so your thinking doesn't become to simplistic.

Philips has explored the theme of "emotional design" as much as any company, so I find there current focus on simplicity hard to understand. Simplicity is the enemy of emotional design. Simplicity appeals to the rational and discrete, while complexity appeals to the subtle and nuanced.

As Robert Chia has noted:

While the traditional scientific mentality emphasizes the simplification of our experiences into manageable "principles", "axioms," etc., literature and the arts have persistently emphasized the task of complexifying our thinking processes and hence sensitizing us to the subtle nuances of contemporary modern life.

True, I want some things to be simple, things that annoy me, or tax my brain. But the sexy design stuff that Philips shows in their adverts -- no, give me richness, not straight-forwardness.

overheard on the bus

2005-06-25T14:19:00.000+12:00

A teenage girl, chatting on her mobile phone, tells her friend: "It's so easy to end up sending the TXT to the person you are talking about [in the TXT]. That person is on your mind when you are choosing the person to send the TXT to."

Seneca on ethnography

2005-06-24T09:20:00.000+12:00

One of my favorite descriptions of ethnography is being a "professional stranger." Part of ethnography is looking at ordinary, everyday situations with fresh eyes, and paying attention to sometimes subtle things that escape notice or reflection during the hubbub of daily life.

The Roman Stoic philosopher Seneca didn't know about ethnography of course, but I think he would have appreciated its approach. I have encountered clients who react to ethnographic findings with an attitude of, "Well, we know that already." Seneca would reply:

People say: "What good does it do to point out the obvious?" A great deal of good, since we sometimes know facts without paying attention to them.

plague, updated for the Internet age

2005-06-24T08:36:00.000+12:00

Rats are always causing trouble for us humans. Now it seems they were responsible for Monday's national network outage in New Zealand.
NZ outage caused by rats

Cashless and helpless

2005-06-22T14:11:00.000+12:00

According to the accountancy KPMG, New Zealand is on its way to becoming a cashless society. They note that last year 741 million EFTPOS (debit card) transactions were conducted in New Zealand with a total value of $41.3 billion. "This represents a transaction being made by every man, woman and child in New Zealand once every two days."

That's wonderful, expect when things aren't working. On Monday, major parts of New Zealand experienced a network outage, which brought down the EFTPOS system with it. People used to carrying hardly any cash were stranded, as stores can to process debit payments manually. I had to teach a store clerk how to use an old style carbon receipt manual slide imprinter (I knew how it operated, though I don't know what the contraption is actually called.)

As comment on the crisis, the newspaper had a cartoon of a customer asking a sales clerk, "er, do you accept New Zealand currency?" The virtual economy has made tourists of us all.

how much do shareholders care about good design?

2005-06-21T16:02:00.000+12:00

The top concern of CEOs today is "shareholder value", in other words, stock price. Shareholder value has become an increasing obsession over the past decade, to the point where it nearly squeezes out all other concerns. I am not alone in finding this development troubling, but that is the way things currently are.

The value of design research to corporate earnings would seem straightforward. Design research can boost sales by making products or services more attractive to customers, and can reduce costs by making products work better, so customer service costs are less. Design research, which includes needfinding, conceptual exploration, and usability, would seem to fit in well with key corporate concerns such as quality, customer service and innovation. Unfortunately, it can be difficult to isolate the contribution of these factors to quarterly profits -- the bellweather of stock price. It takes companies several quarters of sustained effort to build credibility with their products. But in the short term, they need to hit cost targets, which can fluctuate considerably (just think about energy prices), and met demand forecasts as well, which are subject to economic conditions and product and price competition from rivals. Even a company celebrated for its design like Apple can be punished in the stock market if they have to scale back expectations of sales. Sales can fall for many reasons unrelated to design, but if design is seen as an expense, it is a tempting cost-cutting target to boost short term profitability.

It may be that institutional investors, who could care less about design, hold the keys to how design research will develop within companies in the future. Design research needs to accommodate itself to the short-term trading mentality of institutional investors. The first need is not to get too big. Institutional investors, takeover artists and other financial hawks will never see design research as anything other than a cost. So design research needs to be kept nimble and stealthy to avoid attention from the balance sheet readers. Companies enjoying good times don't have to worry about outside interference, but every company sooner or later encounters a bumpy batch. When that happens, a big design staff will look costly.

The other need for design research is to deliver results quickly. Design cycles are collapsing, which is a good thing. The contribution of design research is more immediate than in the past, reflecting the rise of iterative prototyping in both digital and physical design. Design research can have an impact sooner, and doesn't need to rely on the "patience" of investors.

Some people may wonder if institutional investors can learn that design is good for business. I have my doubts. The UK Design Council last year published a report purporting to show that winning design awards was good for the share price of companies. While the report was interesting for recognizing the importance that stock prices have on design, the report did little to prove that design is good for share price. The only reasonable conclusion of the report is that financially successful companies tend to enter design competitions more often than unsuccessful ones. Companies are not successful because they win design awards, they are successful for a multitude of reasons, design being but one.

The irony is: the more successful design research becomes in helping companies deliver better products and services, the more humble it will need to become, because City bankers and Wall Street analysts, who think they know everything, will have to rethink how they look at balance sheets.

am I jinxed?

2005-06-19T19:40:00.000+12:00

I sometimes get irrational when upset, and believe the gods are cursing me. I try to install a simple piece of software, or simple peripheral, and things go haywire. I generally go through three stages of anguish: 1) did I do something wrong? I re-read instructions and wonder 2) did something else screw this up (the cat, which runs around the cables with indifference might be the culprit.) Finally my deductive mind just can't figure what is wrong. So I wonder if something is defective. In too many cases, the answer is a qualified yes.

I've spent the weekend installing bits and bobs and have encountered numerous problems. A free text database program called Sticky Brains doesn't like the "Tiger" OS on the Mac. My Belkin KVM switch erratically stops switching between the two computers it is connected to. A Java-based Oxford Chinese dictionary is disabling any Internet program on the PC. I learn its not me! User forums don't tell me how to fix these issues, but they give me comfort that others are having the same problems. Of course, they also contain the replies along the lines of "it's working fine for me." So some people are luckier than others after all.

experience and happenings

2005-06-19T17:29:00.000+12:00

Many people want to label nearly everything users encounter as an "experience." We talk about the user's experience filling out a form, or the user's experience browsing a website. We talk about the customer's experience standing in a queue waiting to buy movie tickets.

But if you ask people what their experience was, they will often reply "I dunno, ah, normal I guess." There are at least two possible reactions to such answers. One is that asking such a question is not the right way to get at the user experience. One needs to probe the experience through other means, such as observation, to understand what the user is experiencing. Another reaction is to conclude the issue itself just isn't very interesting. The experience clearly didn't register with the user, so if they aren't worked up about it, then it must not be that important.

I think both reactions can be true, depending on circumstances. Users aren't always able to articulate things they feel viscerally, though these things do matter to them -- they do feel affected by them. But other times, I think user researchers project their concerns on the user. They think long and hard about a mundane issue, and see that something is unnecessarily complicated, long, or dull. But it doesn't follow that the user feels that way. They might not even be conscious of the inadequacy of what is presented to them.

Truth is, not everything a user does is an experience. People are often on autopilot, and don't reflect on what they have been doing. In the absence of self-conscious awareness (the event is too mundane or trivial to think about), users just do it, not think it. Saul Alinsky noted this phenomenon back in the 1960s, when he distinguished experiences from happenings. As he wrote in his classic, Rules for Radicals:

Most people go through life undergoing a series of happenings, which pass through their systems undigested. Happenings become experiences when they are digested, when they are reflected on, related to general patterns, and synthesized.

Unless people have cause to reflect on what they have been doing, their "experience" may be just a happening.

we are still slaves to the machine

2005-06-17T10:02:00.000+12:00

If computers are getting more user-friendly, why do we spend what seems like ever increasing amounts of time pampering them? Unfortunately, networking is turning out to be a bottomless sinkhole of time and money.

The villain is security. I was recently in an American computer superstore, maybe the largest one I have been in. My geek side was happy to roam around. But the offerings were incredibly boring. Most of the aisles were taken up by boxes and boxes of software designed to offer virus protection, firewalls, privacy protection, crash recovery, and so on. Where was the software to make me more productive, or creative tools to make things? I had to hunt around to find a few dodgy, low cost products that looked like they would be frustrating to use.

I also recently bought a Mac (jury still out on it). I know there is supposed to be some cool software for Macs, but I was dismayed to find in the Apple Store more boxes of software offering disk maintenance tools and endless utilities. The impression given is that Macs are every bit as fiddly as PCs. The Apple Store mostly sold their own software, and then some third party software to keep it running.

Perhaps visiting shops is not the best indication of the state of affairs. Let's look at today's headlines. Adobe issues "patch" for Acrobat. Sun issues "patch" for Java. Analysts predict "migration pain" for Microsoft's Office 12. That's just today.

I'm not optimistic things will get better anytime. :-(

user centered design: strategy or movement?

2005-06-16T13:44:00.000+12:00

I suppose it is a testimony to the commercial success of user centered design (UCD) that more and more people are referring to it as "strategic." Strategy, of course, is one of those expensive sounding words favored by consultants. We are a long way from the days when UCD was the interest of commercially disinterested academics who had vaguely populist ideas about improving the lot of the common man.

I believe it is a good thing that people are making money out of UCD, since business is the major engine of change in much of society. So when I question whether UCD is "strategic," I am not questioning that it holds important, commercial value. Rather, I am questioning how UCD is introduced in business.

Strategy is based on a hierarchical view of business. Some grand thinker at the top develops a strategy, which the underlings duly implement. As UCD practitioners become interested in UCD as strategy, they excitedly imagine getting close to the source of power, where real things get done. The fantasy is that UCD gets a "seat" at the boardroom conference table. Maybe the corporation hires someone called a Chief experience Officer (CXO), though precisely what a CXO would do is not clear. Alternatively, UCD consultants would be invited in to meet with the CEO with the reverence granted to McKinsey partners. In either case, the strategy fantasy imagines the CEO will take a passionate interest in UCD, and it will be on the tops of people's minds throughout the organization.

I hate to prick a hole in this fantasy, because it would seem by so doing I felt UCD was not vital, or even important. UCD is vital, and I'd like very much to see all corporations embrace it rigorously. But expecting a corporate savior from on high may not be the most viable path. CEOs are extraordinarily busy people, who, if they are receptive to hearing other people's views, probably are made to feel guilty by nearly everyone, who say they don't give enough attention. (For example, Human Resources feels slighted when the CEO says people are the most important asset, but he spends all his time on investor relations). The "UCD as strategy" option expects the busiest person in the company to take a special interest in UCD. He will push it down the ranks, even though as corporations have flattened and federated, his power to directly tell people what to do is diminished.

The alternative vision of a User-centric corporation is to embed it at the grassroots. Defenders of the strategy approach will argue that a grassroots movement won't work. We have all heard tales of corporations that do not reward innovation that can't be measured by the beancounters or project managers. And we have heard tales of lone employees struggling to get anyone to take their UCD interest seriously. So we become cynical to the idea that big organizations can change themselves from the bottom up.

I don't want to discount the challenges that rank and file employees of large organizations face. But we also need to recognize that some big organizations do manage to adopt and embrace change from the bottom. That may happen less often than we would like, but it does happen, often without fanfare. How it happens is an object lesson in design itself.

If UCD is to really transform an organization, it needs to be embraced throughout it. One of the biggest blocks to change is the resistance that comes from being forced to accept someone else's ideas. That resistance can be even stiffer when employees, struggling to cope with numerous demands, are asked to get instantly interested in some alien concept, just because the CEO is pushing it this week.

I wish to commend a book by Mary Lynn Manns and Linda Rising called Fearless Change: patterns for introducing new ideas. Manns is an organizational psychologist and Rising a software patterns writer. They have looked at how new concepts have been introduced and nurtured in different high tech organizations, and identified patterns where the behaviors have been successful taking hold. Patterns are a design concept, adopted by software developers, who extended the concept from Chris Alexander's ideas on physical architecture. Now Manns and Rising are applying patterns to people. Brilliant.

Many of the patterns are mundane, but important, such has hosting "brown bag" lunches on new topics of interests. They involve telling stories about small successes, that other people can relate to and learn from. They introduce change on a human scale, where you know other people who have benefited, and you can model your efforts after what they did.

I won't pretend this approach is fast or easy, but it does have more impact on the culture of an organization than the strategic approach. And it has the potential to outlast the CEO, who might be gone in six months.

coffee and wifi

2005-06-14T07:56:00.000+12:00

An interesting article in today's New York Times, Some Cafe Owners Pull the Plug on Lingering Wi-Fi Users . It seems that web surfing and coffee drinking are not natual combinations. Many people surf without any need to drink coffee continually.

Cafes are a rare example of a "third space" that people can go to work or socialize. I strongly believe we need to develop alternative third spaces, not just rely on cafes. I love my coffee in the morning, but I find it vile in the afternoon. I literally find the aroma of coffee noxious after smelling it too long, over an hour. And I hate the shrill sound of coffee grinders, and the banging of metal as baristas wack out the coffee grinds from the machine. Coffee-centric cafes are really not very pleasant places to spend long periods, which may be why Italians just down their coffee while standing, instead of nursing a boat-sized frothy sugar-ladened drink for an hour. French cafes aren't really about coffee, they are about sitting outside on the pavement, watching the world go by while enjoying drink or food. I can't see wifi in either a French or Italian cafe.

Someone needs to develop a lounge for doing work while mobile, that is more flexible and comfortable than the cubicles of the so-called "Internet cafe", and not so centered on dispensing drinks.

can we humanize air travel?

2005-06-13T07:12:00.000+12:00

Like many (most?) people, I don't like air travel, but I generally tolerate it, assuming things are working according to plan. When things deviate from the plan, I get really bent out of shape because air travel is the most inflexible user system that most of us ever need to encounter in our lives. I imagine, in these days of patient advocacy, when visiting a hospital in an emergency, users possibly have more control and choice over what happens to them than dealing with an airline that is having a bad day.

This weekend I traveled from Honolulu to Wellington, via Auckland. It is supposed to be a 12 hour flight, including the Auckland transfer, but in my case ended up being 21 hours. Bad luck for me, but what interests me is why I was delayed. Air travel is a massive system that processes people as though they were inanimate data objects, queuing them up for a batch run at the convenience of the server. Like the old days of expensive mainframe data processing, airlines and airports deal with people on a schedule that mets their cost and time needs.

My journey started inauspiciously in Honolulu when I arrived to check in, to be told that my midnight flight would be delayed 3 hours because of fog. Honolulu was having fine weather, so I was a bit confused. The fog was in Auckland. I wondered if they were expecting fog in ten hours when we would be landing, an amazing feat of prognostication. Actually, the in-bound plane we were to use was delayed due to fog, so we have to wait for it. So, we have fine weather in Honolulu for take off, a fresh crew ready to go, and several hundred passengers waiting, just no plane. I fantasize why wouldn't Air New Zealand just call Hertz to rent a substitute?

At 3 am we take off. Some 9 hours later we are ready to land in Auckland. Our headsets are collected, and we circle the city. And circle. For half an hour. Now there is fog again in Auckland. Ironically, if we had left Honolulu on time, we could have beat the fog. We are running out of fuel, so we are being diverted to Wellington, my ultimate destination. The diversion will screw up many passengers' connections, but at least I'll soon be home, I imagine.

An hour later we are landing in Wellington. I can practically see my house from the plane window. As we land, I am told we can not dis-embark. We will refuel and return to Auckland as soon as fog permits. The official explanation is that Wellington isn't prepared for our arrival as an international flight, and doesn't have staff on hand to process us through immigration. There are other Auckland-bound planes similarly diverted, and a long queue for refueling. We sit on the ground in Wellington for 90 minutes, told not to leave our seats due to regulations about refueling with passengers on board. It felt like being a hostage in an airport hijacking episode.

Back to Auckland. I clear immigration, and attempt to secure a transfer flight to Wellington. Everything is booked, expect the next flight that will leave in a few minutes. To catch it, I must carry my luggage myself to the domestic terminal a kilometer away. I arrive breathless at the domestic terminal to learn that my flight has delayed, for an hour (it was ultimately 90 minutes). The weather is now fine, but...the weather is to blame. Air New Zealand is off schedule to the late departure of some flight sometime earlier that day, so everyone will be punished for the rest of the day. Unlike the US, where air traffic spikes often cause delays, in New Zealand the problem is simply the availability of planes and crews.

Air travel is about the system being ready for the passenger. It is an inflexible system, with no ability to accommodate even commonly occurring events such as fog (often a problem in New Zealand, though it is discussed as though it was a strange curiousity.) Unlike almost any other customer system, there is no slack in air travel. One thing screws up, and the problem amplifies throughout the system. I know that costs are a big issue for why there is no slack, but the system has hidden costs as well. Countless hours of passenger productivity and sanity are wasted due to the logic of the producer-centric system. Airlines respond by offering lounges and wider seats at a premium cost to cushion the unpleasantness, but they don't do much to make the overall system responsive to passenger needs, such as building in flexible staffing and equipment deployment. In New Zealand the concept of "on time" departure and arrival doesn't even exist. In the US, due to various oversight pressures on airlines, these numbers are at least published, though I suspect they can be fudged if you can blame air traffic for the delay.

Someday, many years from now, airlines and airports will stop being focused primarily on asset deployment. My optimism rests on a new concept called "lean consumption", which is a complement to currently dominant idea of "lean production." Lean consumption holds that customers, not just producers, want an efficient system. And air travel is about the least efficient system in existence from a customer perspective. So it is an ideal target to fix, if not an easy one.

the special as enemy of the good

2005-06-03T13:09:00.000+12:00

Once upon a time, design aspired to be "good". The Museum of Modern Art in New York promoted examples of "good design." Good design was aspirational, but accessible. If only everyone adopted good designs, the world would be a better place. Much of the wonderful Scandinavian design produced in the 20th century embodied this philosophy. Good design was moral, and also good business. Develop a good design and watch your sales enjoy healthy returns for years to come.

We don't live in this innocent world any longer. Last night I heard a speech on 'cult' design by Thomas Gerlach, director of the German firm via4 and former frog design director. Gerlach pointed out how many beautiful prize-winning, media-celebrated designs have little market significance. What does it take to design a million-seller, or "affengeil"? Gerlach suggested the answer is to develop a design with "cult" potential. The ingredients of a cult object are the object, the target group, and a ritual around the object.

Gerlach pointed out, with some astonishment, how some products and services can become cult favorites when they seem quite strange to non-enthusiasts. Why do people spend money on Jamba ringtones, or hire boxer dogs to take to parties? Numerous products and services with cult followings seem to mock established notions of what is good design.

The market logic of cult design is easy to grasp. There are too many products, making the market noisy. To gain differentiation, one needs to develop a devoted base of enthusiasts. The way to do this is to offer something that appears special to some target group. Someone in the audience pointed out how many cult objects are often polarizing, evoking as much hate from detractors as love from followers. But even widely liked objects can seem special if they are exclusive enough (perhaps due to price) to seem special. If the price falls due to the pressure of competitive immitators, such as is happening with the iPod, the specialness starts to evaporate.

The problem with ordinary "good" design is that it doesn't offer a social identity. One can't make a hobby out of owning something that nearly everyone else owns. People seem to have a need for things they perceive as "special" so they can tell themselves they have made a choice of their own, instead of taking the bog-standard on offer. The special object or service allows them to form implicit or formal relationships with fellow travelers of the cult. Sometimes people derive status, but they may equally just want an interest that has a social aspect to it, for example, a collector's club or swap meet.

Have we given up on good design that is meant to appeal to everyone? Does everything need to be special? Is market differentiation a reflection of individual needs and aspirations, or does it shapes those needs?

telic and paratelic design

2005-06-01T12:51:00.000+12:00

The gulf between the goals of usability (just give me what I want, no more) and emotional design (this should be fun) can be understood through a concept known as "reversal theory". Developed by Michael Apter, the theory holds there are two modes in which we operate: telic, which concerns being future oriented and achieving goals, and paratelic, which concerns being in the "here and now." People switch between these modes, but our preferences in each mode are very different. Apter argues that in the telic mode, when people want to achieve goals, they want calm. If one offers something too exciting while people are focused on goals, they get overloaded. In the paratelic mode, people are bored when things are calm and serious. They aren't focused on achieving something, so they need distraction.

Usability is about the telic, emotional design is about the paratelic. What is simple and reassuring to some is dull and uninspiring to others. Different users may experience the same design as either exciting or anxiety producing -- based on their goals. If user doesn't care about winning a game, for example, the game is exciting. If he or she is dead serious about winning, it is anxiety producing.

If you are goal-focused, your ideal is to be relaxed, not but not apathetic. If you want to have fun, you want to be excited, not over-excited. There is a thin line between these states.

I think this idea has some fascinating implications. Potentially, fun might be demotivating for someone pursuing a serious goal. One might need to rethink notions that "learning should be fun" if you expect students to put in effort. The slacker student figures the only thing that matters is only the immediate experience of the moment; don't worry about getting it right or wrong -- homework isn't necessary. The serious student (think Lisa Simpson) might get stressed out by the fun.

On a website do you emphasize high returns on a mutual fund (paratelic) or explain prominently all the risks about past performance not being an indication of future performance (telic)? Some financial companies believe greed always prevails, but some people are stressed by appeals to greed. The question is my mind is: does the greedy person have serious goals and future-orientation, or is it just a game?