Home › Syllabus

Information Systems and Service Design

INFO 228 (CCN 42590)
MW 2-3:30, South Hall, Rm 210 (Lab: Tu 5-7 every other week); Office Hours M 3:30-4:30 Rm 313

L01. Course Introduction (Mon, 08/29/2011 - 2:00pm)

“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. Personal Background (Ind.) (Due: 08/31/2011)

A2. The BART Service System (Ind.) (Due: 09/07/2011)

L02. Service Design Contexts (Wed, 08/31/2011 - 2:00pm)

Service systems combine and integrate the value created in different design contexts. These contexts include person-to-person encounters, technology enabled self-service, computational services, multi-channel services, multi-device services, and location-based / context-aware services. 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.

W1. Project Concept Workshop (Tue, 09/06/2011 - 5:00pm)

  • Project Requirements
  • Roll of TAs
  • Tour of Prior Projects
  • Project Idea Pitches
    • [TBD]
  • Break
  • Team Time

    L03. Stakeholders & Risk Management (Wed, 09/07/2011 - 2:00pm)


    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.

    In addition to managing stakeholders, a project team should also manage risk. Risk Management--the practice of identifying, assessing, and prioritizing project risk-- helps teams develop a risk strategy determining which risks should be accepted (do nothing), avoided, mitigated, or transferred (as to a third party).

    A3. Project Concept/Charter (Grp) (Due: 09/14/2011)

    L04. Organizational Contexts (Mon, 09/12/2011 - 2:00pm)

    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.

    L05. Service Encounters & Touch Points (Wed, 09/14/2011 - 2:00pm)

    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 a series of back and front stage service encounters 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.

    A4. Stakeholder Analysis and Risk Assessment (Grp) (Due: 09/19/2011)

    L06. Person to Person (P2P), Tech Enhanced P2P, & Self-Service (Mon, 09/19/2011 - 2:00pm)

    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.  At one endpoint of the continuum are person-to-person services, at the other are self-service ones, and in between are those in which technology enhances person-to-person services.

    This perspective makes "substituting information for interaction" a unifying concept in service system design.  It applies to the P2P to Self-service continuum, and also lets us understand a similar continuum between "experience-intensive" and "information-intensive" service systems that have up to now have been thought to require different design concepts.  

    A5. Research for Service Brainstorm (Ind.) (Due: 10/03/2011)

    A6. Service Brainstorm (Grp) (Due: 10/03/2011)

    W2. Service Brainstorm Workshop (Tue, 09/20/2011 - 5:00pm)

    1. Go over Project Websites
    2. Review Service Brainstorm assignment
    3. 5 minute project intros; 5 minutes Q&A with whole class (90 mins)

      L07. Multi-Channel & Multi-Device Contexts (Wed, 09/21/2011 - 2:00pm)

      As the Web matured as a platform for online commerce and information services, firms like Amazon.com with no physical presence became competitive threats to incumbents like Barnes & 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 improve service delivery to citizens and let them avoid inefficient face-to-face encounters in government offices. The key strategy and design decisions for multi-channel 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.

      In addition to multiple channels, most people also use one or more devices to obtain information services: cell phones, smart phones, personal computers, tablets, 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.

      L08. Context-Aware & Computational Contexts (Mon, 09/26/2011 - 2:00pm)

      "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, 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.

      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.

      L09. Design Concepts & Traceability (Wed, 09/28/2011 - 2:00pm)

      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.

      Traceability is an important goal because good designs not only solve problems and satisfy stakeholder requirements; they can demonstrate why they do so by explicitly relating design decisions to observations, analysis, and other design activities,    If we record the dependencies, influences, and causal relationships between design work and  design outcomes we create designs that  are easier to justify to stakeholders and that are easier to adapt to meet changed requirements.

      L10. Ethnography Continuum & Techniques (1 of 2) (Mon, 10/03/2011 - 2:00pm)

      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" side 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. 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.

      A7. Ethnography (Grp) (Due: 10/17/2011)

      W3. Ethnography Workshop (Tue, 10/04/2011 - 5:00pm)

      Clarification of traceability and work on Traceability Worksheet. 15 mins
        • A five minute clarifying description, based on the email I sent out.
        • Time for each team to identify 5-7 traces from their service brainstorm (10 minutes)
      Ethnography Planning. 45 mins
      • Information on how to prepare your ethnography plan (10 minutes)
      • Ethnography Planning Group Workshop (35 minutes)
      Break. 5 mins

      Ethnography Plan Discussion. 45 mins
      • Round-robin: We will rotate through team pairings (one pairing with Bob and the TAs) and give feedback on the ethnography plans.

        L11. Ethnography Continuum & Techniques (2 of 2) (Wed, 10/05/2011 - 2:00pm)

        Locating and understanding documents and information sources always requires a mixture of "anthropology" (observing their use) and "archaeology" (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

        L12. Design Process (Mon, 10/10/2011 - 2:00pm)




        L13. Design Methods (Wed, 10/12/2011 - 2:00pm)

        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."

        L14. Requirements & Use Cases (1 of 2) (Mon, 10/17/2011 - 2:00pm)

        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.

        A8. Requirements and Use Cases (Grp) (Due: 11/02/2011)

        W4. Requirements & Use Cases Workshop (Tue, 10/18/2011 - 5:00pm)

        • Diagramming tools and RAVEN Cloud (30 mins)
        • Use Case exercise (30 mins)
        • Break (5 mins)
        • Work on requirements and use cases in teams (45 mins)

          L15. Requirements & Use Cases (2 of 2) (Wed, 10/19/2011 - 2:00pm)

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


          A9. Take-Home Midterm (Ind) (Due: 10/28/2011)

          L16. Personalization & Customization (Mon, 10/24/2011 - 2:00pm)

          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.

          L17. Team Touchbase (Wed, 10/26/2011 - 2:00pm)

          Teams will informally share progress with other teams, the TAs, and Bob to get feedback that will better inform future work.

            L18. Process Modeling (1 of 2) (Mon, 10/31/2011 - 2:00pm)

            “Process Analysis” can be generically described as follows: 
            • Performing an "as-is" analysis of how some activity is conducted today 
            • Identifying requirements that may result in new or revised activities / processes / transactions; the "to-be" model
            • Looking for existing patterns or opportunities to use patterns in the models
            • Maybe "re-engineering" 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.

            A10. Service Blueprint or Process Model (Grp) (Due: 11/14/2011)

            W5. Service Process Models & Blueprints Workshop (Tue, 11/01/2011 - 5:00pm)

            [TBD]

              L19. Process Modeling (2 of 2) (Wed, 11/02/2011 - 2:00pm)

              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.

              L20. Design Patterns (Mon, 11/07/2011 - 2:00pm)

              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.

              L21. User/Customer Models & Personas (Wed, 11/09/2011 - 2:00pm)

              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.

              L22. Prototyping (Mon, 11/14/2011 - 2:00pm)

              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:
              1. Cost and Effort - as constrained by a design project's budget, schedule, and designer capabilities
              2. 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.

              A11. Prototyping (Due: 12/05/2011)

              W6. Prototypes Workshop (Tue, 11/15/2011 - 5:00pm)

              • Review prototyping tools (20 min)
              • Brainstorm cargo cult ideas in your team (30 mins)
              • Share cargo cult ideas in groups of three teams each (20 mins per team -- 1 hr)

                L23. Iteration (Wed, 11/16/2011 - 2:00pm)

                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.

                L24. Quality in Design (Mon, 11/21/2011 - 2:00pm)

                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.

                L25. Team Touchbase (Wed, 11/23/2011 - 2:00pm)

                Teams will informally share progress with other teams, the TAs, and Bob to get feedback that will better inform future work.

                  L26. Quality in Operation & Evaluation (Mon, 11/28/2011 - 2:00pm)

                  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.

                  A12. Final Presentation (Grp) (Due: 12/06/2011)

                  A13. Final Report (Due: 12/14/2011)

                  L27. Course Retrospective (Wed, 11/30/2011 - 2:00pm)

                  This class will provide a retrospective view of the entire course.

                    Final Project Presentations (Tue, 12/06/2011 - 5:00pm)

                    AGENDA FOR FINAL PROJECT PRESENTATIONS

                    5:10 Welcome and Introduction to the Event (Bob)
                    5:15-5:27 Audio Archives (Group 1)
                    5:27-5:39 Green Data (Group 2)
                    5:39-5:51 DARS (Group 5)
                    5:51-6:03 Health Clinics (Group 4)
                    6:03-6:15  Winery Passport (Group 9)
                    6:15-6:30 break (popcorn and non-alcoholic beverages)
                    6:30-6:42  Trash (Group 8)
                    6:42-6:54  Making Visible (Group 7)
                    6:54-7:06 I find UC (Group 6)
                    7:06-7:18 Code for America (Group 3)
                    7:18-7:20 closing remarks

                    reception - break out the wine and beer now