WORKING THROUGH SCREENS
Glossary Many specialized terms have been intentionally omitted throughout “Working through Screens” in favor language that product teams can more easily share during their application envisioning efforts. However, given that the main goals of this book represent a highly specialized pursuit, the following glossary defines a number of specific terms that have been used in this volume. Please note that the following definitions are not general purpose; they are written specifically for the limited context of envisioning interactive applications for knowledge work. Broader definitions of the same terms could take on substantially different slants. Activity: Within a product team’s rationalized models of work practice, an activity is a larger set of goal oriented actions performed by one or more workers in order to contribute to a larger purpose. Activities are tied to foundational motives of knowledge work, and they are often nameable, discussed elements of workers’ shared cultural models. As product teams envision concepts for how their technology could mediate workers’ efforts, the selection of targeted activities can be a key determinant of an application’s design strategy, functional scope, and potential meanings to future users. Activities are one part of the “operations, tasks, and activities” hierarchical approach to modeling work (see other definitions in this glossary), as coarsely borrowed from Alexei Leontiev’s Activity Theory. Activities may also nest into other, higher order activities, which may in turn nest into further activities, and so on. Advanced Analogies: Lateral references to the innovative use of technologies in other, often seemingly unrelated, domains. An advanced analogy creates a meaningful connection to an outside reference point that can inspire product teams to think about their design problems in different ways. Sometimes this inspiration involves literal translation from an analogous situation, while other times the forward looking influence is less direct and more evocative. Analysis application: In the context of this book’s examples, this term refers to a computing tool for clinical research. Analysis tools designed for the scientific market represent some of the most advanced examples of interactive applications currently available to knowledge workers. These tools can take seemingly countless pieces of laboratory data and present them in ways that allow scientists to understand trends, uncover anomalies, and make decisions. Robust visualization functionality can allow researchers to sift through experimental results from a wide variety of perspectives based on emergent wayfinding approaches. In clinical research areas where certain established analyses are often useful for understanding data, highly tailored functions can automate known, well characterized tests and present their results in clear and actionable information displays. See the “Primer on example knowledge work domains” section for
additional background information on the clinical research computing examples used throughout this book. Application: See definition for “interactive application.” Application concept: Sketched assemblies that integrate selected functionality concepts, along with strategic and infrastructural ideas about a product’s design, into a named, overall approach to mediating a chosen scope of knowledge work activities. Product teams eventually choose one of their envisioned application concepts (or a hybrid concept) to serve as the basis for the rest of the product development process. Application envisioning: An early, separate time in product development for teams to collaboratively consider diverse and appropriate concepts of what could be, rather than being pulled down an incremental, largely unconsidered course. During this interval, teams can iteratively generate application concepts in lightweight models and sketches rather than implemented code. Time spent in this “preproduction” mode can result in outcomes that are grounded in the vector of a compelling and broadly informed design strategy. At the end of application envisioning, teams can select the “fittest” concepts for their product’s essential direction and form from a relevant ecosystem of potential ideas. Architect: See definition for “architectural domain.” See also the “Primer on example knowledge work domains” section for additional background information. Architectural domain: Architects and their firms, generally speaking, seek to profitably create well designed drawings for buildings that address complex criteria. Some aspects of these complex work practices are used in examples throughout this book. See the “Primer on example knowledge work domains” section for additional background information. Automaticity: In the context of interactive applications for knowledge work, the point of learning and accommodation at which workers can execute certain operations and larger tasks with reduced effort. When novel situations arise in otherwise predictable interactions, workers’ automatic behaviors can lead to special error cases in product use. Application designs that promote automaticity in frequent usage scenarios can be very different from those design responses that emphasize initial learnability and usability. Building modeling application: This term encompasses an emerging class of computing applications, more commonly called Building Information Modeling (BIM), that is beginning to drive radical changes in architectural practice. In BIM, the entire design of a building is stored as a collaborative virtual model
that can be modified and referenced by different contributors to a project, purportedly improving communication and reducing representational misunderstandings. See the “Primer on example knowledge work domains” section for additional background information on the architectural computing examples used throughout this book. Clinical research domain: Clinical research scientists, generally speaking, want to make applied discoveries related to human health. These scientists adopt diverse methods and technologies to attack their research problems, depending on the nature of the topic under study and researchers’ own areas of expertise. Some aspects of these complex work practices are used in examples throughout this book. See the “Primer on example knowledge work domains” section for additional background information. Community of practice: A community of knowledge workers mutually engaged in collaborative action and learning in a shared domain over time. As described in the writings of Etienne Wenger, these communities build upon each others’ efforts and ideas, often through direct participation in social exchanges. In the context of knowledge work, communities of practice can represent the staff of a particular group in an organization or a larger collective within a domain, such as a long standing professional organization. Conceptual model: In the context of envisioning applications for knowledge work, they are the mental models that contain people’s particular understandings of which work practices an interactive application is designed to support, how it essentially “works,” and how it might fit into their own activities. As mental constructs, product teams cannot create conceptual models for their eventual users. Knowledge workers must build their own nesting and interrelated understandings as part of adopting a computing tool into their own work practices. However, product teams can develop intended conceptual models for various parts of their applications and seek to communicate these models through embedded design characteristics and explicit instruction.
nological possibilities, market forces, trends, and predictions. Product teams can use these strategies to drive clarity in their offerings and focus their members around a shared vision and goal set. Since they are derived from key business, marketing, and product development considerations, design strategies can be thought of as a lower level expression of a computing tool’s initiating, high level charter. Envisioning: See definition for “application envisioning.” Envisioning questions: Points of inquiry that get product teams thinking about divergent factors that could shape their application concepts. Envisioning questions are answered through active, considered, and participatory processes of research and design exploration. Financial trader: See definition for “financial trading domain.” See also the “Primer on example knowledge work domains” section for additional background information. Financial trading domain: The many specializations of financial trading are, generally speaking, about the exchange of financial instruments to maximize returns for traders, their firms, and their clients. Some aspects of these complex work practices are used in examples throughout this book. See the “Primer on example knowledge work domains” section for additional background information. Functional area: A larger area within an application, often organized around a particular goal or set of actions. Functional areas can be designated by a prominent heading in an application’s navigation and a separate “place” or “section” within a tool. A single functional area can typically be further broken down into a number of individual options and related interactivities. See also definitions for “functionality” and “functionality concept.”
Domain: Generally connotes a unique specialty in knowledge work. Domains can encompass a broad range of existing cultural knowledge and skills, ranging from general methods of practicing to highly specific information and abilities that are crucial for successfully accomplishing work activities.
Functionality: Features in a knowledge work application that are provided as goal oriented options for workers to use in their own activity contexts. Some functionalities may be highly specific tools for narrow goals, while others may be more general purpose and open to users’ interpretations. Applications are typically comprised of many functionalities, and individuals may use some available options more frequently than others, depending on how they see a product fitting into their local ways of thinking and acting. See also definitions for “functional area” and “functionality concept.”
Design strategy: The singular, relatively unchanging proposals that summarize the essence of an envisioned application’s scope, core value, points of emotional connection, and approaches to mediating knowledge work. Design strategies are situated within a larger context of targeted user needs, tech-
Functionality Concept: Sketched possibilities for work mediation that product teams generate as a part of their envisioning explorations. These concepts represent a goal oriented scenario for potential user experience, including a team’s proposed design responses to targeted problems and constraints. See also
Published on Jan 13, 2010
Working through Screens: 100 Ideas for Envisioning Powerful, Engaging, and Productive User Experiences in Knowledge Work This heavily illus...