Doc Or Die

For most of my professional career I've designed and deployed information-intensive applications, systems, and services. Almost 30 years ago, when I was one of the first handful of people with a cognitive science background to work at Bell Labs, my work in online documentation and content management systems emphasized the "people parts" or "front stages." Over time, especially when I was part of two Silicon Valley start-ups in electronic publishing (Passage Systems, 1992-1996) and B2B marketplaces (Veo, 1997-1999) my focus shifted toward the "back stage" where information is managed, transformed, and moved within and between business systems.

But recently, as I've helped to shape the emerging discipline of "Service Science," my goal is to develop methods for designing " service systems" that treat the entire network of service components that comprise the back and front stages as complementary and integrated parts. For almost two years I've had a team of graduate students with a mixture of front and back stage design skills thrash with each other and with me to seek some unifying concepts and methods that can overcome the biases and conflicts inherent in their different perspectives.

At the risk of stereotyping, here's how I've contrasted these two design approaches in a paper I wrote with Lindsay Tabas:

• Designers with a "front stage mindset" strive to create service experiences that people find enjoyable, unique, and responsive to their needs and preferences. Front stage designers use techniques and tools from the disciplines of human-computer interaction, anthropology, and sociology such as ethnographic research and the user-centered design approach to specify the desired experience for the service customer. They capture and communicate their service designs using modeling artifacts that include personas, scenarios, service blueprints, and interactive prototypes.


• In contrast, service designers with a "back stage mindset" typically follow different goals and techniques. They strive for efficiency, robustness, scalability, and standardization. Even though some back stage activities are carried out by people, and others carried out by automated processes or applications, the back stage mindset tends to treat people as abstract actors. So instead of modeling the preferences and interactions of people, back stage designers identify and analyze information requirements, information flows and dependencies, and feedback loops. They use concepts and techniques from information architecture, document engineering, data and process modeling, industrial engineering, and software development. Their typical artifacts include use cases, process models, class diagrams, XML schemas, queuing and simulation models, and working software.

The usual approach for resolving the typical design conflicts and tradeoffs between front and back designers is to create multidisciplinary design teams that explicitly include designers with front and back stage biases. But this is a necessary but insufficient remedy, because what often happens is that each tribe of designers is so convinced of its intellectual and moral correctness that it tries to beat the other side into submission rather than make reasoned tradeoffs. I think this is especially true of relatively inexperienced usability or HCI designers, who find it difficult to accept that business models, legacy implementation constraints, or backward compatibility should shape what gets built. Likewise, some software developers and business managers discount ethnographic field work because the insights about activities and problems seem obvious, but only in retrospect.

So I've come to think that a good designer needs a more end-to-end perspective and some familiarity with the concepts and design techniques of "the other stage." And that's why we developed a new course called " Information Systems and Service Design: Strategy, Models, and Methods" that I'll teach for the first time this coming semester.

This course covers the entire design process, but rather than teach it from a narrow perspective governed by a single methodology like "user-centered design," it brings together multiple perspectives so that students can learn multiple ways of dealing with the same problem. Many of the topics in the syllabus come in complementary pairs, like "Personas" and "Customer modeling" - where traditional HCI methods get "mashed up" against business/marketing/backend perspectives on the same design problems. Likewise, there are readings on "Ethnography for experience design" (i.e., follow and observe people as they work) with what I call "Ethnography for information system design" (i.e., follow documents and other information objects as they move between people, organizations, and systems). My experience has shown that a combined "document anthropology and archeology" yields much better requirements and insights than either does on its own.

One other key aspect of the course is that it discusses a much broader set of design contexts than the typical UCD or HCI design course does. These courses most often consider the design of "one shot" new applications or services where there are no legacy constraints, integration concerns, or product family roadmaps in which functionality emerges over time over a set of related offerings that have to fit into an environment with existing systems and services.

So in this new course we'll deal with multichannel designs (that exist in both online and physical contexts, like a web store that also has brick-and-mortar locations), composite applications that combine new information resources with existing ones, and "smart" services that are driven by information collected from sensors or from objects as they move through supply chains or distributed systems. Students will work in teams (which we'll put together to have as diverse or contrasting design experiences as we can) to have an end-to-end design experience in one of these three emerging contexts. I think this will give students a more realistic view of what "design in the wild" is really like.

I'll publish my lecture notes on the course syllabus page as the semester progresses if anyone wants to follow along.

-Bob Glushko