100 APPLICATION ENVISIONING IDEAS | A. EXPLORING WORK MEDIATION AND DETERMINING SCOPE
WORKING THROUGH SCREENS
A5. Interrelations of Operation, Task, and Activity Scenarios Knowledge workers’ granular actions can be categorized as operations, which overlap and interrelate into larger tasks, which themselves overlap and interrelate into the larger unit of activities. Explicit models of these multi-tiered relationships can help product teams envision interactive applications that are much more than haphazard collections of unconnected, discrete functions.
From a vantage point that emphasizes knowledge workers’ mental efforts, how might your team break down your big picture characterizations of targeted workers’ practices into a useful and meaningful hierarchy of activity, task, and low level operation elements?
It’s amazing to think of all of the different steps that I take in a day, many of which touch my building modeling so�ware in one way or another...
More specific questions for product teams to consider while envisioning applications for knowledge work:
Examples from three knowledge work domains: An architect performs many small operations in her building modeling application, progressively completing separate tasks that incrementally advance the project. These individual advancements, in conjunction with her colleagues’ contributions to the same model, result in a series of iterations, which eventually result in a complete and approved design (see illustration).
Architect
In the process of rationalizing knowledge work for system design, product teams inevitably break down larger work practices into smaller pieces. They may characterize segments of work by inputs and outputs, the actors involved (A2), related goals, and many other factors (J3). While this deconstructive approach can be a key method for developing meaningful understandings of workers’ behaviors, it runs the risk of severing inherent linkages that can be essential for effective envisioning of useful and usable computing tools (C4, G1). Product teams can connect characterized units into networks and tiered hierarchies that reflect workers’ current and desired practices. They can recognize that when they envision a specific activity as part of their application’s scope (A3, A9), they are going to have to support at least some of its related tasks and operations. Teams can discover that these linkages between units may not be exclusive, so that, for example, the same task can be tied to two different activities, with slight variations based on differences in context (A7, A8). They may also see that the interrelations inherent in work practices could suggest, for example, a basis for automated functionality (E3, E4) or connectivity with other technologies (B8, K8, K9, K10). When product teams do not actively consider how the interrelated nature of workers’ practices might impact their emerging ideas about work mediation and application scope, opportunities to envision clearly defined, easily navigable, and functionally appropriate products can be lost (C1, C2). Considering these interrelations can be particularly important when teams are creating novel tools that do not have core, established conventions to fall back on (F2, L2). See also: A, B4, B5, C6, F1, G5, K, M1, M4
Which operations are so discrete that they probably do not need to be included in your envisioning process? How much detail is too much detail when thinking about a foundational model that your team can use to sketch potential design strategies and application concepts? What user goals and other attributes might your team capture for each operation, task, and larger activity in your emerging rationalizations of knowledge work?
A financial trader performs a number of steps while completing every trade. These individual trades contribute to his larger goal of advancing the profitability of his firm by maximizing the value of his own transactions. A scientist analyzes the clinical data generated by her lab technicians after each round of their experiments. These individual analyses accumulate into a study’s findings, which then lead to further studies, in a chain of research that contributes to the accumulated knowledge of her clinical field.
28
How should the discrete, individual elements within your team’s models of current and desired work practices overlap, nest, and interrelate? Could individual operations map to more than one task, or are they strictly hierarchical? In the interval of this one ac�vity, there are several tasks, which are themselves comprised of many separate opera�ons
Could individual tasks map to several different activities? Could individual activities map to other, larger activities? How might the mapping of an individual work element to multiple situations change how it is practiced under different circumstances? Where could variations based on these mappings be drastic enough to call them out as different practices? How might different scenario flows through your team’s rationalized maps of work practice drive different requirements for functionality concepts? Which threads and mappings in your models could be essential for envisioning your application’s conceptual model, interaction model, and pathways for goal directed wayfinding? Do you have enough information to usefully answer these and other envisioning questions? What additional research, problem space models, and design concepting could valuably inform your team’s application envisioning efforts?