Information Systems and Service Design

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

L1. Course Introduction (8/26)

“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

L2. Design Contexts (8/31)

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/2)

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.

A2. Individual Assignment 2 - The BART Service System

L4. The Design Process [1] (9/9)

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

L5. Information-Intensive Case Studies (9/14)

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. Project Kick-off (9/16)

A team project with several milestone assignments gives students experience in applying methods and tools across the design lifecycle. In addition, the project will employ the idea of design contexts as conceptually coherent building blocks that enable the incremental design of many different kinds of service systems. For example, many service systems integrate person-to-person encounters and self-service contexts. Similarly, delivering some services on multiple devices or platforms and with location-based and context-awareness capabilities (e.g., through sensors in mobile phones) are natural and even inevitable technology-enabled expansions of the scope of a service system. We'll spend this lecture brainstorming and critiquing possible projects. The diverse set of case studies for the previous lecture should have given you lots of ideas.

A3. Group Assignment 1 - Project Concept

L7. The Design Process [2] (9/21)

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

Link to the podcast:  (if you click it, it should play in the browser, but you can also right-click (or Ctrl-click) and save to your local machine) http://courses.ischool.berkeley.edu/i290-1/f09/Readings/ISSD-20090921.mp3 

L8. Stakeholders / POVs (9/23)

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.

Link to the podcast: (if you click it, it should play in the browser, but you can also right-click (or Ctrl-click) and save to your local machine)http://courses.ischool.berkeley.edu/i290-1/f09/Readings/ISSD-20090923.mp3

L9. Service Encounters / Touch Points (9/28)

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.

L10. Self-service (9/30)

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.

L11. Computational Services (10/5)

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.

A5. Group Assignment 2 - Service Brainstorm

A4. Individual Assignment 3 - Service Brainstorm

L12. Segmentation, Personalization & Customization (10/7)

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.

L13. Quality - Design (10/12)

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.

L14. Ethnography Continuum & Techniques [1] (10/14)

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

L15. Ethnography Continuum & Techniques [2] (10/19)

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

(Download recorded lecture from http://courses.ischool.berkeley.edu/i290-1/f09/files/ISSD-20091019.mp3  )

L16. Requirements & Use Cases [1] (10/21)

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.

(Download recorded lecture from http://courses.ischool.berkeley.edu/i290-1/f09/files/ISSD-20091021.mp3  )

A7. Group Assignment 4 - Requirements and Use Cases

L17. Requirements & Use Cases [2] (10/26)

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

(Download recorded lecture from http://courses.ischool.berkeley.edu/i290-1/f09/files/ISSD-20091026.mp3  )

L18. User / Actor Models & Personas (10/28)

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.

(Download recorded lecture from http://courses.ischool.berkeley.edu/i290-1/f09/files/ISSD-20091028.mp3  )

L19. Process Modeling [1] (11/2)

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

(Download recorded lecture (first few minutes are missing) from http://courses.ischool.berkeley.edu/i290-1/f09/files/ISSD-20091102.mp3  )

A8. Group Assignment 5 - Blueprints

L20. Process Modeling [2] (11/4)

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.

(Download recorded lecture from http://courses.ischool.berkeley.edu/i290-1/f09/files/ISSD-20091104.mp3 )

L21. Multichannel Context (11/9)

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.

(Download recorded lecture from http://courses.ischool.berkeley.edu/i290-1/f09/files/ISSD-20091109.mp3 )

L22. Multi-device Context (11/16)

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.

(Download recorded lecture from http://courses.ischool.berkeley.edu/i290-1/f09/files/ISSD-20091116.mp3 )

L23. Context-aware Context (11/18)

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

(Download recorded lecture from http://courses.ischool.berkeley.edu/i290-1/f09/files/ISSD-20091118.mp3 )

L24. Prototyping (11/23)

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.

(Download recorded lecture from http://courses.ischool.berkeley.edu/i290-1/f09/files/ISSD-20091123.mp3 )

A9. Group Assignment 6 - Prototyping Plan

L25. Project Status Report Presentation (11/25)

No lecture from me and no reading assigned.  Each project team will take 8-10 minutes to present a status report. This should begin with a crisp description of your project's scope, primary stakeholders, and point of view. Next tell us what your M and S priority requirements are, and give some examples of design ideas for satisfying them. If use cases, blueprints or other process models would make it easier to communicate your work, present them. If you have less precise ideas, just discuss design ideas organized by "seven contexts." In either case, present as much "traceability" to previous work as you can specify.  Finally, tell us what else you expect to accomplish by the end of the semester (what specific "design artifacts" are you aiming to produce).

The primary goal of this status report is to get your team to evaluate where it is and make decisions about what can and what can not be accomplished in the remaining three (or at most four) weeks until your final presentations. Your team will be able to decide if it can make a final project presentation on Wed 12/9 or whether it wants to do one on Tuesday 12/15. I'd like to make a firm schedule for this as soon as all the presentations are finished.

A secondary goal is to inform your classmates about your work; they are likely to have comments and suggest design ideas for your projects.

L26. Iteration (11/30)

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”

(Download recorded lecture from http://courses.ischool.berkeley.edu/i290-1/f09/files/ISSD-20091130.mp3 )

L27. Quality Evaluation and Operation (12/2)

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.

(Download recorded lecture and course review from http://courses.ischool.berkeley.edu/i290-1/f09/files/ISSD-20091202.mp3 )

A10. Individual Assignment 4 - Take-home Check Point

L28. In-Class Project Consulting Session (12/7)

Professor and TAs will be ready and willing to meet with any project team.

L29. Project Presentations (12/9, 12/15)

Presentation 12/9 (regularly scheduled class time, Room 202)

• Frontline World - Vision 2015 (Donna Leo, Michael Porath, Jeremy Whitaker)

Frontline World is a non-profit journalistic organization and a subsidiary of WGBH's Education Foundation. FLWorld is partnered with the highly regarded Frontline, but breaks from Frontline's more traditional documentary, long format journalism, by producing shorter Internationally themed pieces, emphasizing the web for added value, distribution, and user engagement.

In order to define a service system for Frontline World, we outlined a vision for five years from now, naming it Vision 2015. The service system takes into consideration the type of audience that the FLWorld team wants to serve. A central entity ("the portal") serves both as the metaphor and the back end system for an integrated process workflow that is used by editors, consumers, journalists and syndication services as primary stakeholders. The service system evolves around the portal.

• Education Portfolio Service System (Erin Knight, Nathan Gandomi, JinYoung Baik)

There are two common issues students and instructors face in most education environments.  The first is that there are typically a large set of documents and resources - including course content provided by the instructor, student-generated content and social content - in multiple formats and mediums, that the students must manage for each course. This issue is exponentially increased when students are enrolled in multiple courses.  The second issue is that for each course, all of the content and material is typically "stuck" within the coursesite and essentially disappears once the course is completed.  Both of these issues make it difficult to revisit content or to find connections across resources, thus limiting the amount of reflection and synthesis students can achieve.

In response to these issues, e-Portfolios emerged in the last 10 years, offering content management, lifetime access to content, and transformation tools to students. However, the existing e-Portfolio systems require the student to manually upload or publish content to the portfolio.  While this starts to mitigate the issues, it still puts a heavy burden on the student and only captures content that the student thought to upload at that particular time, which still limits any comprehensive reflection or discovery across material, especially after some time has passed.  Additionally, these systems typically save content in the traditional desktop manner, with content buried within folders and difficult to reconnect.

We are developing a Portfolio Service System that automatically captures all content from the course site and organizes it based on the tags provided by the class, as well as the contextual metadata provided by the course site.  And instead of presenting the information as a set of folders, our system will present "learning trails" and a wider "learning graph" so that students can traverse the entire learning experience, and find connections within and across courses.

• Diasporta (A Brooks, M Manoochehri, S Lee, B Ekaterin)

Diasporta helps to satisfy social gaps in the way sports media is consumed, by meeting the needs of geographically dispersed sports fans who crave the intermittent social contact that characterizes supporting professional sports teams. Disporta will provide fans with tools to meet other "expat" fans near them, and provide  them with low-effort ways in which they can leverage already existing social networks to make support of their favorite teams more enjoyable.

• MUSE (Jessica Voytek, Ljuba Miljkovic, Eva Reinstadler)

Our project proposes to design a mobile application for visitors to interact with art in ways that are not yet widely available, and an affordable, simple to implement system for museum staff to create, organize, and publish authoritative content to augment their physical collections.  In addition to the authoritative content, we would also like to explore features that would allow visitors to create their own content associated with specific artifacts inside and outside of the physical museum space.  These features include the ability to rate and comment on artifacts, and explore supplementary material associated with an artifact.

• Crohnology.MD (Ayush Khanna, Christian Schraml, Nikolai Kirienko)

We want to build a system that aids patients of the Crohn's disease record,manage and visualize their information. The typical doctor appointment is a 10-15 minute window, and presenting the right data to your physician is a challenging task. The difficulty in measuring Crohn's symptoms further complicates this problem. By empowering the patient and the provider with data, we want to improve the overall healthcare quality for Crohn's patients.

Presentation 12/15 (2:00-3:30 in Room 202)

• Reseller Service System (Amy Haas, Prateek Kakirwar, Priyanka Reddy)

The implementation of the Consumer Product Safety Improvement Act of 2008 (CPSIA) has now made selling recalled products illegal. Consequently, the CPSIA has created the need for dramatic changes to the existing business processes within the reseller marketplace. New requirements imposed on importers and manufacturers should result in safer products entering the resale market in the future, but right now, resellers need a solution for checking their inventories to determine if any products have been recalled. The goal of our group project is to help fill this gap and provide a solution for resellers in the form of a customizable “Inventory Checker” application. Our group has partnered with the product safety group, WeMakeItSafer, to expand upon their beta web-hosted “Inventory Checker” solution to create a customizable solution that resellers can use on any platform they wish (i.e. computer, mobile device, in-store kiosk, etc.).

• Smart Home (Karen, Heather, Stephanie, Sohyeong)

MiCasaVerde makes Vera, an easy to use Smart Home technology based on a wireless router.  Currently, it has basic functionality and is not as user friendly as MiCasaVerde claims. We designed a service system to empower developers at all levels with the intention of creating a more diverse and active development community that will lead to richer features and improved usability.

• Medical Messaging (Abe Coffman, Annette Greiner, Kimra McPherson, Lee Schneider)

The UCSF Urological Oncology clinic deals with a large number of phone and online messages each day relating to patient lab work: whether patients have had labs done, whether the results have arrived at the clinic, whether doctors have discussed those results with patients, etc. Currently the system has two major components: Mercury Message, a system that sends messages between the UCSF call center and the clinic, and Relay Health, a portal used by providers and patients. We envision a system that would seamlessly communicate lab report status and results between the parties, eliminating the need for patients to phone the call center only to learn their results aren't in and the need for providers to follow a complicated and time-consuming trail to track down results from various patients, hospitals, and labs.

• Smart Water Management - California Agricultural Irrigation Management Solutions (Marianne, Jackson, Kate)

MyCIMIS - California Irrigation Management Information System (CIMIS) - Department Of Water Resources, Office Of Water Use Efficiency (http://wwwcimis.water.ca.gov/cimis/myCimis.jsp)

CIMIS is a project of the California Department of Water Resource’s Office of Water Efficiency. CIMIS provides California’s irrigators with weather data, free of charge, to help them manage their water resources effectively and efficiently. MyCIMIS was created for irrigators to have individual accounts and request customized information reports. The report preferences include weather stations (130 locations throughout California), data types (e.g. evapo-transpiration rate) and frequency of report.

Our project aims to improve the current MyCIMIS platform and help expand the farmer user base. Our approach is to provide value-added services to the current data offerings to attract farmers to MyCIMIS. Non-water efficiency related services for farmers will be explored as a potentially beneficial component of MyCIMIS, such as frost warnings and fertilizer management recommendations from onsite sensor networks. In order to achieve this goal, we aim to understand what information farmers utilize most frequently to inform irrigation management practices and to understand other data that would prove useful to farmers.

We will create multi-channel solutions to accommodate the wide variance in technology adoption by farmers:

1. Improve the MyCIMIS online custom report manager interface. Not only will we expand the offerings to entice farmers, but additionally will adjust some existing complications with the report request process. Create a report format that highlights the most important data in a comprehensive manner. The current format is raw data in an Excel spreadsheet.
2. Develop the user interface for a smartphone application utilizing our improved version of MyCIMIS.
3. Outline offerings for low-tech farmers that provides access to similar data via telephone calling, fax, and SMS services.

We are considering dispensing synthesized data presented in charts and graphs, and would like to know what is the most useful data format for farmers. We will generate prototypes of the report request website, the customized report deliverable, and the smartphone application interface.

A11. Group Assignment 7 - Final Presentation and Report