100 Ideas for Envisioning Powerful, Engaging, and Productive User Experiences in Knowledge Work
Download E-Book or Order Softcover Book In addition to this website, Working through Screens is available in several other formats: - Softcover print on demand books (NEW) - Free letter size .pdf (NEW) - Free large format .pdf - Free "Idea Cards" .pdf View all Working through Screens Formats |
| Email List Join our email list to receive updates about our publications: |
| Contact Our Consulting Studio Contact Flashbulb Interaction to find out how we can help your team to better conceptualize and deliver your next application design. E: info@FlashbulbInteraction.com P: 206.280.3135  |
| Latest Studio Updates From our FlashbulbUX Twitter feed:  |
| Feedback on Working through Screens? Email us your thoughts or Twitter @FlashbulbUX |
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. 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. 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, technological 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.” 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.” 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 definitions for “functional area” and “functionality.” Information management application: In the context of this book’s examples, this term refers to a computing tool for clinical research. These applications, also known as a Laboratory Information Management Systems (LIMS), can keep track of all stored data about a laboratory, from the stock on the shelves to the results of genetic tests. Many of these systems also provide functionality for defining and monitoring laboratory workflow, allowing scientists to design and distribute experimental protocols for lab technicians and automated instruments to follow. Since LIMS are often open to integration with other applications, they can become a central hub for connecting all of a laboratory’s computing infrastructure. See the “Primer on example knowledge work domains” section for additional background information on the clinical research computing examples used throughout this book. Interaction object: The comprehensible elements within an application that workers act on in order to accomplish their goals. Interaction objects are defined from users’ activity oriented perspectives, and they do not necessarily correspond to the idea of “objects” in the computer science sense of the word. Product teams can translate key interaction objects from artifacts in workers’ existing practices, which can then become meaningful elements of an application’s intended conceptual models. Other objects can represent novel system ideas that would otherwise not exist in targeted knowledge work culture. Interaction objects can nest and interrelate, and ideas for additional, low level objects may emerge during the product development process. The notion of interaction objects is derived from Ben Shneiderman’s “Object-Action Interface Model” (1998), without its emphasis on direct manipulation. Interaction pattern: A reusable convention in the design of interactive applications. These conventions are often thought of at the “literal” level, containing specific arrangements of information and user interface controls. Interaction patterns can also usefully represent larger commonalities in conventional interactions, such as approaches to entire application structures or task processes. Interactive computing: In the context of knowledge work, applications of computing that workers directly interact with, as opposed to an increasing number of embedded applications that are effectively hidden in artifacts in a way that prevents users from having direct control over their behaviors. This book primarily focuses on interactive applications that could be feasibly implemented on personal computers at the time of writing. Interactive application: A specialized computing tool for mediating targeted activities, including both installed products and those that are accessed via the Internet. In the context of envisioning potential user experiences in knowledge work, the emphasis of this term falls less on the technical construction of a tool and more on its potential definition and design opportunities. Interaction model: The highest level expression of an application’s structure. A “shell” that determines how interactive behaviors and disclosures essentially flow within a computing tool. An interaction model frames the full scope of an onscreen product, outlining the interactive approaches and points of access for its constituent functional concepts. In contemporary personal computing, where some sort of keyboard and pointing method are essentially a given, interaction models may reside largely in the onscreen structure and behaviors of a knowledge work tool, rather than in specialized hardware controls. Knowledge work: A broad category of human activity that is focused on inventing, producing, interpreting, manipulating, transforming, applying, and communicating information using specialized skills and knowledge. Knowledge workers: Individuals who, in their working lives, are valued for their specialized intellectual skills and their ability to act on and with complex information in goal oriented ways. This term can refer to specialized professions (such as the architect, financial trader, and scientist found in the examples throughout this book) or more generalized vocations. Object: See definition for “interaction object.” Organization: Any group of individuals working together with shared goals and, in many cases, a division of labor and responsibilities. This umbrella includes groups such as non profits and online collaboratives, as well as those that are more commonly associated with knowledge work in the business world. Magic happens expectation: A problematic expectation in product teams that a successful, even visionary, product will somehow emerge solely from the sum of countless detailed definition, design, and implementation decisions — without a larger design strategy or application concept as guiding road map. See also definitions for “straight to the details progression” and “single vision and concept design.” Market information application: These computing tools allow financial traders to investigate current and historical data about specific market sectors and traded financial instruments from a variety of different perspectives. The feeds and visualizations in these applications can help traders to stay current on market happenings and to better assess potential deals. See the “Primer on example knowledge work domains” section for additional background information on the financial trading computing examples used throughout this book. Mediate / mediation: Refers to an interactive application’s interfacing role between workers and their goals, as coarsely borrowed from Alexei Leontiev’s Activity Theory. Each approach to supporting a work practice with technology presents different “mediating” changes to the essential nature of that practice. Knowledge workers will inevitably view some mediation approaches as more attractive and successful than others. Models of problem spaces: Artifacts that summarize meaningful primary research, secondary research, and design research insights into clear and informative representations that map out relevant regions of product possibility. These models can take a variety of forms, ranging from graphs, to textual stories, to storyboards, to video exposition. Offloading: Reducing the work needed to accomplish an action by distributing some of the effort to an interactive application, collaborator, or another part of a distributed work system. Actions that initiate offloading can range from deliberate and intentional to implicit and subconscious. Offloading effort can change the essential nature of work practices. After a computing tool has been appropriated into a workplace culture, participating individuals, in their accommodated ways of thinking and acting, may not even recognize how they opportunistically offload effort to the external artifact. Operation: Within a product team’s rationalized models of work practice, operations are low level actions that workers can perform. Individual operations are typically enacted in a sequence in order to accomplish larger goals for interacting with a system. Operations 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. Multiple operations comprise a task. Product: See definition for “application.” In many cases, the term “service” could be equally applicable (though it was not extensively used throughout this book in order to promote brevity). Although the term “product” has a commercial connotation, the applications discussed here could also be created by an open source community or internally developed within specific organizations. Product Teams: The primary audience of this book; a group of people creating an interactive application for knowledge work. For the purposes of this text, product teams’ memberships can include anyone who plays a role in product development, with a special emphasis on those individuals who are (or could be) involved during early, strategic, application envisioning efforts. This broad definition can include anyone from high level management to knowledge work “customers” who are brought on as advisors and design participants. Progressive disclosure: A design approach which can decrease perceptual load and promote more effective use of limited screen areas by “hiding” some content and functionality until it is interactively accessed, as needed, through users’ goal oriented pathways. Scaffolding: Borrowed from Lev Vygotsky’s ideas on the Zone of Proximal Development, scaffolding is application content or functionalities that provide workers with supporting structures for their learning, based on an understanding of their current knowledge and abilities. Users can accomplish more with the support of scaffolding, and by doing so, they can make learning leaps that may be more difficult without such support. After an individual has learned a scaffolded interaction, the supporting features can often be removed from day to day use. Alternately, in some cases, these features may be left in place to provide some ongoing utility. Scientist: See definition for “clinical research domain.” See also the “Primer on example knowledge work domains” section for additional background information. Settings: Meaningful parameters in an application that workers can have some measure of control over. These parameters can be highly flexible and numerous in applications for early adopters. By contrast, in highly developed products that target less invested user segmentations, guiding product settings may be relatively few in number and more constrained in scope. Single vision and concept design: The problematic approach by which product teams iteratively create only one de facto design strategy and corresponding application concept. These singular progressions often begin with a rush toward implementation and only limited ideas about product direction and potential meaning. Although teams practicing this type of design may evolve their own conceptions about their applications at a detailed level, their lack of early, divergent thinking about work mediation can be considered a failure to strategically explore potential directions within their initial, high level charters. See also “straight to the details progression” and “magic happens expectation.” Sketch: A rough representation of a framing idea or potential design direction, generated within a product team during the application envisioning process. Teams can sketch at many levels of granularity, ranging from an application’s overall vector to the diminutive shape of a small functionality concept. During early envisioning, teams typically create sketches to capture and convey potential options for mediating work, not to solidify highly specific design details like those found in later prototypes. Although the outputs of sketching exercises are often some sort of drawing, teams may also usefully “sketch” their ideas in video and other media. Straight to the details progression: The problematic progression by which product teams quickly move from high level consideration of product strategy into the specifics of an application’s definition, design, and implementation. This progression can be fueled by various team members’ specialized focuses on particular techno-centric facets of their products. See also “magic happens expectation” and “single vision and concept design.” Tailored: Designed or customized to meet the specific needs of targeted knowledge workers and their organizations, as situated in the context of well characterized cultures and activities. Task: Within a product team’s rationalized models of work practice, tasks are a goal oriented action that workers can perform. Tasks may be nameable, discussed elements of workers’ shared cultural models of their own work, or they may be unspoken routines and improvisations. A product team’s application concepts may aim to effectively eliminate some existing tasks in workers’ practices while introducing new ones that could stem from the adoption of their product. Tasks 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 (where the term “Action” is used instead of “Task”). Multiple operations comprise a task. Multiple tasks comprise an activity, though not all of the tasks associated with a particular activity may occur within the confines of a single interactive application. Trading application: As a financial traders’ “window” into their firm’s valuable information, these computing tools typically allow users to examine shared trading records and to book new deals. Trading applications often automate many tedious operations ranging from small data predictions when filling out forms to automatic routing and processing of completed deals through a number of related systems. See the “Primer on example knowledge work domains” section for additional background information on the financial trading computing examples used throughout this book. Work practice: The actual methods, as opposed to idealized notions of process, by which knowledge workers accomplish their efforts. People may have different approaches to accomplishing the same categories of activity, and observations of knowledge work often reveal considerably more improvisation, situated decision making, communication, cooperation, and collaboration than is commonly acknowledged by individual workers or their organizations. See also definition for “work process.” Work process: Established ways of working that are formally agreed upon within an organization or larger profession. In many types of knowledge work, especially in those domains where practitioners have developed considerable skills and expertise, established processes may arise from formal acknowledgement and standardization of workers’ own emergent practices. Alternately, work processes may be defined based on top down considerations, such as legal or business operations requirements. See also definition for “work practice.” Workflow: Established work processes where efforts are distributed among a number of different individuals, often based on the assigned roles that these people play within a group or larger organization. Depending on the context, workflow can also be a synonym for “work process.” Workspace awareness: As outlined in Gutwin and Greenberg (2002), this type of awareness can be thought of as an ongoing sense, often without conscious attention, of others’ actions within a shared locale. In shared computing environments, this awareness can be especially relevant when it pertains to actions that could impact cooperative or collaborative efforts. Workspace awareness can be critical for promoting coordination and communication, potentially leading to fewer errors and higher quality work outcomes. Knowledge work applications can provide specialized workspace awareness functionalities to counter the individualized, often isolating interactions of contemporary personal computing. < PREVIOUS PAGE | NEXT PAGE > Back to top | View Table of Contents |
All original contents of Working through Screens online book are subject to the creative commons license (Attribution-NonCommercial- ShareAlike http://creativecommons.org/licenses/by-nc-sa/3.0/) unless otherwise noted. Please attribute the work to “Jacob Burghardt / FLASHBULB INTERACTION Consultancy.” |