Interactions - September/October 2009

least six types of sensors. We are on the cusp of a huge wave of sensor technology. Sensors will be embedded in everything, and they will pour out a continuous flood of data.

9. SERVICE DESIGN / SERVICE SCIENCE Service design and service science refer to the process of developing and managing services. As hardware becomes increasingly commoditized, services offer opportunity for differentiation. A customer’s experience with a brand may extend across a family of services, each with a collection of touch points. These touch points are increasingly networked, and thus customer behavior may be logged, analyzed, and used to drive improvements.

10. SOCIAL MEDIA

Social media refers to media (communications channels, most often enabled by the Internet) in which users create most (or all) of the content. Users engage in conversations with each other—sometimes about and with businesses that serve them. Participating in social media and its attendant conversations is a growing part of managing relations with customers. Social media are forms of crowd sourcing—or crowd sourcing from another perspective.

The next generation of computing will assemble vast stores of data—from a growing array of physical and virtual sensors. These technical and social changes will create opportunities for a wide range of companies. Consumer electronics makers like Apple will monitor their hardware and supporting services. Network-tools makers like Cisco will instrument their customers’ networks. Google (and other Web-services providers) will continue to instrument search and everything you do with their tools. Health care device makers like Johnson & Johnson will increasingly offer services to complement products that continuously monitor your vital signs. Sports and apparel makers like Nike will also build biometric sensors into the soles of their shoes and the fabrics of their clothes, supporting another form of continuous monitoring.

Apple, Cisco, Google, Johnson & Johnson, Nike, and others like them will find themselves in essentially the same business, certainly dealing with the same customer management, design management, and information technology management questions. They will have entered the era of customer-data-driven business.

tate analysis of the reports. Tools that facilitate categorization and visualization of data pay for themselves in short order. Otherwise, time will be spent telling the bug reporter, “I can’t reproduce your problem.”

Server-side logging. The simplest and most cost-effective technique is to execute server-side system logging. Then scripts can be run to collect and analyze the logged data.

The main advantage of this approach is that little planning is required to generate data because there are no changes to the device code. In the simplest case, an IT operator or engineer adds some logging code (using the existing logging framework) to a server-side component. These changes are usually low risk to any release. This modification gets deployed to the main user population at the next server-side software release.

However, back-end logging alone doesn’t provide a rich picture of the user experience because many behavioral issues can be resolved only via data from the device side.

In addition, tools construction is required to “extract knowledge from data.” Mike Kuniavasky gives an overview of both the benefits and issues with server-side logging [ 13].

Device logging. Logging from the client side is more complex than logging from the server side, because device logging has to handle the transmission of state back to the mother ship. In addition, the organization has to be willing to pay the bandwidth cost required to send back the data.

The simplest code approach is to just add a logging function to each “user event” (such as a key-press). This is analogous to a website “click-stream.” The UI framework may have a very small number of places where this logging code could occur. So the implementation can be both simple and broad. The downside, of course, is that an enormous amount of data is generated and transmitted and most of the data is not germane to the user experience questions at hand.

Fundamentally, this functionality is only useful for debugging purposes when focused on a small number of users.

A more complex approach is to log, for the purposes of a targeted experiment, only the data germane to the researcher’s question. This requires custom code to map between various system states and the user state. This code can be more complex because it is integrated into the application logic