Information Systems and Service Design

INFO 228
MW 2:00-3:30, South Hall 202

L1. Course Introduction (8/30)

“Service” once only implied face-to-face interactions between two people, one offering the service and the other receiving it. But in today’s service-led and information-powered economy, service domains and interactions are vastly more complex. An “outside-in” or “customer-centric” design perspective is important, but it is essential to take a “service systems” perspective that combines the visible “front stage” where service providers and customers interact with the invisible “back stage” where information and resources needed by the front stage are created and managed.

A1. Individual Assignment 1 - Personal Background

A2. Individual Assignment 2 - The BART Service System

L2. Design Contexts (9/1)

Service systems combine and integrate the value created in different design contexts like person-to-person encounters, technology enabled self-service, computational services, multi-channel, multi-device, and location-based and context-aware. Most designers are familiar with some of these contexts, but few service designers are familiar with all of them. Because the design concerns and methods in one context can seem incompatible with those in others, there is relatively little work that analyzes design concerns and methods that span multiple contexts. Doing exactly that is the point of this course.

A more abstract view that focuses on the information required to perform the service, how the responsibility to provide this information is divided between the service provider and service consumer, and the patterns that govern information exchange yields a more flexible description of service encounters and outcomes that applies to all the design contexts.

L3. Organizational Contexts (9/8)

The design of any service -- whether it will be performed by people or by information systems -- takes place in a context of: • Current and potential customers • Current and potential technologies • Current and potential competitors • Existing services or systems • Existing user or application interfaces • Legal, regulatory, cultural systems and constraints These factors or constraints can never be equally important; how they are weighted determines the appropriate design methodology and the key characteristics of the design.

A3. Group Assignment 1 - Project Concept/Charter

CS1. Project Kick-Off (9/8 5-7pm)

L4. Stakeholders/POV (09/13)

Who are we designing for? A service system might have users, operators, customers, clients, citizens, managers, buyers, champions… and in any particular domain we would classify them more precisely as doctors, patients, teachers, students, and so on. We need the broader concept of “stakeholder” to include "all the claimants inside and outside the firm who have a vested interest in the problem and its solution.” The actor or service at the end of an information flow, often the stereotypical “end user” or “customer,” is usually designated (often by default) as the most important stakeholder or focal point of the service system, especially when the service system contains a person-to-person context. Nevertheless, this point of view is arbitrary, and many of the actors or services in a service system could be alternative or secondary points of view, resulting in a different design.

L5. Information-Intensive Case Studies (09/15)

Information-intensive services are those in which information actions or processing are responsible for the greatest proportion of value created by the service system. The most information-intensive ones are those with few or no requirements for physical and personal interactions, or where personal interactions are narrowly focused on the information exchange needed to make decisions and apply other information. In these service domains documents, databases, software applications, or other explicit repositories or sources of information are ubiquitous and essential to meeting the goals of the service consumer or customer. Even service types that are dominated by physical or interpersonal actions, and which are thus “experience-intensive,” usually require information exchanges to specify and co-produce the service.

L6. The Design Process [1] (09/20)

Because the specific concepts, methods, and technologies of design differ across contexts, we need to introduce some more abstract ways of thinking about design. In particular, whenever we design something we follow (implicitly or explicitly) some steps or techniques for scoping, analysis, idea generation, and implementation. This design methodology makes assumptions about which design questions can be separately answered, the priorities and dependencies, and who can best answer them. Some design methods prescribe activities in a fixed sequential order, while others are more iterative or recursive. Artifact or work product-centered design methods specify activities, but put more emphasis on the artifacts or work products that result from them than on the way in which they are created. And so on...

L7. The Design Process [2] (09/22)

Unless the design projects taken on by an organization or team are always for the same context, with similar scope and requirements, they will not follow the same design methodology on every project. There will be always be a need to adapt the methodology in some way, emphasizing some activities more or less than usual because of schedule, resource, or stakeholder considerations. So in practice, the "methodology" employed in any given project is likely to be a subset of design techniques selected and adapted for it from a larger portfolio. IBM consulting calls this adaptation of its "standard" methodology the "Engagement Model."

A4. Individual Assignment 3 - Research for Service Brainstorm

L8. Service Encounters / Touch Points (09/27)

The service system concept embodies the essential claim that a service outcome is never the result of a single encounter between a service provider and service consumer. Instead, it emerges from the service system of back and front stage services that establish the context and satisfy the preconditions for the final service encounter to take place. There may be a ‘‘moment of truth’’ in which the quality of the service experience becomes apparent to the service consumer, but that quality was enabled or constrained to a greater or lesser extent by the entire service system.

A5. Group Assignment 2 - Service Brainstorm

CS2. Project Concepts & Service Brainstorm (9/27 6-7pm)

L9. Ethnography Continuum & Techniques [1] (09/29)

Design contexts range from "experience-intensive" to "information-intensive.” On this continuum "documents" and other information sources go from being incidental or occasional to being ubiquitous and intrinsic to the goals and activities of the stakeholders and actors. Put another way, on the "experience-intensive" send of this continuum the most important things to study are (human) participants, and on the "information-intensive" end we need to pay most attention to the documents. Put yet another way, we can learn mostly from "informants" or we can learn mostly from "information." In this first lecture we’ll talk about ethnographic techniques of “contextual inquiry” that emphasize participant observation and interviews to understand behavior and goals in a particular context.

A6. Group Assignment 3 - Ethnography

L10. Ethnography Continuum & Techniques [2] (10/04)

Locating and understanding documents and information sources always requires a mixture of "anthropology" ("observing their use") and "archeology" ("digging into their history"). Document designs are often the most enduring aspects of business processes, lasting for years or decades, far longer than the tenures of the specific people who produce and use documents. How we conduct "document anthropology and archeology" differs substantially among three different contexts: • Within an organization or enterprise • Between organizations or enterprises • Within an information ecosystem

L.11 Self-Service (10/06)

Using technology to transform person-to-person services into self-service ones eliminates the frontline employee and moves back the line of visibility between the front and back stage, giving the customer access to information that was previously visible only to the frontline employee. A more subtle way to understand the impact of introducing technology in a service encounter is that it changes the proportions of physical, interpersonal, and information actions. From this perspective, these proportions are design parameters that can be systematically adjusted by technologies that enable the different types of actions to substitute for each other.

L12. Computational Services (10/11)

Computational services are “pure” information services that are typically carried out entirely by automated services without any human involvement or physical actions. These services are designed using principles and techniques of “document engineering,” “web services,” or “service-oriented architecture”. These design perspectives view the service system abstractly as a set of cooperating services that interact by exchanging information through well-defined interfaces that specify the inputs and outputs of each service.

L13. Requirements & Use Cases [1] (10/13)

When a problem or opportunity is defined and scoped, any constraints on possible solutions or goals that must be satisfied can be viewed as requirements - “conditions that must be met for the solution to be acceptable to the stakeholders." Requirements do not dictate how the solution is to be achieved; that is the responsibility of design. Requirements can be quantitative or qualitative, but in all cases should be verifiable. Specifying requirements using business rules or using "simplified technical English" makes them easier to validate and communicate. Going a step further, when requirements can be captured as “decision rules” or “business rules” we can implement and enforce some classes of them using a "rules engine" or "decision service" rather than scattering them into application code.

CS3. Ethnographies (10/13 6-7:30pm)

L.14 Requirements & Use Cases [2] (10/18)

A use case is an outside-in or "black box" depiction of a system's functionality from the perspective of an "actor". Use cases define possible sequences of interactions or procedures between actors and the system that achieve some goals or otherwise result in successful outcomes for users (and often, other stakeholders). Text is a suitable format for specifying a use case but any text specification in "natural language" can easily be incomplete, inconsistent, or ambiguous, which is why "best practices" for writing text specifications include "simplified writing" and "business rules" (with controlled grammar, vocabulary, and logic flow).

A7. Group Assignment 4 - Requirements and Use Cases

L15. Personalization & Customization (10/20)

Customers want products and services that fit their individual needs in as specific a way as possible. Providers usually segment the population of potential customers for their products and services, but would prefer to meet the specific needs of individual customers. The degree to which a person-to-person service can be personalized is limited by the extent to which the frontline employee is able to interact with the customer to obtain information about the customer’s requirements and preferences. It also depends on the customer’s willingness or ability to provide the information. Automated recommendation systems used by many service providers employ very sophisticated data mining and business intelligence algorithms that aggregate and analyze millions of transactions and queries.

A8. Individual Assignment 4 - Take-Home Midterm

L.16 Quality - Design (10/25)

The highly subjective nature of most dimensions of service quality means that it is most sensible to use customer-centered measures. Quality is defined as the difference between the level or nature of service that the customer expected and the level or nature that the customer perceives. But since customers have different experiences and goals, they will differ in their expectations, which complicates the task of the service or information system designer.

L.17 User / Customer Models & Personas (10/27)

Front-end designers, back-end developers, marketing, customer service, and many other participants in service system design or operation each employ some set of qualitative or quantitative techniques to model the actor, customer or user of the service. Unfortunately, each of these models has some limitations of its own and even worse, collectively the models can be inconsistent and incompatible. For example, user interface and user experience designers often create one or more ‘‘personas,’’ fictional characters that represent typical customers or user groups for a product or service. In contrast, marketing or customer support organizations use “hard data” to segment a customer base into different groups using demographic and psychographic variables.

L.18 Process Modeling [1] (11/01)

“Process Analysis” can be generically described as follows: • We perform an "as-is" analysis of how some activity is conducted today • We identify requirements that may result in new or revised activities / processes / transactions; the "to-be" model • We look for existing patterns or opportunities to use patterns in the models • We may "re-engineer" the "as-is" model to optimize the processes; this is process design The set of processes and activities are usually arranged in a hierarchy of detail, their sequence of execution, or both (depending on which if any stakeholder's or actor's point of view is used to define the context). Some sort of diagram is conventionally used to represent the relationships between the actors and activities in the model. Many times this semester we've contrasted (or caricatured) two ends of a design continuum between "experiences" and "systems," and we'll do the same for process analysis and models. In this first lecture we’ll discuss the service blueprinting technique often used to model services with a dominant person-to-person context. We’ll also discuss approaches for optimizing process models by eliminating activities and iterations that don’t add value.

L.19 Process Modeling [2] (11/03)

In this lecture we introduce concepts and methods for process modeling of information systems and information-intensive services. We’ll discuss the multi-level conceptual model of a "business process" developed by the ebXML standards effort: • A process consists of one or more collaborations • A collaboration consists of one or more transactions • The transaction is the basic unit at which information exchanges occur between the participants (e.g, the service provider and customer) We'll also discuss transaction patterns.

L19R1. Robert J. Glushko & Tim McGrath, Chapter 9, "Document Engineering", MIT Press, 2005

A9. Group Assignment 5 - Service Blueprint / Process Modelling

L.20 Multichannel Context (11/08)

As the Web matured as a platform for online commerce and information services, upstart firms like Amazon.com with no physical presence became competitive threats to incumbents like Barnes and Noble. For these “brick and mortar” firms, creating a web channel was an urgent and critical strategic decision, and the concept of “multi-channel services” as a distinct service design context emerged. The Web channel also inspired the vision of “E-government” services that would radically improve service delivery to citizens and let them avoid inefficient face-to-face encounters in government offices. The key strategy and design decisions for multichannel services concern the allocation of services to one or more channels and the manner in which the channels fit together. These decisions ultimately are implemented in terms of the content, direction, and reciprocity of information exchange between the channels.

L.21 Multi-device Context (11/10)

Most people use one or more other devices other than personal computers to obtain information services. In fact, many times more people in the world use mobile phones than personal computers, and many use PDAs or other devices. The proliferation of devices and network alternatives is a challenge for service system designers. If a service provider’s intended customers use different or multiple devices, the service must be designed to work on all of them. But there is little consensus about the best approach for designing services to run on multiple devices or platforms.

A10. Group Assignment 6 - Prototyping

L.22 Prototyping (11/15)

A design space can be large and complex, and we can't explore it all at once. Prototypes are representative and manifested forms of design ideas to "view a design's future impact" before it gets built. Proototyping techniques are traditionally contrasted on two dimensions: • COST AND EFFORT - as constrained by a design project's budget, schedule, and designer capabilities • FIDELITY - how realistic or similar is the prototype artifact to a final product or service? But this contrast is too simplistic to describe the range of prototype techniques being used today. For example, for information-intensive services and systems it is much more important to use prototypes to assess the quality and feasibility of the information models.

L.23 Context-Aware Context (11/17)

"Location" is the most obvious attribute that might be used to make a service "context-aware," but not the only one. Context has been defined as "any information that characterizes a situation related to the interactions between users, applications, and the surrounding environment." The environment consists of places, people, and things, and for each entity there are four categories of context information: location, identity, status (or activity), and time. From the perspective of service design, once again the key principle is that information replaces interaction. There is no need to ask a customer to supply location, time, or other contextual information that the provider has obtained or inferred from another service or sensor. Likewise, there is no value in providing information to the customer that isn’t relevant to his location or context.

A11. Group Assignment 7 - Final Report

CS4. Prototypes (11/17 5-7pm)

L.24 Iteration (11/22)

Every design effort inevitably has some work that needs to be done more than once. An iteration is the cycle by which a work product, artifact, or design is revised after evaluating feedback from a stakeholder. When “designing the iteration” we need to answer these questions: • What is the project scope to which iterative methods will be applied? • What are the processes in each iteration? • What is the "cycle time" of the iteration? • What kind of feedback will be collected and what will be done with it? At a more macro level, we need to recognize that identifying stakeholders, determining their priority, and setting the priority of requirements elicited from them depends on the scope of the design project. These are inherently iterative tasks that require activities to maintain “continuous stakeholder alignment”.

L.25 Quality - Evaluation & Operation [1] (11/24)

Because requirements evolve and are refined during the design lifecycle, some early stage usability methods can only partly predict the usability of the deployed system or service. Some usability methods require a working system or prototype and the involvement of users, neither of which might be available during early stages of the design lifecycle. So there's potential conflict between software architecture - which is an early stage activity - and late stage usability efforts. Service failures occur when a service encounter falls short of the customer's expectations. If this failure is apparent to the service provider, recovery actions might be attempted. For information services, service quality and recovery are often governed by a service level agreement that quantifies the minimum quality of service that satisfies business needs.

L.27 Design Patterns [1] & [2] (CANCELED)

Patterns improve designs by replacing an ad hoc approach with a successful one. Design patterns also promote reuse, which has the immediate benefit of reduced training, implementation and maintenance costs, and longer-term benefits of encouraging and reinforcing consistency and standardization. Reuse at more abstract levels enables interoperability between systems that follow patterns that differ at more concrete levels. The design patterns for information systems and services span the broad “abstraction hierarchy” we’ve talked about when modeling processes. For example, we can describe business activity using: • Business model or organizational patterns: marketplace, auction, supply chain, build to order, drop shipment, vendor managed inventory, etc • Business process patterns: procurement, payment, shipment, reconciliation, etc. • Business information patterns: catalog, purchase order, invoice, etc. and the information components they contain for party, time, location, measurement, etc.

Many design patterns for service experiences are abstract qualitative depictions of the "value chains" that create positive outcomes for customers or other stakeholders. They provide frameworks for design choices that encourage or constrain the experiences, so they can serve as templates for a set of related service offerings that vary in the number or intensity of encounters or co-production. Traditional service design mechanisms like scheduling and demand management can be used as patterns in this way.

User login

Navigation

Syllabus (Extended Version)

Information Systems and Service Design